-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Jenkins 2.69
Artifactory Plugin 2.12.2 + a few unreleased PRs, see https://github.com/reversefold/artifactory-plugin/commits/artifactory-2.12.2-shn
If the very first build of a maven job on jenkins is a release build the artifactory plugin will not change the versions of the pom.xml files, causing the build to be a release build. This is due to this logic running before the maven plugin parses the pom.xml files. In the case of the first build this means that it changes no versions and the build is a snapshot.
I have not verified this but I believe that this would also cause any new modules added between the last build and the release build to not have their versions changed as the new pom.xml contents will not be parsed until after the version changing logic is run.
In MavenReleaseWrapper.java in the artifactory-plugin the changeVersions() method, which relies on the pom.xml data, is called during setUp():
https://github.com/jenkinsci/artifactory-plugin/blob/master/src/main/java/org/jfrog/hudson/release/maven/MavenReleaseWrapper.java#L174
In MavenModuleSetBuild.java in the maven-plugin:
setUp() on the wrappers is called on line 667:
https://github.com/jenkinsci/maven-plugin/blob/master/src/main/java/hudson/maven/MavenModuleSetBuild.java#L667
parsePoms() is called on line 691:
https://github.com/jenkinsci/maven-plugin/blob/master/src/main/java/hudson/maven/MavenModuleSetBuild.java#L691
The parsePoms() line has a reference to issue #5428 (JENKINS-5428). This caused parsePoms() to be moved after the setUp() steps. There was another issue opened, JENKINS-7985, which comments that the change caused other issues. This is another issue caused by this change.
I looked a little into fixing the new issue but since the current code relies on the behavior of the maven-plugin I'm not sure what the right fix is. According to JENKINS-5428 some plugins might alter (or generate) the pom.xml files, so it makes sense for the plugins to run their logic before the poms are parsed. This causes a chicken-and-egg problem for the artifactory plugin, though, as it currently requires the pom.xml files to be parsed before it will change the versions. It is, however, modifying the pom.xml files, so it makes sense for it to make its changes before the pom.xml files are parsed. This could cause even more troubles if this plugin is used in conjunction with a plugin which generates the pom.xml files as I'm not sure there is a way to specify their ordering.
The best fix I can think of would be for the artifactory-plugin to force itself to be the last thing run before a build, parse the pom.xml files itself (or somehow through the maven-plugin's support), change the versions, then allow the maven plugin to parse the pom.xml files for use during the build. Another fix might be to inject the version change as the first step in the Build phase and to somehow tell the maven-plugin to reparse the pom.xml files. Thinking more on this, the best thing might be for the maven-plugin to go ahead and (try to) parse the pom.xml files before any wrapper runs its setUp logic, then to expose a way for the plugin to flag that it has made changes to the pom.xml files so that the maven-plugin can re-parse them for the next wrapper or step.