-
Bug
-
Resolution: Won't Fix
-
Major
-
None
-
Platform: All, OS: All
When setting up multiple Maven2 projects with the dependencies specified as
version ranges, Hudson doesn't trigger downstream builds if a built version of a
dependency matches the version range as specified in the downstream project.
The above URL points to my mail in the Hudson users list archive. It describes
the setup I used to detect this defect.
From the sources: the culprit is in hudson.model.MavenModule, method
buildDependencyGraph(DependencyGraph), line 355:
MavenModule src = modules.get(d);
modules is a HashMap with ModuleDependency objects as the key. All
ModuleDependency objects in there have a normal version number since they
represent the version information from the modules themselves.
On the other hand, the lookup with ModuleDependency 'd' can contain a version
range as the version string. Since the key lookup in the Hashmap works using the
equals method of ModuleDependency, even if the range matches according the Maven
versioning concepts, there will be no match from this lookup.
I think the best way to solve this is to incorporate the usage of the following
Maven2 interface and classes:
org.apache.maven.artifact.versioning.ArtifactVersion
org.apache.maven.artifact.versioning.DefaultArtifactVersion
org.apache.maven.artifact.versioning.VersionRange
The last class has the most interesting method ever:
VersionRange.containsVersion(ArtifactVersion)
I'll see if I can find the time to create a patch...
Ringo
- is duplicated by
-
-
- Resolved
-
[JENKINS-2787] Hudson doesn't support Maven2 dependency version ranges
Koshuke,
I attached an initial version of a patch supporting Maven2 dependency version
ranges. I took the shortest path possible as you can probably see. However, it
doesn't work completely as expected and I need a bit of input here.
My Hudson test setup has the same set of Maven2 projects setup twice. Once in a
normal way with the dependency version ranges, and once via an active profile,
specified in the Maven2 goals and options field (-P the-profile). The profile
redefines the version property to become a SNAPSHOT-to-SNAPSHOT dependency chain
between all modules.
With the patch applied, my Hudson Maven module for pres.d:9.10.2 (a released
version) eventually gets "app.d 9.10" and "app.d 9.10.x" as downstream
dependencies. The former app.d is the one with the active profile, which I
expect not to match since the dependency should be 9.10-SNAPSHOT and not the
version range.
Now my question: where are the active profiles taken into account when building
the dependency graph? It seems to work for the SNAPSHOT-to-SNAPSHOT dependency
chain...
Ringo
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
kutzi
added a comment - Hmm, this is rather old and a lot has changed in the maven plugin in the mean time.
Is this still a problem with current Jenkins versions?
kutzi
added a comment - Hmm, this is rather old and a lot has changed in the maven plugin in the mean time.
Is this still a problem with current Jenkins versions? 
Clément Caron
added a comment - Hello,
I still have the problem with the current version of Jenkins, the range works well on my computer using only maven, but doesn't work on my server using Jenkins.
Any news about this issue ?
Clément Caron
added a comment - Hello,
I still have the problem with the current version of Jenkins, the range works well on my computer using only maven, but doesn't work on my server using Jenkins.
Any news about this issue ? kutzi
added a comment - No, not yet.
I'll have a look at the patch, but I cannot make any promises on the timeframe.
kutzi
added a comment - No, not yet.
I'll have a look at the patch, but I cannot make any promises on the timeframe. Clément Caron
added a comment - In fact, it depends of the build plugin I think...
On my Jenkins, poms build with maven-assembly-plugin works fine with version range, but those using maven-petals-plugin don't. I'm looking if there is an issue about version range compatibilities with maven-petals-plugin.
Clément Caron
added a comment - In fact, it depends of the build plugin I think...
On my Jenkins, poms build with maven-assembly-plugin works fine with version range, but those using maven-petals-plugin don't. I'm looking if there is an issue about version range compatibilities with maven-petals-plugin. kutzi
added a comment - Clément, this issue is about the automatic job dependency detection in Jenkins based on the POMs and not about some general build problems. Are you sure, we are talking about the same problem?
Or asked otherway: what is your concrete problem with the dependency ranges?
kutzi
added a comment - Clément, this issue is about the automatic job dependency detection in Jenkins based on the POMs and not about some general build problems. Are you sure, we are talking about the same problem?
Or asked otherway: what is your concrete problem with the dependency ranges? Clément Caron
added a comment - After reading it carefully, it seems not to be the same problem, I skimmed through the issue 
.
Mine is just about a Project build with version range, not the automatic downstream builds...
Sorry about that, I'll read carefully next time 
.
Clément Caron
added a comment - After reading it carefully, it seems not to be the same problem, I skimmed through the issue .
Mine is just about a Project build with version range, not the automatic downstream builds...
Sorry about that, I'll read carefully next time . 
Created an attachment (id=497)
Initial cut at support for Maven2 dependency version ranges