![]() |
|
|
|
|
Change By:
|
Frédéric Camblor
(29/May/13 7:40 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, either maven-scm-provider-svnjava or maven-scm-provider-gitexe)
-
jenkins
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
once
[mercurial|https://github.com/jenkinsci/scm-sync-configuration-plugin/pull/9]/perforce/whatever will be
provided
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
implementation
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
automatically
(and I don't even speak about *automatic* testing)
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
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
implementations
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.
In terms of maintenability, this will imply :
- Migration from an organization where I (Frederic Camblor)
like
am
a
*
SPOF
*
, to an organization where this is *less* the case : every scm implementor will be considered as
its own
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.
