scm-sync-config to expose an extension point for all repo operation would indeed be a more extensible design.
I'm also not convinced about using maven-scm implementation. For sample, the git one don't let you create a commit passing author/committer identity. An alternate impl to use JGit could then be created. Afaik scm-sync only uses a limited set of scm methods, so such an implementation wouldn't be such a pain.

I don't have problem with many plugins, aka scm-sync-configuration-plugin & scm-sync-configuration-plugin-xxxx-impl.

About SPOF, it will be nice to have SCM SYNC in Jenkins organisation, next to the core, since you experience issues when core moved.
Currently it's a nightmare to have a working matrix in Jenkins, aka Core and Plugins aligned, and some sensible parts, like SCM SYNC should be part of core.

My 0.01€

I don't get your argumentation on maven parent pom for scm-sync implementors. If scm-sync expose an extension point, just need to create a very classic jenkins plugin and implement @Extension, what else ?

for backward compatibility, scm-sync could have the scm-sync-svn-provider and scm-sync-git provider bundled as dependency.
Initial implementation for those two plugins just need to extract code from scm-sync "as is" still using maven-scm, then let maintainer explore alternative implementation, either as improvements or in other dedicated plugins.

@Nicolas I agree with you on the fact that only a little set of maven-scm is used.
And relying on it shows its limits as soon as a feature is not "generically" available for every scms (see JENKINS-14841).
So your proposal makes sense.
What I'm not confident about this proposal is the way authentication will be handled on SCM. Is Jenkins SCM API providing generic way to authenticate against stored credentials in jenkins ?
If it would be the case, it would be great !

@Henri Dependency against core is the burden of every plugin maintainers.
But I don't know there is a better way to handle this.
This was the intention of the plugin-compat-tester .. but I didn't have enough time recently to improve it

@Nicolas The main goal of maven parent is to provide some tricky things like the plexus components merging.
... Only needed if we stay with maven-scm-api.
If there isn't any tricky build part, no parent will be needed.

@Frédéric well we should be moving authentication credential storage to the credentials-plugin.

I was discussing with @Nicolas what needs to be done to get, e.g. subversion-plugin using the credentials-plugin. There is a number of things that I would like to see in terms of additions to the credentials-plugin API that should take place before wiring it up to more plugins.

The point of getting credentials 1.0 out was to let the API soak some more. After over a year of soaking I am mostly happy with the core of the API.

Where I feel there are gaps are with respect to grouping credentials and providing an easy way for consumers to retrieve credentials.

I am leaning towards adding Hamcrest matchers as a dependency, with methods for using those matchers to select a sub-set of credentials.

Additionally I am thinking of adding some grouping extension point to allow grouping related credentials together.

Finally, there needs to be a credential mapper extension point, thus you could have

A grouping that reflects, e.g. an Active Directory / LDAP domain.
Within the group a User/Password pair
A credential mapper from User/Password to SSH User/Password
A credential mapper from User/Password to HTTP(s) User/Password
A credential mapper from User/Password to SVNSERVE User/Password

Then the Credential consumer can ask for credentials within a Jenkins scope (i.e. specific job) for a specific user, against a specific host (which the grouping then matches) and for a specific protocol

The user, on the other hand, sees just the one credential in the one group, and changing that password updates all of that credential's use by Jenkins in one go.

The bits I need to refine are:

• Credential mapper - and when a credential mapper should not be employed, e.g. if the SSH password is different in that scope for the same user name and there already is a SSH credential defined in the group
• Credential group extension point - how to handle matching which group is appropriate... maybe not needed, if the group is just a "name" but it would be nice to have a better solution.
• Whether to expose hamcrest matchers directly (pushing the API into Jenkins Core effectively as credentials is now in core) or whether to copy the "nice" bits of Hamcrest and do an NIH... leaning towards exposing as Hamcrest seems to be good at maintaining backwards compatibility (unlike some others... I'm looking at you BouncyCastle)

Then the final bits should actually be mostly trivial as there are very few authentication schemes that would need to be handled. (user/pass, user/key, client certificate. I think that is all)

@Nicolas & @Stephen I created JENKINS-18129 which represent a different concern than current issue to my POV
It will be better to discuss there instead of noising current comments

I think split into multiple plugins is a good solution.

I think this refactor must address credentials topic. May be the maven-scm plugin can be remove for a simplest one, I had bad memories about patches to add git support.

I'm ok to move the git support to the new architecture.

The scm sync configuration plugin is deprecated. No further work is expected on the plugin.

Users of this plugin are encouraged to migrate their jobs to Pipeline Plugin, so that their jobs will be specified in pipeline code that can be checked into an SCM, all without using the SCM Sync configuration plugin.

Users of this plugin are also encouraged to use the Configuration as Code Plugin to specify the configuration of their Jenkins server in a file which can be checked into an SCM, all without using the SCM Sync configuration plugin.