Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
Hudson 1.395
Description
When using uniqueVersion == true with Maven deployments for artifacts that have attached artifacts (specifically hpi artifacts in this case...) I've observed the following behavior:
- MavenArtifactRecord.deploy for pom and main artifact (hpi) occurs as expected, assigning unique version in sequence (i.e. "-5")
- When MavenArtifactRecord.deploy reaches the iteration for .attachedArtifacts (line #128) and begins deploying these the unique version will be incremented (i.e. "-6")
- I've confirmed that when the artifact is "transformed" by the SnapshotTransformer, specifically line #104, that an incorrect "nextBuildNumber" is determined. This is due to #resolveLatestSnapshotBuildNumber (line 151) returning the "current" build number.
This seems to be a regression for 1.395 as the same setup worked fine in 1.383
Attachments
Issue Links
- is duplicated by
-
-
- Closed
-
Activity
Jason Stiefel
added a comment - Olamy-
I've solved this in the interim by creating my own artifact promoter using Aether. If you would be interested in looking at my solution please let me know.
Jason Stiefel
added a comment - Olamy-
I've solved this in the interim by creating my own artifact promoter using Aether. If you would be interested in looking at my solution please let me know. 
Olivier Lamy
added a comment - Nice do you have time to provide a patch ?
Thanks ! Jason Stiefel
added a comment - Well it's less a matter of time and more a question of how you'd like to approach a final solution. My implementation is intended to be extensible (eventually support non-maven artifacts) and also compatible with the Promoted Builds plugin. Here's the breakdown-
- Recorder implementation that converts MavenArtifactRecords into an intermediate dto that implements my "Promotable" interface. Once converted (or wrapped really) into Promotable it delegates to:
- A "Promoter" (AetherPromoter in this case) that is constructed from (credentials, localRepository, remoteRepositories[]). The promoter then uses Aether to upload the artifacts. My implementation uses the artifact version to determine whether it should aim for the snapshots or releases repositories, but then I'm building towards a more integrated target where my Nexus instance is actually deployed as part of the overall CI server (this approach removes the "repository url" configuration from the job entirely- the repo locations are known. however I could see value in being able to define the repo releases and snapshots repos at both a global level and optionally override at a job level...)
This process may be a little too specific for the core maven-plugin, or it may be just what the core needs as a start towards using Aether and Maven repositories in general for arbitrary binary artifact storage. Your call, share your thoughts and I'll see how quickly I can "generalize" this and to what extent.
Jason Stiefel
added a comment - Well it's less a matter of time and more a question of how you'd like to approach a final solution. My implementation is intended to be extensible (eventually support non-maven artifacts) and also compatible with the Promoted Builds plugin. Here's the breakdown-
Recorder implementation that converts MavenArtifactRecords into an intermediate dto that implements my "Promotable" interface. Once converted (or wrapped really) into Promotable it delegates to:
A "Promoter" (AetherPromoter in this case) that is constructed from (credentials, localRepository, remoteRepositories[]). The promoter then uses Aether to upload the artifacts. My implementation uses the artifact version to determine whether it should aim for the snapshots or releases repositories, but then I'm building towards a more integrated target where my Nexus instance is actually deployed as part of the overall CI server (this approach removes the "repository url" configuration from the job entirely- the repo locations are known. however I could see value in being able to define the repo releases and snapshots repos at both a global level and optionally override at a job level...)
This process may be a little too specific for the core maven-plugin, or it may be just what the core needs as a start towards using Aether and Maven repositories in general for arbitrary binary artifact storage. Your call, share your thoughts and I'll see how quickly I can "generalize" this and to what extent. Olivier Lamy
added a comment - fixed in more simple way.
Will be in 1.398 Code changed in jenkins
User: Olivier Lamy
Path:
maven-plugin/pom.xml
maven-plugin/src/main/java/hudson/maven/reporters/MavenArtifact.java
maven-plugin/src/main/java/hudson/maven/reporters/MavenArtifactRecord.java
test/pom.xml
test/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java
test/src/test/java/hudson/maven/RedeployPublisherTest.java
test/src/test/java/hudson/model/AbstractProjectTest.java
http://jenkins-ci.org/commit/core/b3b4ccb0f23bf1769d91ee7535d054ef1937953e
Log:
JENKINS-8651 Maven deployment with uniqueVersion == true creating "new" versions for attached artifacts
Code changed in jenkins
User: Olivier Lamy
Path:
pom.xml
src/main/java/hudson/maven/reporters/MavenArtifact.java
src/main/java/hudson/maven/reporters/MavenArtifactRecord.java
http://jenkins-ci.org/commit/maven-plugin/595199a20193c71f18783c81b5d0949a06668224
Log:
JENKINS-8651 Maven deployment with uniqueVersion == true creating "new" versions for attached artifacts
Originally-Committed-As: b3b4ccb0f23bf1769d91ee7535d054ef1937953e
Code changed in jenkins
User: Olivier Lamy
Path:
test/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java
http://jenkins-ci.org/commit/jenkins-test-harness/f06684aee169d83c331ab53a36f201e628d384a5
Log:
JENKINS-8651 Maven deployment with uniqueVersion == true creating "new" versions for attached artifacts
Originally-Committed-As: b3b4ccb0f23bf1769d91ee7535d054ef1937953e
@Olamy-
Thanks for looking into it. Very frustrating problem for me right now. I have confirmed that the same behavior is exhibited when I overload MavenArtifactRecord.deployArtifact to use the "default" Maven Deployer rather than the "maven2" implementation you added back in December.
The upside to switching to the built-in artifact deployer was that I can finally use the httpclient wagon provider for uploads, which was a really nice find while debugging the original issue of incrementing snapshot versions
As a bit more detail here's what I'm seeing uploaded into Nexus for a single build:
mygroup:myartifact:1.8-SNAPSHOT,2343434-1:pom
mygroup:myartifact:1.8-SNAPSHOT,2343434-1:hpi
mygroup:myartifact:1.8-SNAPSHOT,2343435-2:jar <- Where this is the "attached" artifact on the build.
I had thought earlier that the timestamps were identical but noticed later on that might have been a fluke and the timestamp will fluctuate a bit between the pom+main and attached artifacts. In the maven-metadata.xml I see 3 artifacts listed, each with different extension elements: pom, hpi and jar. Only the jar shows as build #2 and that's also listed as the "current build". So when I go to grab the latest snapshot of the hpi artifact- it's not found as there is no hpi artifact in build #2, just the jar.
Please let me know if I can provide additional detail. I'm even happy to submit a patch if you have a suggestion on where I should "fix" this!