Ideas for plugins

Skip to first unread message

Olaf Zevenboom

Apr 5, 2021, 4:56:35 AMApr 5
Some time (release) ago there was a call for ideas if I recall correctly. Sadly it took me some time to compile these let alone I could find time to develop them myself. So here they are:

As I did not have had the time recently to play around with the latest SCM-Manager versions so I might suggest something already (partly) there.  If so: sorry for the fuzz.

#1 Subprojects
Use case: developing various tools/script to support a project/product. These are seperate items. They might not interact and can be developed next to the main project.
I have not used this feature yet (bit want/need to), but as I understand there is some support for this with Git:
Having a nice GUI to facilitate this would be nice.

#2 (wiki) documentation
Sometimes it can be useful to document something which applies to several projects/repositories. Such as links to tools, document coding standards, who to reach out to in case of X, knowledgebase like things such as what is the IP-address or hostname of the development/test database server etc
It would be nice if such info can be jotted down and shared among multiple projects.
Obviously it would be overkill to implement a full wiki. It would be better to support an external one or to minimize the feature.

#3 sync/backup/publish repositories
With the arrival of we were provided by import/export features. How cool would it be if there could be some (semi)automated relation between code repositories or even tickets?
Develop in house some code using SCM-Manager and publish (export) it to external GitLab? Have a FOSS project on Github with a local SCM Manager enterprise sibling and import some code to SCM_manager?
Both are examples of one way code sharing, but copying code between branches manually or automatically could keep codebases in sync. Though cookie as the more complex it gets the more challenging conflicts can be.
Never the less a nice feature to have.
When available through an API it can also be used in backup script automation.

#4 License wizard/manager
Finding the right License for a project can be challenging. You also need to add a license file. Some licenses allow for double licensing or a change of license en some do not.
Having a simple plugin which would assist in these would be nice.

Thank you for a great project. I liked SCM Manager v1 a lot, but things are put really into high gear with SCM Manager v2.

Daniel Huchthausen

Apr 6, 2021, 12:56:24 PMApr 6
to scmmanager
Hi Olaf,

Thanks that you took the time to share your ideas, that's exactly what we need to improve SCM-Manager even more!

After reading your ideas I have a few questions and suggestions for you:
#1 Subprojects
Could you please further explain what you would like to do via the GUI? SCM-Manager supports the linking of repositories/subrepositories, which comes with the general advantages and disadvantages described in your links. Would you for example like to add subrepositories via the GUI?

#2 Wiki
We have already developed a wiki that is highly integrated with SCM-Manager. It's called Smeagol and you can easily use it together with SCM-Manager in our Cloudogu EcoSystem. There is also the Smeagol plugin for SCM-Manager

#3 Sync/backup/publish repositories
Currently it isn't possible to sync with an external repository, but SCM-Manager allows you to make repositories publically available. Also, if you use the Cloudogu EcoSystem, you can easily use its backup and restore feature. Using that, you can create backups of SCM-Manager, the wiki Smeagol and all other tools you might use in the platform. Are these two features a step in the right direction? Please let me know if you have any questions about them!

#4 License wizzard/manager
I am not sure if SCM-Manager would be the right place to choose a license for an open source project. Are you thinking of a wizzard that askes you a few questions and then tells you which license would be best? 
I know for example Sonatype Lifecycle which is also available through the Cloudogu EcoSystem. That tool even analyses all artifacts of your project to tell you about restrictions of their licenses. That is propably a lot more than what you thought of but it is very helpful when using open source components in your projects (even if your project itself is not open source). 

Best regards,

// Enterprise support for SCM-Manager
// Cloudogu GmbH
// Web:

Olaf Zevenboom

May 3, 2021, 6:53:34 AMMay 3
to scmmanager

Hi Daniel,

Sorry for the late reply.

Yes, adding/managing subrepositories using the GUI is exactly what I would like to see.

#2 / #3
Sorry I did not have a look at your Cloudogu Ecosystem. I fully understand that you do not want to do things double and want to have a commercial offering next to SCM-Manager. I was not aware of the possibilities and was just looking at things from the FOSS SCM-Manager point of view.

More and more you see on projects (at Github for instance) that projects have "special files" added to them to facilitate external processes (CI for instance), ignoring files to commit, or adding descriptions to projects. My idea was to have SCM-Manager make users/project manager aware of the (non)existence of these files and to add them when required. One of the more complex ones being a file describing the license. Not that the file itself is complex, but choosing a license can be hard, changing or adding one can be too. And it is also easy to forget to add one at all. Adding remark lines with (c) just is not enough. Adding a wizard to facilitate this would be nice.
Hence my idea for such a project facilitating plugin. Again, I was not familiar with a full analytic tool available through Cloudogu.

You received this message because you are subscribed to the Google Groups "scmmanager" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Daniel Huchthausen

May 3, 2021, 1:06:59 PMMay 3
to scmmanager
Hi Olaf, 

Thanks for your reply and sharing your point of view. 
Just in case you are currently interested in using a wiki: our wiki Smeagol is also open source, just like SCM-Manager. The easiest way to use it is with the Community Edition of the Cloudogu EcoSystem, but you could also set it up manually.

The way you describe the license wizard sounds interesting, but my first thought was, what happens if somebody chooses a license based on the wizard, which then turns out to be the wrong one. Just because of legal issues that would almost have to be a small application in its own. Sonatype LifeCycle, the tool I mentioned, doesn't really help in that matter either. 
What you said about the "(non)existing" files made me think of a wiki or readme to at least mention them. Therefore the scm-readme-plugin could be a first step, because it shows the content of the readme in the UI of SCM-Manager which is maybe more accessible for e.g. project managers.


// Enterprise support for SCM-Manager
// Cloudogu GmbH
// Web:

Olaf Zevenboom

May 3, 2021, 3:28:05 PMMay 3
to scmmanager
Hi Daniel,

Legal issues are indeed something to keep in mind. Maybe a very big disclaimer can be used here. Not sure,
I am quite sure I have seen other examples in the past, but here are some current findings:

But most of all I think a "monitor" which reviews a repository by suggesting improvements (add ReadMe, add License file, add .ignorre file, etc) would be a nice asset. If would be a big bonus if that plugin could generate these files and add them to projects. Chances are choices need to be made when inserting them. One example would be "the right" license. But as you said: adding stuff, making suggestions, etc might provide an extra compared to other repository managers, but also requires some legal attention just like most software licenses try to keep the FOSS developers safeguarded.
Or resort to:


Or some alternative background info:
Which might sound offensive and does not address potential liability.

oh. Although I find this topic quite intriguing I hope this does not start a flame war on licensing.
Never came across a license which protects you against liability, demands patches to be send upstream, allows for all kinds of usage, but requires payment when money is being made out of the provided code. Hundreds of licenses are available, but only 10 or so seem to be popular. Also see: License proliferation
I just wanted to clarify myself a bit further.


Reply all
Reply to author
0 new messages