Re: Auto building parent and sibling projects as needed
The problem is that a child does not know where the sources of its parents are located, and therefore it is completely unable to trigger its build. You probably have set up one or more parent aggregator projects and you mapped this hierarchy onto the file/directory structure but this is not mandatory at all. You can very well use a parent just to define the default version to use for dependencies, or the default target of the compiler, other properties that are common through all your projects and many more things. You should probably read again the first two paragraphs here: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Inheritance_vs_Project_Aggregation The first one explains the benefits of inheritance while the second explain the aggregation. Hope this helps you clear things out. Cheers, Guillaume Le 11/09/2011 06:21, Jason Pyeron a écrit : I am trying to understand why maven's reactor would not add a parent and a parent's children to the build when it is detected that the dependency is not in the repository. Is there a use case to NOT auto build? Or is there a technical hurdle to overcome to accomplish this in the reactor design? Could I be missing a concept on maven usage? I have a project which has a very large set of parent/child/sibling dependencies I am migrating from our ant build system. When an engineer needs to make changes on their part it would be best for them to execute mvn from that parts directory. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: [maven] Re: Auto building parent and sibling projects as needed
-Original Message- From: Guillaume Polet Sent: Sunday, September 11, 2011 4:07 To: Maven Users List Subject: [maven] Re: Auto building parent and sibling projects as needed The problem is that a child does not know where the sources of its parents are located, Is it not the point of relativePath../pom.xml/relativePath? and therefore it is completely unable to trigger its build. You probably have set up one or more parent aggregator projects and you mapped this hierarchy onto the file/directory structure but this is not mandatory at all. You can very well use a parent just to define the default version to use for dependencies, or the default target of the compiler, other properties that are common through all your projects and many more things. You should probably read again the first two paragraphs here: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project _Inheritance_vs_Project_Aggregation Read that before and again. See the bottom of the email and attachment (the poms). The first one explains the benefits of inheritance while the second explain the aggregation. Hope this helps you clear things out. Still stuck at the same place, but thanks for confirming what I read. Cheers, Guillaume Le 11/09/2011 06:21, Jason Pyeron a écrit : I am trying to understand why maven's reactor would not add a parent and a parent's children to the build when it is detected that the dependency is not in the repository. Is there a use case to NOT auto build? Or is there a technical hurdle to overcome to accomplish this in the reactor design? Could I be missing a concept on maven usage? I have a project which has a very large set of parent/child/sibling dependencies I am migrating from our ant build system. When an engineer needs to make changes on their part it would be best for them to execute mvn from that parts directory. jpyeron@black /projects/cascade/trunk/tmp/test $ mvn compile [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] parent [INFO] A [INFO] B [INFO] [INFO] [INFO] Building parent 1.0.0 [INFO] [INFO] [INFO] [INFO] Building A 1.0.0 [INFO] [INFO] [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ A --- [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent! [INFO] skip non existing resourceDirectory C:\Documents and Settings\All Users\Desktop\projects\cascade\trunk\tmp\test\A\src\main\resources [INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ A --- [INFO] No sources to compile [INFO] [INFO] [INFO] Building B 1.0.0 [INFO] [INFO] [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ B --- [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent! [INFO] skip non existing resourceDirectory C:\Documents and Settings\All Users\Desktop\projects\cascade\trunk\tmp\test\B\src\main\resources [INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ B --- [INFO] No sources to compile [INFO] [INFO] Reactor Summary: [INFO] [INFO] parent SUCCESS [0.000s] [INFO] A . SUCCESS [0.719s] [INFO] B . SUCCESS [0.047s] [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 0.891s [INFO] Finished at: Sun Sep 11 11:33:49 EDT 2011 [INFO] Final Memory: 3M/121M [INFO] jpyeron@black /projects/cascade/trunk/tmp/test $ cd B jpyeron@black /projects/cascade/trunk/tmp/test/B $ mvn compile [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building B 1.0.0 [INFO] [WARNING] The POM for us.pdinc.foo.maven.test:A:jar:1.0.0 is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO]
Exclusions for maven plugin
Hi there, It looks like I might be getting bitten by the bug as mentioned at http://jira.codehaus.org/browse/WAGON-253. My symptoms were contents of known_hosts file were disappearing except for the one server. As a result all other builds were failing as they could not connect/ssh to source control host - we do use git. mvn clean package cargo:redeploy site:site site:stage-deploy site:deploy Above is the command hudson executes to deploy one war file on qa server and deploy documentation and bunch of other stuff on documentation server. Both cargo and site plugins seem to be wagon plugin and I found multiple versions of wagon plugin in my hudson's local maven repository. If I make known_hosts file readonly, build does fail with the error, can not write to known_hosts file. Direct ssh or scp to remote hosts using hudson as user, does work as expected as password less login is setup correctly. What is the best way to tell maven plugins to use the latest version of wagon plugin. The bug mentioned above is resolved back in 2008/2009. Using maven2, on ubuntu 11.04. Cargo plugin version is 1.1.2 explicitly mentioned in POM, site plugin is not mentioned in POM at all so should be using latest. Last relevant lines from the build log Using private key: /var/lib/hudson/.ssh/id_rsa scp://wiki/var/www/docs/staging/ - Session: Connection refused scp://wiki/var/www/docs/staging/ - Session: Disconnecting scp://wiki/var/www/docs/staging/ - Session: Disconnected [HUDSON] Archiving disabled - not archiving /var/lib/hudson/jobs/FiPort QA deployer/workspace/pom.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Connection aborted - failed to write to known_hosts. Reason: /var/lib/hudson/.ssh/known_hosts (Permission denied) Regards, Niranjan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Exclusions for maven plugin
The quickest solution is to use a buildextensionsextension element in the POM to call out the version of the wagon plugin that you want. On Sun, Sep 11, 2011 at 7:18 PM, Niranjan Rao nhr...@gmail.com wrote: Hi there, It looks like I might be getting bitten by the bug as mentioned at http://jira.codehaus.org/browse/WAGON-253. My symptoms were contents of known_hosts file were disappearing except for the one server. As a result all other builds were failing as they could not connect/ssh to source control host - we do use git. mvn clean package cargo:redeploy site:site site:stage-deploy site:deploy Above is the command hudson executes to deploy one war file on qa server and deploy documentation and bunch of other stuff on documentation server. Both cargo and site plugins seem to be wagon plugin and I found multiple versions of wagon plugin in my hudson's local maven repository. If I make known_hosts file readonly, build does fail with the error, can not write to known_hosts file. Direct ssh or scp to remote hosts using hudson as user, does work as expected as password less login is setup correctly. What is the best way to tell maven plugins to use the latest version of wagon plugin. The bug mentioned above is resolved back in 2008/2009. Using maven2, on ubuntu 11.04. Cargo plugin version is 1.1.2 explicitly mentioned in POM, site plugin is not mentioned in POM at all so should be using latest. Last relevant lines from the build log Using private key: /var/lib/hudson/.ssh/id_rsa scp://wiki/var/www/docs/staging/ - Session: Connection refused scp://wiki/var/www/docs/staging/ - Session: Disconnecting scp://wiki/var/www/docs/staging/ - Session: Disconnected [HUDSON] Archiving disabled - not archiving /var/lib/hudson/jobs/FiPort QA deployer/workspace/pom.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Connection aborted - failed to write to known_hosts. Reason: /var/lib/hudson/.ssh/known_hosts (Permission denied) Regards, Niranjan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
About transitive dependencies
I came across an issue I raised on StackOverflow: http://stackoverflow.com/questions/7373105/noclassdeffounderror-org-junit-afterclass-during-annotation-processing/7375380#7375380 I have a library B having a compile dependency (i.e. scope) on A. I have a library C having a test dependency (i.e. scope) on B. When I compile C, it includes B, but not A. And since C calls B calls A, it crashes at runtime. Apparently, this is how it should work according to the dependency scope (http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope). Yet, why should users of C explicitly declare a compile dependency to A, when we know at compile time that A will be required? Shouldn't the transitivity rule be that if you have such a transitive relationship, A should always be compile dependency of A? Or is there something I am missing? The problem is that the runtime crash is really late to be notified about this issue. It does not fit with the maven philosophy. Thanks, JVerstry - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
