|
Description:
|
Scm-sync-configuration is based on Maven SCM API & Jenkins SCM API to provide a generic way to synchronize config files with multiple possible scm.
Today, every possible SCM implementation (namely svn & git) are bundled inside the scm-sync-configuration-plugin artefact, thus pulling every scm implementations even if you only rely on 1 of them.
FYI, following dependencies will be pulled per scm implementation :
- maven-scm-provider's scm implementation (at the moment, either maven-scm-provider-svnjava or maven-scm-provider-gitexe)
- jenkins' plugin providing authentication support for your scm (at the moment, only org.jenkins-ci.plugins:subversion but we should consider org.jenkins-ci.plugins:git to have homogeneous git authentication support accross the plugin and jenkins stored credentials, see JENKINS-14506)
This point is an important point because as soon as a plugin is depending on another plugin, jenkins will install both plugins when the root plugin is installed. This means when mercurial/perforce/whatever will be provided, when you will install the plugin on your jenkins instance, it will pull & install lots of possible unwanted plugins on your instance.
Another burden is the way scm implementation are maintained.
I (Frédéric Camblor) will not be able to ensure every scm implementation will "work" : it is already a burden to ensure, for only 1 given scm implementation, that every possible scm protocols (namely svn / svn+ssh / http / https) are supported.
This is something hard to test automatically because it needs to setup a subversion server handling every supported protocols.
For more informations about this point, See JENKINS-8871.
These are the reasons why I would like modularize the plugin.
Technically, this should consist in :
- Modularize needed generic/helpful classes for scm manipulation in a scm-sync-configuration-api artefact
- Provide a maven parent pom for scm-sync-configuration's scm implementations, in order to help scm maintainer to only focus on their implementation, and not on the build / dependencies
- Externalize scm implementations into dedicated Jenkins plugins, relying on scm-sync-configuration-api and extending scm-sync-configuration-scm-parent pom
- Provide an @ExtensionPoint in the core, used by scm plugin implementors
In terms of usability, this will imply for the user :
- To download not only the scm-sync-configuration-plugin but both scm-sync-configuration-plugin & scm-sync-configuration-plugin-<your scm impl(s)> (for instance : scm-sync-configuration-plugin-subversion)
- The basic "none" scm implementation will be provided, and a message will be displayed to the user asking him to download at least one implementation if he didn't
- The plugin will not be backward compatible because we will go from (none/subversion/git) available implementations to (none) implementation only. I don't know, at the moment,
In terms of maintenability, this will imply :
- Migration from an organization where I (Frederic Camblor) like a SPOF, to an organization where this is less the case : every scm implementor will be considered as its own maintainer (with dedicated component in jira & project in github)
- The core will remain open to every contributor, particularly scm implementors (if one of them need an enhancement in the core, we'll have to talk about it but it will be welcomed)
|
