![]() |
|
|
|
|
Change By:
|
Frédéric Camblor
(29/May/13 7:59 AM)
|
|
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, both maven-scm-provider-svnjava and 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 once [mercurial|https://github.com/jenkinsci/scm-sync-configuration-plugin/pull/9]/perforce/whatever will be supported, 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 implementations are maintained.
I (Frédéric Camblor) will not be able to ensure *every* scm implementation will just "work" : it is already a burden for me to ensure, for only 1 given scm implementation, that every possible scm protocols (namely svn / svn+ssh / http / https) are supported (See JENKINS-8871).
This is something hard to test (and I don't even speak about *automatic* testing) because it needs to setup a subversion server handling every supported protocols.
These are the reasons why I would like to 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 implementors, in order to help scm maintainer to only focus on their implementation, and not on the build / dependencies for the plugin
- Externalize scm implementations into dedicated Jenkins plugins, relying on scm-sync-configuration-api and extending scm-sync-configuration-scm-parent pom
- Provide an [@ExtensionPoint|https://wiki.jenkins-ci.org/display/JENKINS/Extension+points] in the core, used by scm plugin implementors to plug their implementation
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, how I could handle this backward incompatibility (if you have ideas, don't hesitate to submit them in comments).
Maybe could I rename the plugin and deprecate the existing one ? I dunno.
- Lifecycle between core and scm implementations won't be the same : a bugfix/improvement in an scm implementation won't need a release of the core
Drawback for this is we will have to track api incompatibilities in the core, and align scm implementations when needed. Goal is to avoid errors when core is upgraded and implementations are not (eventually, we could enforce this
problematic
detection
in scm-sync-config-api)
In terms of maintenability, this will imply :
- Migration from an organization where I (Frederic Camblor) am a *SPOF*, to an organization where this is *less* the case : every scm implementor will be considered as a plugin maintainer with dedicated component in jira, project in github, *and responsibilities*.
- 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)
|
|
|
|
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit
https://groups.google.com/groups/opt_out.
