[Design the new POJO MicroContainer] - Re: MAVEN: build change
by Kevin.Conner@jboss.com
"adrian(a)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(a)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(a)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(a)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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062999#4062999
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062999
18 years, 9 months
[Design the new POJO MicroContainer] - Re: MAVEN: build change
by adrian@jboss.org
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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062998#4062998
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062998
18 years, 9 months
[Design the new POJO MicroContainer] - Re: MAVEN: activation-1.0.2.jar not being fetched
by pgier
"adrian(a)jboss.org" wrote : "pgier" wrote :
| | If you try to download from the old location, it should give you a message that you need to point to the new location.
|
| What do you mean "give you a message"?
| Why didn't Kabir's build pick up the same thirdparty dependencies that my build does?
|
| This is the key issue that needs to be resolved. How do we know this build is
| reproducable given we're likely to have any old rubbish in our local repositories
| from other maven builds?
|
| i.e. How can we be sure that we can checkout the JBossMC-2.0.0.GA tag from SVN
| and rebuild the same binaries as we had when it was released 6 months earlier?
|
It should display a warning similar to this if you use the old location (sun-jaf):
| [WARNING] While downloading sun-jaf:activation:1.0.2
| This artifact has been relocated to javax.activation:activation:1.0.2.
| This file has been relocated based on maven recommendations: http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html
|
I'm thinking that the best way to handle reproducing old builds is to keep a copy of the contents of the local repo when doing a release. That way if an old release needs to be rebuilt, the local repository can be refreshed, and the build can be done off-line.
I think the amount of "old rubbish" in our repository will be increased if we can never make any changes to files or directory locations. If we keep our release builds off-line without using any remote repository and we save the build environment, then we can be sure that we can redo the build. None of this is set up yet, but it is probably what needs to be done.
Does this sound like a better solution?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062993#4062993
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062993
18 years, 9 months