Starting with version 3.2.0, the buildnumber-maven-plugin switched from using maven-scm-provider-svnexe to maven-scm-provider-svnjava for SVN repositories. This change broke our build because we rely on Integrated Windows Authentication (IWA) with our SVN server, and maven-scm-provider-svnjava does not support IWA.
Details
- Both
SvnJavaScmProvider and SvnExeScmProvider are registered for the same role: svn This creates a conflict, and the chosen provider depends on the discovery process.
SvnJavaScmProvider still uses deprecated Plexus Containers for dependency injection, whereas SvnExeScmProvider now uses Eclipse Sisu.- This difference might explain why the discovery order changed in recent versions.
- There is currently no way to exclude the dependency on
maven-scm-provider-svnjava.
- The plugin no longer works in environments that require IWA authentication for SVN.
Suggestion
Wouldn’t it be better if the plugin did not include provider dependencies by default, allowing end users to choose the appropriate provider? This approach is already documented for other SCM providers (e.g., Perforce example).
Starting with version 3.2.0, the
buildnumber-maven-pluginswitched from usingmaven-scm-provider-svnexetomaven-scm-provider-svnjavafor SVN repositories. This change broke our build because we rely on Integrated Windows Authentication (IWA) with our SVN server, andmaven-scm-provider-svnjavadoes not support IWA.Details
SvnJavaScmProviderandSvnExeScmProviderare registered for the same role: svn This creates a conflict, and the chosen provider depends on the discovery process.SvnJavaScmProviderstill uses deprecated Plexus Containers for dependency injection, whereasSvnExeScmProvidernow uses Eclipse Sisu.maven-scm-provider-svnjava.Suggestion
Wouldn’t it be better if the plugin did not include provider dependencies by default, allowing end users to choose the appropriate provider? This approach is already documented for other SCM providers (e.g., Perforce example).