I'll go through root pom.xml to see what are the differences with build/build-thirdparty.xml when it was removed. Adrian Brock wrote:

Adrian Brock wrote: Have you tried using the dependency plugin to clear only the dependencies for the project you're releasing? Sometimes this helps me quite a bit: mvn dependency:purge-local-repository S, ALR

Scott M Stark wrote: Sure, we can tie it into the Maven lifecycle in a top-level parent somewhere. Problem is, I often get errors on the purge-local-repository task during re-resolution (try this on EJB3 Aggregator trunk/pom.xml). To avoid this I have to set -DreResolve=false. However, if we make it a default, now we've got builds that'll take forever. Pretty useful as routine maintenance, but really time-consuming as a default. Scott M Stark wrote: Yeah, I have this problem too, makes debugging difficult. I imagine this can be addressed somehow, just haven't found the solution yet. S, ALR

No. But then does that also fix problems with using the wrong version of a maven plugin getting used? And does it only clear the version referenced by the pom? The big problems I've seen are with the * local repository containing multiple versions and transitive dependencies picking the wrong one * not downloading something it should or downloading things too much stuff * "random" NPEs during builds * incremental compilation not working (there's no equivalent of ant's up-to-date task or if there is, it doesn't work). The first two examples of a poor rule that can't be changed? If I specify a version in my pom that's what I want it to use, I don't want to use some other transitive dependency it finds on some other dependency. mvn dependency:tree helps find the problem, but the problem shouldn't exist in the first place! Actually, I've found maven quite well behaved when I clear my local repository as I switch projects and resynch with svn (even though its slow when you have to keep downloading docbook ;-) You also have to regularly analyze your pom dependencies to make sure it is doing what you think/hope it is doing. So it does work in principle. Just not when the local repository is allowed to "fester", you're not "baby sitting" your pom or you don't do regular clean builds. Like I've said for a while, Maven is a nice idea but a poor implementation. ;-) On Thu, 2008-03-13 at 17:18 -0400, Andrew Lee Rubinger wrote: -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

The components versions in the two files are very much out-of-sync: pom.xml build-thirdparty.xml junit 3.8.1 3.8.2-brew aop 2.0.0-SNAPSHOT 2.0.0.CR7 microcontainer 2.0.0.Beta10 2.0.0.Beta10.1 security 2.0.2.Beta5 2.0.2.Beta5 but jbosssx at 2.0.2-SNAPSHOT oswego 1.3.4-jboss 1.3.4-jboss-update1 antlr 2.7.7 2.7.6-brew apache-discovery 0.2 0.4-brew apache-logging 1.0.4-jboss 1.1.0.jboss apache-myfaces 1.1.0 1.1.3 apache-slide 2.0 2.1-brew apache-velocity 1.4 1.4jboss apache-xalan j_2.7.0 2.7.0.patch01-brew apache-xerces 2.9.1 ` 2.9.0 apache-xmlsec ` 1.2.97 1.3.0 cglib 2.1_3 2.1.3 dom4j 1.6.1-jboss 1.6.1 gnu-getopt 1.0.13 1.0.12-brew hibernate 3.2.4.SP1 3.2.4.SP1_CP01-brew hibernate-annotations 3.3.0.ga 3.3.1.Beta1 hibernate-commons-annotations 3.0.0.ga 3.0.0.GA hibernate-entitymanager 3.3.2.Beta1 3.3.2.Beta3 hsqldb 1.8.0.7 1.8.0.8-brew jacorb 2.3.0jboss.patch4-brew 2.3.0jboss.patch5-brew jacorb-idl 2.2.2.jboss.patch3 javassist 3.6.0.GA 3.7.1.GA jaxen 1.1-beta-11 1.1-brew common-logging-jdk 2.0.4.GA 2.0.2.GA common-logging-log4j 2.0.4.GA 2.0.2.GA common-logging-spi 2.0.4.GA 2.0.2.GA jboss-ejb3-cache 0.13.0-SNAPSHOT 0.11.1 jboss-ha-client 1.0.0.BETA1 1.0.0.GA jboss-jaspi-api 1.0.0-SNAPSHOT 1.0-BETA1 jboss-managed 2.0.0-SNAPSHOT 2.0.0.snapshot jboss-vfs 2.0.0.Beta7 2.0.0.snapshot jbossws-context 2.1.0.snapshot jbossws-framework 3.0.0.GA jbossws-framework-scripts3.0.0.GA jbossws-spi 1.0.1.GA jbossws snapshot jbossxb 2.0.0-SNAPSHOT 2.0.0.CR5 metadata 1.0.0-SNAPSHOT 1.0.0.Beta6 microcontainer 2.0.0.Beta10 2.0.0.Beta10.1 remoting 2.2.1.GA 2.4.0.Beta2 joesnmp 0.3.3 0.3.4 junit 3.8.1 3.8.2-brew qdox 1.6 1.6.1 sun-opends 1.0.0-BUILD04 0.1.0.build016 trove 2.1.1 1.0.2 osgi 4.0 osgi_R4_compendium 1.0 osgi_R4_core 1.0 objectweb-joramtests ??? 1.5 jms-integration-tests ??? 1.0.1.GA jboss/integration ??? 5.0.0.Beta4 javamail ??? 1.4 sun-javac 4.0 3.2 javaee There are multiple jars at different -SNAPSHOT level, that ok? recorded as: org.beanshell beanshell bcel apache-bcel commons-beanutils apache-beanutils commons-codec apache-codec commons-collections apache-collections commons-digester apache-digester commons-fileupload apache-fileupload Snapshot plugins - shouldn't those be tagged??? <groupId>org.codehaus.mojo</groupId> <artifactId>jboss-packaging-maven-plugin</artifactId> <version>2.0-SNAPSHOT</version> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>2.2-beta-1-jboss-1-SNAPSHOT</version> <groupId>org.codehaus.mojo</groupId> <artifactId>rmic-maven-plugin</artifactId> <version>1.0-alpha-1-SNAPSHOT</version> Dimitris Andreadis wrote:

