-
1. Re: MAVEN: build change
adrian.brock Jul 11, 2007 10:03 AM (in response to kconner)Can you explain what the pros and cons are?
I asked for all dependencies to be explicitly listed in the super pom in the build project
and only that version used.
I don't know whether Maven supports such a configuration.
i.e.
1) raise an error if there is a conflict
2) raise an error for non-explicit transitive dependencies
I know there are reports that can be run, but as far as I am aware nobody is doing that
(or a way to enforce it). Checking it just before a release is really too late.
It would mean redoing all the testing with new dependencies.
It would have to be done on all dependent projects as well, e.g. the current common
release is a mess as far as this concerned. Even its own internal project
references are out-of-step. :-) -
2. Re: MAVEN: build change
adrian.brock Jul 11, 2007 10:13 AM (in response to kconner)And the same is true of the our build:
e.g.[ejort@warjort microcontainer]$ grep -ri jboss-test * aop-mc-int/.classpath: <classpathentry kind="var" path="M2_REPO/jboss/jboss-test/1.0.3.GA/jboss-test-1.0.3.GA.jar"/> aop-mc-int/pom.xml: <artifactId>jboss-test</artifactId> aop-mc-int/.svn/text-base/pom.xml.svn-base: <artifactId>jboss-test</artifactId> aop-mc-int/.svn/text-base/.classpath.svn-base: <classpathentry kind="var" path="M2_REPO/jboss/jboss-test/1.0.3.GA/jboss-test-1.0.3.GA.jar" sourcepath="M2_REPO/jboss/jboss-test/1.0.3.GA/jboss-test-1.0.3.GA-sources.jar"/> classloader/.classpath: <classpathentry kind="var" path="M2_REPO/jboss/jboss-test/1.0.4-SNAPSHOT/jboss-test-1.0.4-SNAPSHOT.jar"/> classloader/pom.xml: <artifactId>jboss-test</artifactId>
This example leads to "IncompatibleClassChangeError" when running tests under eclipse. -
3. Re: MAVEN: build change
kconner Jul 11, 2007 10:15 AM (in response to kconner)"adrian@jboss.org" wrote:
Can you explain what the pros and cons are?
The negative side is that the transitive dependency analysis performed by certain versions of maven appears to be flawed. The specific example I had this morning was caused by the inclusion of two different versions of jboss-test in our poms. The old version was disabled but this also disabled some of the dependencies of the newer version!
The consequence of this was that a number of tests within deployers-vfs were failing because the oswego library was no longer on the classpath."adrian@jboss.org" wrote:
I asked for all dependencies to be explicitly listed in the super pom in the build project and only that version used.
This is what I have done. They are now listed in dependencyManagement sections and these supplement the dependency specifications in the pom. This can still be overridden locally if needed."adrian@jboss.org" wrote:
I don't know whether Maven supports such a configuration.
i.e.
1) raise an error if there is a conflict
2) raise an error for non-explicit transitive dependencies
I don't believe there is any way to force the build to terminate if you have a conflict. The resolution mechanism gives precedence to the version which is configured closest to the pom IIRC, unless it is specified in the dependencyManagement section."adrian@jboss.org" wrote:
It would have to be done on all dependent projects as well, e.g. the current common
release is a mess as far as this concerned. Even its own internal project
references are out-of-step. :-)
Yes, that would also need checking in that case. -
4. Re: MAVEN: build change
adrian.brock Jul 11, 2007 10:34 AM (in response to kconner)"Kevin.Conner@jboss.com" wrote:
I don't believe there is any way to force the build to terminate if you have a conflict. The
resolution mechanism gives precedence to the version which is configured closest to the
pom IIRC, unless it is specified in the dependencyManagement section.
What I want to be able to say is in "build"
'the common version for jboss-test is 1.4-SNAPSHOT"
in one of the projects
'I use jboss-test"
so it is a dependency of my project.
I don't want all the dependencies from "build" being dragged through into my project.
Is that how it works?
If so, then we can add a big warning in each pom.<!-- SPECIFY THE VERSION YOU WANT TO USE IN ../build/pom.xml NOT HERE -->
-
-
6. Re: MAVEN: build change
kconner Jul 11, 2007 10:40 AM (in response to kconner)"adrian@jboss.org" wrote:
What I want to be able to say is in "build"
'the common version for jboss-test is 1.4-SNAPSHOT"
in one of the projects
'I use jboss-test"
so it is a dependency of my project.
The dependencyManagement section specifies the version and scope of the dependency. You would still specify the dependency in the pom but would not require the version nor the scope."adrian@jboss.org" wrote:
I don't want all the dependencies from "build" being dragged through into my project.
They won't be, this is the dependency metadata."adrian@jboss.org wrote:
If so, then we can add a big warning in each pom.<!-- SPECIFY THE VERSION YOU WANT TO USE IN ../build/pom.xml NOT HERE -->
Sounds like a good idea to me :) -
7. Re: MAVEN: build change
kconner Jul 12, 2007 12:02 PM (in response to kconner)Should I commit the pom changes?
With our stuff tidied up there are still a few conflicts
* javassist/javassist/3.5-SNAPSHOT/javassist-3.5-SNAPSHOT.jar
org/jboss/javassist/3.6-beta/javassist-3.6-beta.jar
javax/activation/activation/1.1/activation-1.1.jar
sun-jaf/activation/1.0.2/activation-1.0.2.jar
ant/ant/1.6.5/ant-1.6.5.jar
* org/apache/ant/ant/1.7.0/ant-1.7.0.jar
* - we include these explicitly
I also noticed that the deployers project is still present, was this not replaced by all the deployer-* projects? -
8. Re: MAVEN: build change
adrian.brock Jul 12, 2007 12:19 PM (in response to kconner)Yes, commit them.
We should be using the latest of everything I think so we can find the problems earlier.
There's a long discussion on sun-jaf, what uses ant?
The deployers project just needs archiving somewhere. -
9. Re: MAVEN: build change
kconner Jul 12, 2007 1:11 PM (in response to kconner)"adrian@jboss.org" wrote:
Yes, commit them.
Okay, will do."adrian@jboss.org" wrote:
We should be using the latest of everything I think so we can find the problems earlier
I'll update javassist in that case."adrian@jboss.org" wrote:
There's a long discussion on sun-jaf, what uses ant?
Sorry, my mistake. The only explicit part where ant is mentioned is within aop-mc-int (ant-junit is part of the build).
The dependencies are showing jboss-aop using ant 1.6.5 and jboss-test using 1.7.0."adrian@jboss.org" wrote:
The deployers project just needs archiving somewhere.
In subversion not sufficient for this? -
10. Re: MAVEN: build change
adrian.brock Jul 12, 2007 1:24 PM (in response to kconner)"Kevin.Conner@jboss.com" wrote:
"adrian@jboss.org" wrote:
The deployers project just needs archiving somewhere.
In subversion not sufficient for this?
Yes, but svn is a tool. It can do
svn move url-of-deployers somewhere-else
but it can't decide what the value of somewhere-else should be. :-) -
11. Re: MAVEN: build change
kconner Jul 12, 2007 1:31 PM (in response to kconner)"adrian@jboss.org" wrote:
Yes, but svn is a tool. It can do
svn move url-of-deployers somewhere-else
but it can't decide what the value of somewhere-else should be. :-)
I guess I was thinking more along the lines ofsvn delete deployers svn co -r XXXX
:) -
12. Re: MAVEN: build change
adrian.brock Jul 12, 2007 1:54 PM (in response to kconner)Ok, if you tag it first, so it is easy to find.
-
13. Re: MAVEN: build change
kconner Jul 12, 2007 2:37 PM (in response to kconner)I have checked in the modified poms and regenerated the eclipse project/classpath files.
Can someone please check and see if anything is amiss? -
14. Re: MAVEN: build change
kconner Jul 12, 2007 2:44 PM (in response to kconner)"adrian@jboss.org" wrote:
Ok, if you tag it first, so it is easy to find.
It looks as if the changes were made in revision 63690, so I'll tag revision 63689. Any preference for a name?