-
15. Re: Shared Parent POM for dependencyManagement
This is not meant to resolve circular dependencies. This is to make sure we have a common base for all components.
It should not list any jboss-as or jboss-ejb3 versions, because they are on top of this base.
Theoretically some dependencies should be removed from jboss-as as jboss-ejb3 (or another) is authoritive on it. But lets leave that beyond scope for the moment. -
16. Re: Shared Parent POM for dependencyManagement
"pgier" wrote:
Yes, normally this would work and the explicit dependency would win. The problem in some of our dependency trees has to do with artifacts that changed their name. So maven doesn't know that these two are really different versions of the same thing.
AS --> ejb3 --> jboss-logging-jdk
AS --> jboss-common-logging-jdk
The transitive one might actually come first in the classpath, because maven builds the tree doing a depth first traversal (This appears to be fixed in 2.0.9 http://jira.codehaus.org/browse/MNG-1412). So jboss-logging-jdk needs to be excluded from the ejb3 dep tree in the AS dependencies.
So the important bit is to make sure we fix those duplicate imports. -
17. Re: Shared Parent POM for dependencyManagement
"dimitris@jboss.org" wrote:
So the important bit is to make sure we fix those duplicate imports.
It's more complicated than that.
Let me give you an example of why the maven transitive dependencies
stuff is broken (or at least impossible to manage effectively).
X->Y means X depends on Y
Lets suppose you have a util project with two versions
common-core:1.0.0
common-core:1.0.1
then you have
jbossxb:2.0.0 -> common-core:1.0.0
Now you have a project that uses both (but a different version of common-core)
jbossmc:2.0.0 -> jbossxb:2.0.0
jbossmc:2.0.0 -> common-core:1.0.1
Which gets used? common-core:1.0.1 of course (it is explicit)
You have another project that does
jboss-deployers:2.0.0 -> jbossmc:2.0.0
jboss-deployers:2.0.0 -> jbossxb:2.0.0
Now which version of common-core gets used?
The answer is common-core:1.0.1 because jbossmc is first in the list
Finally here's the problem
jbossas:5.0.0 -> jboss-deployers:2.0.0
jbossas:5.0.0 -> jbossxb:2.0.0
The version that gets used is common-core:1.0.0
Why?
Even though jboss-deployers resolves to common-core:1.0.1 and it
is first on the list, its link to common-core is two steps away,
but jbossxb's link is one step away.
Stupid.
The only answer is go through all the poms and check them
(what I call baby sitting).
if you get the wrong answer then either do an exclusion or list the
dependency you want explicitly.
BUT DO YOU REALLY KNOW THAT YOU SHOULD BE USING common-core:1.0.1?
What if you listed jbossxb before jboss-deployers in the jbossas project?
The fundamental problem is that maven has no idea that 1.0.1 is after 1.0.0
and that regardless of where it is in the dependency hierarchy it should be used.
The other approach is to list everything explicitly in every project
but you've still got to "babysit" your pom when you upgrade dependencies
to see wether its transitive dependencies are later and therefore need
updating in your project. -
18. Re: Shared Parent POM for dependencyManagement
I'm surprised maven doesn't understand versioning (1.0.1 > 1.0.0).
For peace of mind, I would go with top level explicit dependencies; and educate people how this is supposed to work.
Otherwise we could be looking at 'build tragic - take2'.
Thanks for detailed example. -
19. Re: Shared Parent POM for dependencyManagement
If we can't have a pluggable resolver, then we must at least get an exception if there is a version conflict. It is already happening that the wrong version is showing up at the end.
I'm not going to babysit poms. -
20. Re: Shared Parent POM for dependencyManagement
"wolfc" wrote:
then we must at least get an exception if there is a version conflict. It is already happening that the wrong version is showing up at the end.
I'm not going to babysit poms.
My question still stands (for Dimitris as well),
how do you know what the correct version is?
e.g. suppose jbossas upgraded ejb3 to 3.0.1 which requires xyz:1.0.1
some other project uses xyz:1.0.0
JBossAS updates its pom to xyz:1.0.1 thereby saying the issue/conflict is resolved
Later ejb3:3.0.2 says xyz:1.0.2 is required,
how does it know that the xyz:1.0.1 in the jbossas pom isn't already resolving the conflict?
Sure you could add a constraintxyz:[1.0.2,)
But then how do you reproduce your build?
i.e. you need to choose a specific version in your pom.xml that gets tagged in svn,
but still have the open constraint in the one that goes in the repository.
Has anybody tried this, does it work?
Does it play nicely with snapshots? :-) -
21. Re: Shared Parent POM for dependencyManagement
Sat in on Freenode #maven for a bit tonight to see if I could sort some of this out. Brian Fox of the Maven PMC was very helpful; I'll attach some relevant snippets below and a link to the full (edited for brevity) transcript at the end.
"dimitris@jboss.org" wrote:
I'm surprised maven doesn't understand versioning (1.0.1 > 1.0.0)"#maven" wrote:
Brian: Will Maven know that 1.0.0 is less than 1.0.1? -> yes.
Brian: the next thing: The fundamental problem is that maven has no idea that 1.0.1 is after 1.0.0 ... isn't true
---"adrian@jboss.org" wrote:
Now which version of common-core gets used?
The answer is common-core:1.0.1 because jbossmc is first in the list"#maven" wrote:
Brian: "The answer is common-core:1.0.1 because jbossmc is first in the list" ... is also not true
ALR: "Closest wins", you mean.
Brian: it will use 1.0.1 because it's comparing at the same level
Brian: right. closest wins applies first
---
Some additional insight that might help us:"#maven" wrote:
Brian: ok, so a few things that might not be known..
ALR: All ears.
Brian: dependencyManagement will apply to transitive dependencies since 2.0.6
Brian: so your common-core thing... if you put that in depMgt, all that first discussion goes away. it will be what you set (provided it's not defined anywhere else)
This is the main suggestion; use "dependencyManagement" more frequently than simple "dependency"."#maven" wrote:
Brian: the other thing to know, specifying a version like "1.0" is just a suggestion
Brian: technically the range is [,] with a recommendation on 1.0
Brian: so that means that [1.0] is very different.
Brian: so that's another way to influence the resolution. It's probably not the best way to do it though
ALR: Meaning, "[1.0]" is concrete.
ALR: And "1.0" is suggested?
Brian: correct
Brian: 1.0 means you want 1.0 but it lets maven have the flexibility to choose
Brian: [1.0] means that's the only thing you can get. It _should_ either give you 1.0 or fail the build because there's a conflict
ALR: And what if we specify [1.0] somewhere, and [1.1] is somewhere else transitively?
Brian: it should fail
ALR: :)
Brian: i think this is a heavy handed approach that may make things worse
ALR: Brian: But it gives us fail-fast.
Brian: yes. You could also use the enforcer for that
So we can also look at locking down versions by placing them in brackets, forcing a version conflict failure if there's a problem. Brian alludes to some problems here; I'm not sure in which way these might manifest themselves.
Also worth a look is the Enforcer Plugin http://maven.apache.org/plugins/maven-enforcer-plugin/.
Edited transcript: http://www.alrubinger.com/jboss/pound-maven.txt
S,
ALR -
22. Re: Shared Parent POM for dependencyManagement
"ALRubinger" wrote:
PS - I'm not married to the name "component-matrix", but "build" sounded redundant and non-deterministic. Suggestions?
Diesler suggested "dependency" on the dev-list.
S,
ALR -
23. Re: Shared Parent POM for dependencyManagement
I have committed org.jboss.jbossas:jboss-as-dependency:
http://jira.jboss.com/jira/browse/JBAS-5324
Looking to avoid being too invasive here. The shared POM is now committed and deployed for review, though I'm holding the commit for org.jboss.jbossas:jboss-as-parent until we can verify that all looks allright. Once Paul gives me the nod, I'll commit that change.
The patch up for review is attached to the JIRA, as is the commit of the new project.
Paul, let's look over this together.
S,
ALR -
24. Re: Shared Parent POM for dependencyManagement
This new pom.xml as it is now contains, more or less, all the AS depedencies. Moving that outside AS looks dump to me. Everytime we need to change a component in AS, we'll need to make a new release of this project?
-
25. Re: Shared Parent POM for dependencyManagement
"dimitris@jboss.org" wrote:
This new pom.xml as it is now contains, more or less, all the AS depedencies. Moving that outside AS looks dump to me. Everytime we need to change a component in AS, we'll need to make a new release of this project?
Until the versions for a release are locked down, it's a snapshot. How difficult is "mvn deploy"?
S,
ALR -
26. Re: Shared Parent POM for dependencyManagement
"ALRubinger" wrote:
I have committed org.jboss.jbossas:jboss-as-dependency:
http://jira.jboss.com/jira/browse/JBAS-5324
Looking to avoid being too invasive here. The shared POM is now committed and deployed for review, though I'm holding the commit for org.jboss.jbossas:jboss-as-parent until we can verify that all looks allright. Once Paul gives me the nod, I'll commit that change.
The patch up for review is attached to the JIRA, as is the commit of the new project.
Paul, let's look over this together.
S,
ALR
Hey Andrew, I think it's fine to commit this, except for the prerequisites section (maven 2.0.8). I think that should stay in the jbossas parent because it doesn't get inherited. If ejb also requires 2.0.8 you'll have to define it in that parent also.
Also, I must have committed the 2.2-beta-3-SNAPSHOT version of the assembly plugin by mistake. I was working with that locally, but the one in the pom should be 2.2-beta-2. -
27. Re: Shared Parent POM for dependencyManagement
"ALRubinger" wrote:
"ALRubinger" wrote:
PS - I'm not married to the name "component-matrix", but "build" sounded redundant and non-deterministic. Suggestions?
Diesler suggested "dependency" on the dev-list.
S,
ALR
I think I like component-matrix better ;-) Or maybe dependency-matrix. Just "dependency" by itself seems too generic. -
28. Re: Shared Parent POM for dependencyManagement
"pgier" wrote:
Also, I must have committed the 2.2-beta-3-SNAPSHOT version of the assembly plugin by mistake. I was working with that locally, but the one in the pom should be 2.2-beta-2.
Sorry, you can ignore this part, since I see it is already set to 2.2-beta-2. I misunderstood some messages in my local environment. -
29. Re: Shared Parent POM for dependencyManagement
"ALRubinger" wrote:
So we can also look at locking down versions by placing them in brackets, forcing a version conflict failure if there's a problem. Brian alludes to some problems here; I'm not sure in which way these might manifest themselves.
No we should use constraints (version ranges). But we need to understand
how that interacts with the release process and reproducability of tagged versions.
Specific versions is just a very restrictive form of version constraint
that will make it virtually impossible to upgrade projects without also doing
dummy releases of other projects to change their constraints to agree.