It turns out this is a bug with maven version 2.0.10. It works fine if the developer switches to 2.1 or 2.2.1.
-Dave On Mon, Sep 28, 2009 at 8:31 AM, Roland Asmann <[email protected]> wrote: > And like I said: compare the settings.xml files on both systems, maybe > there's > something different in there! > > > On Monday 28 September 2009 16:14, David Hoffer wrote: > > Yeah, that combination is all I can come up with too for the cause of > this > > bug. I'm waiting to hear back from the developer what version of maven > he > > is using (I think 2.1) and then I'll create a JIRA for this. > > > > -Dave > > > > On Mon, Sep 28, 2009 at 8:08 AM, Roland Asmann <[email protected]> > wrote: > > > The behavior on system 2 is somehow wrong... Maybe it has something to > do > > > with > > > the combination of Vista/Cygwin/Maven? At least make sure you have the > > > same version of maven running and are using the same (or at least a > > > compatible) settings.xml file... > > > > > > Not sure what else it could be, but imo the correct behavior is that of > > > system > > > 1. > > > > > > On Monday 28 September 2009 15:21, David Hoffer wrote: > > > > No, the problem is with the compiler. Here is more details on what > is > > > > happening: > > > > > > > > I have a parent pom that has two modules, A & B. > > > > > > > > B depends on A. > > > > > > > > A depends on P which is a 3rd party jar with provided scope. The > task > > > > of module A is to combine the contents of A & P, this sum is the > output > > > > of > > > > > > A. > > > > > > > Now when we build this (clean install) at the parent pom on two > systems > > > > > > we > > > > > > > get two different behaviors. > > > > > > > > System 1: (XP w/ maven 2.1) > > > > Everything works as expected. The build of B depends on the final > > > > output jar of A in its target folder. I.e. with -X turned on I see > its > > > > > > depending > > > > > > > on .../target/A.jar > > > > > > > > System 2: (Vista, w/ cygwin, maven 2.?) > > > > Build fails. The build of B does not depend on the final output jar > of > > > > > > A, > > > > > > > rather it depends on A's target/classes folder. I.e. with -X turned > on > > > > I see its depending on .../target/classes > > > > (Note the build fails here because the classes folder is not enough, > it > > > > would also need the P dependency which is not available because it's > > > > > > scope > > > > > > > is provided. The desired behavior is as system 1, where dependent > > > > builds depend on the final output of A.) > > > > > > > > Whey are these builds different? System 1 is the assumed correct > > > > > > behavior, > > > > > > > right? Is this somehow configurable?? > > > > > > > > -Dave > > > > > > > > On Mon, Sep 28, 2009 at 12:51 AM, Roland Asmann < > [email protected] > > > > > > > >wrote: > > > > > And for what plugin is this? In a normal scenario, this could be > the > > > > > output in the project 'cdf-webtas-overrides' for the test-plugin > > > > > (surefire-plugin). There could be others as well. > > > > > > > > > > This is normal, because the tests need your classes when being > run... > > > > > > It > > > > > > > > always uses the classes from the current project + any and all > > > > > dependencies from the local repository. > > > > > > > > > > If you still think this is wrong, please post a little more from > the > > > > > Maven log, this small excerpt unfortunately is not quite clear > > > > > without more info! > > > > > > > > > > Roland > > > > > > > > > > > That's right maven is looking for a dependency in taget/classes, > > > > > > see > > > > > > > > > > below > > > > > > > > > > > for the log. The one I'm referring to is > > > > > > > C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes > > > > > >, it should be referencing the jar, right? > > > > > > > > > > > > How can this happen? So far I have only seen this on the one > > > > > > system > > > > > > I > > > > > > > > > described. > > > > > > > > > > > > -Dave > > > > > > > > > > > > [DEBUG] (f) classpathElements = [ > > > > > > > > > > > > > C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-adapter\target\classes, > > > > > > > C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-public\0.3 > > > > > > > >-SNAPSHOT\cdf-public-0.3-SNAPSHOT.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\dom4j\dom4j\1.6.1\dom4j-1.6.1.jar > > > > > > > >, > > > > > > > C:\Users\steve.seagraves\.m2\repository\xml-apis\xml-apis\1.0.b2\xml-apis > > > > > > > >-1.0.b2.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\org\apache\xmlbeans\xmlbeans\2.4. > > > > > > > >0\xmlbeans-2.4.0.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\stax\stax-api\1.0.1\stax-api-1.0. > > > > > > > >1.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\org\codehaus\groovy\groovy-all\1. > > > > > > > >5.4\groovy-all-1.5.4.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant\1.7.0\ant-1.7. > > > > > > > >0.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\org\apache\ant\ant-launcher\1.7.0 > > > > > > > >\ant-launcher-1.7.0.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\jline\jline\0.9.93\jline-0.9.93.j > > > > > > > >ar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\slf-service-ap > > > > > > > >i\0.2\slf-service-api-0.2.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\com\issinc\commons\java-commons\0 > > > > > > > >.2\java-commons-0.2.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\log4j\log4j\1.2.14\log4j-1.2.14.j > > > > > > > >ar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\com\google\code\findbugs\jsr305\1 > > > > > > > >.3.9\jsr305-1.3.9.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\velocity\velocity\1.4\velocity-1. > > > > > > > >4.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\com\issinc\cdf\sdk\cdf-internal\0 > > > > > > > >.3-SNAPSHOT\cdf-internal-0.3-SNAPSHOT.jar, > > > > > > > > > > > > C:\SVNHome\CDF-trunk\cdf-webtas\cdf-webtas-overrides\target\classes > > > > > >, > > > > > > > C:\Users\steve.seagraves\.m2\repository\commons-beanutils\commons-beanuti > > > > > > > >ls\1.6\commons-beanutils-1.6.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\commons-logging\commons-logging\1 > > > > > > > >.1.1\commons-logging-1.1.1.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\commons-collections\commons-colle > > > > > > > >ctions\3.1\commons-collections-3.1.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\commons-codec\commons-codec\1.3\c > > > > > > > >ommons-codec-1.3.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\commons-configuration\commons-con > > > > > > > >figuration\1.6\commons-configuration-1.6.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\commons-lang\commons-lang\2.2\com > > > > > > > >mons-lang-2.2.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\commons-digester\commons-digester > > > > > > > >\1.8\commons-digester-1.8.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\commons-beanutils\commons-beanuti > > > > > > > >ls-core\1.8.0\commons-beanutils-core-1.8.0.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\commons-dbcp\commons-dbcp\1.2.2\c > > > > > > > >ommons-dbcp-1.2.2.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\commons-pool\commons-pool\1.3\com > > > > > > > >mons-pool-1.3.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\commons-dbutils\commons-dbutils\1 > > > > > > > >.0\commons-dbutils-1.0.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\commons-httpclient\commons-httpcl > > > > > > > >ient\3.0.1\commons-httpclient-3.0.1.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\commons-io\commons-io\1.2\commons > > > > > > > >-io-1.2.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\jakarta-regexp\jakarta-regexp\1.2 > > > > > > > >\jakarta-regexp-1.2.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\jaxen\jaxen\1.1.1\jaxen-1.1.1.jar > > > > > > > >, > > > > > > > > > > > > C:\Users\steve.seagraves\.m2\repository\jdom\jdom\1.0\jdom-1.0.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\xerces\xercesImpl\2.8.1\xercesImp > > > > > > > >l-2.8.1.jar, > > > > > > > > > > > C:\Users\steve.seagraves\.m2\repository\xom\xom\1.0\xom-1.0.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\xerces\xmlParserAPIs\2.6.2\xmlPar > > > > > > > >serAPIs-2.6.2.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\xalan\xalan\2.6.0\xalan-2.6.0.jar > > > > > > > >, > > > > > > > C:\Users\steve.seagraves\.m2\repository\lark\lark\19980115\lark-19980115. > > > > > > > >jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\org\apache\lucene\lucene-core\2.3 > > > > > > > >.0\lucene-core-2.3.0.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\org\apache\lucene\lucene-highligh > > > > > > > >ter\2.3.0\lucene-highlighter-2.3.0.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\org\apache\lucene\lucene-snowball > > > > > > > >\2.3.0\lucene-snowball-2.3.0.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\tsmConfig\tsmConfig\3.1.0\tsmConf > > > > > > > >ig-3.1.0.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\webnfs\webnfs\19990414\webnfs-199 > > > > > > > >90414.jar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\xml4j\xml4j\2_0_15\xml4j-2_0_15.j > > > > > > > >ar, > > > > > > > C:\Users\steve.seagraves\.m2\repository\com\bbn\openmap\4.6.3\openmap-4.6 > > > > > > > >.3.jar] > > > > > > > > > > > On Sun, Sep 27, 2009 at 2:33 PM, Roland Asmann > > > > > > <[email protected] > > > > > > > > > > > > wrote: > > > > > >> It's looking for dependencies in target/classes? Really? > > > > > >> > > > > > >> Normally, Maven reads the POM in the directory you start it > from. > > > > > >> If this > > > > > >> POM contains modules, those are loaded as well (and if they have > > > > > >> modules, > > > > > >> those are loaded too... ad infinitum). Then, if some of those > > > > > > modules > > > > > > > > >> have > > > > > >> dependencies to each other, they are NOT loaded from the local > > > > > >> repository, > > > > > >> but from the reactor (Maven might shuffle your list of > > > > > >> dependencies > > > > > > a > > > > > > > > >> bit > > > > > >> to make sure the modules are build in such a way that the > > > > > > dependencies > > > > > > > > >> are > > > > > >> already built when another project needs it). > > > > > >> > > > > > >> I hope this answers your question. If not, pleas be a bit more > > > > > >> specific about what your problem is/what you want to know/do! > > > > > >> > > > > > >> Roland > > > > > >> > > > > > >> > When performing [clean] install on multi-module projects, > where > > > > > >> > is > > > > > >> > > > > > >> maven > > > > > >> > > > > > >> > supposed to look for (child) dependencies? Does it look in > > > > > >> > > > > > >> target/classes > > > > > >> > > > > > >> > or does it look at the jar previously installed in the local > > > > > >> > repo? > > > > > >> > > > > > > >> > We have two systems where one seems to be looking in the local > > > > > > repo > > > > > > > > >> for > > > > > >> > > > > > >> > all > > > > > >> > dependencies and one looking in target/classes. I thought > maven > > > > > >> > > > > > >> always > > > > > >> > > > > > >> > used > > > > > >> > the local repo only but is this configurable? How is this > > > > > > supposed > > > > > > > > >> > to work? > > > > > >> > > > > > > >> > -Dave > > > > > > --------------------------------------------------------------------- > > > > > > > > >> To unsubscribe, e-mail: [email protected] > > > > > >> For additional commands, e-mail: [email protected] > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > -- > > > Roland Asmann > > > > > > CFC Informationssysteme Entwicklungsgesellschaft m.b.H > > > Bäckerstrasse 1/2/7 > > > A-1010 Wien > > > FN 266155f, Handelsgericht Wien > > > > > > Tel.: +43/1/513 88 77 - 27 > > > Fax.: +43/1/513 88 62 > > > Email: [email protected] > > > Web: www.cfc.at > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > -- > Roland Asmann > > CFC Informationssysteme Entwicklungsgesellschaft m.b.H > Bäckerstrasse 1/2/7 > A-1010 Wien > FN 266155f, Handelsgericht Wien > > Tel.: +43/1/513 88 77 - 27 > Fax.: +43/1/513 88 62 > Email: [email protected] > Web: www.cfc.at > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