On Thu, 2008-03-13 at 22:54 +0100, Adrian Brock wrote: I've got a clean build and "all" configuration boot. Don't forget to zap thirdparty and do a build clean if you've previously used the maven thirdparty build. -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

On Thu, 2008-03-13 at 17:33 -0500, Paul Gier wrote: That's going to be pretty difficult since we're all working towards RC1 by producing RC1/GAs of our own sub-projects. e.g. I'm trying to get the final Beta out of the all Microcontainer stuff so we can then get on to the final bug fixes/tasks for RC1/GA I'd suggest three things: 1) If anybody changes build-thirdparty.xml, then send a message to list (copy Paul as well to get his attention :-). 2) Paul monitors build-thirdparty.xml http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/build/build-thir... That will catch people not doing (1) and it is a least an indication that something changed, even if it might require looking at the dependencies of what changed to get the full picture. 3) You should be able to get most of the changes by doing an svn merge of the diff between 70847 (the revision at the start of your branch) and "head". -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

Hi Paul, do you have documentation on how to publish stuff to the maven repository? The jbossws artifacts need be published properly as well. How do dependencies work? Previously, when I put a dependency in component-info.xml, the build pulled that dependency in automatically and detected inconsistencies with other modules declaring a dependency on the same artifact. http://repository.jboss.com/jboss/jbossws/snapshot/component-info.xml I publish stuff to bin, lib and resources - how can I do this for the maven repository? BTW, your move to get rid of build-thirdparty.xml was the bravest I've seen so far ;-) cheers -thomas Paul Gier wrote: -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler Web Service Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

On Fri, Mar 14, 2008 at 3:06 PM, Paul Gier <pgier(a)redhat.com&gt; wrote: The main problems as far as I am concerned is the need to upload JARs all over the place, and I certainly don't want to checkout the whole repository. To me, the previous repository was a lot more manageable. Could this be improved ? [we could have someone responsible for signing and uploading stuff, for example] Rémy

On Fri, Mar 14, 2008 at 3:28 PM, Paul Gier <pgier(a)redhat.com&gt; wrote: JBoss Web is now: http://repository.jboss.org/maven2/jboss/web/jbossweb/2.1.0.CR13/ (only one JAR, the others are ... elsewhere) JBoss Web was: http://repository.jboss.org/jboss/web/2.1.0.CR13/lib/ (5 JARs, plus a source zip) I suppose I have to put the 4 other JARs "somewhere else", and I have no clue about the source zip. Rémy

On Fri, Mar 14, 2008 at 4:02 PM, Paul Gier <pgier(a)redhat.com&gt; wrote: I will release a new build shortly, but it could be useful if the repo went through a serious cleanup, I think. Rémy

Adrian Brock wrote: I guess nobody asked for it? I moved both build-thirdparty.xml and root pom.xml (trunk) at 2.0.0.CR7. Please use the following jira if further upgrade is needed: http://jira.jboss.com/jira/browse/JBAS-5314 I guess Paul wants to do the same in the new maven branch. Can someone please explain HOW THIS WORKS? From yesterday's "experiment" I now have 3 version of xercesImpl in my maven repo (2.2.1, 2.4.0, 2.6.2). Note that I had completely wiped-out the content, so this is the result of the jboss as mavenized thirdparty download. Isn't maven supposed to decide which *one* version of a component to download, while resolving dependencies? How it is guaranteed that the correct version of a component will be used in a particular build?

Adrian Brock wrote: I did try booting. :-) CR6 is not in the legacy repo (nor in the maven one).

It's at CR6 now. On Fri, 2008-03-14 at 13:36 +0100, Adrian Brock wrote: -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

Another quick way to view the dependencies is with mvn dependency:tree and if you want to include the dependencies that were filtered out by conflict resolution mvn dependency:tree -Dverbose Paul Gier wrote:

Adrian Brock wrote: For some reason that old version of the jaxb-impl library was explicity defined in root pom.xml, while in build-thirdparty.xml it was implicitly imported through jbossws. Which brings the question: Should the top-level project (in this case AS) declare the indirect dependency (e.g. jaxb-impl), or let the intermediate project bring it in, at whatever version it wants? I guess the answer is, yes, if the top-level project wants to lock into a particular version.