Re: [maven] Re: Auto building parent and sibling projects as needed
Le 11/09/2011 17:37, Jason Pyeron a écrit : -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 ofrelativePath../pom.xml/relativePath? No, this simply indicates where to look relatively to find a pom.xml if it is not installed in your local repository (or a remote one where it could be fetched from). 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. Hard to say why your second build is failing. I just tried a similar setup and it worked in all cases: parent: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdparent/artifactId packagingpom/packaging nameparent/name version1.0.0-SNAPSHOT/version modules moduleB/module moduleA/module /modules /project A: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdA/artifactId nameA/name version1.0.0-SNAPSHOT/version packagingpom/packaging parent groupIdtest/groupId artifactIdparent/artifactId version1.0.0-SNAPSHOT/version relativePath../pom.xml/relativePath /parent /project B: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdB/artifactId nameB/name version1.0.0-SNAPSHOT/version packagingpom/packaging parent groupIdtest/groupId artifactIdparent/artifactId version1.0.0-SNAPSHOT/version relativePath../pom.xml/relativePath /parent dependencies dependency groupIdtest/groupId artifactIdA/artifactId version1.0.0-SNAPSHOT/version /dependency /dependencies /project With the directory hierarchy: * parent * A * B and the results from the build: D:\tmp\parentmvn package [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] parent [INFO] A [INFO] B [INFO] [INFO] [INFO] Building parent 1.0.0-SNAPSHOT [INFO] [INFO] [INFO] [INFO] Building A 1.0.0-SNAPSHOT [INFO] [INFO] [INFO] [INFO] Building B 1.0.0-SNAPSHOT [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] parent SUCCESS [0.003s] [INFO] A . SUCCESS [0.001s] [INFO] B . SUCCESS [0.002s] [INFO
RE: [maven] Re: Auto building parent and sibling projects as needed
-Original Message- From: Guillaume Polet Sent: Monday, September 12, 2011 3:01 To: Maven Users List Subject: Re: [maven] Re: Auto building parent and sibling projects as needed Le 11/09/2011 17:37, Jason Pyeron a écrit : -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 ofrelativePath../pom.xml/relativePath? No, this simply indicates where to look relatively to find a pom.xml if it is not installed in your local repository (or a remote one where it could be fetched from). Is this a design or bug of the reactor? 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 snip/ Hard to say why your second build is failing. I just tried a similar setup and it worked in all cases: parent: The difference is that you are saying that the children A B are pom packaged, which does not cause compile to kick off, which inturn does not need the dependency. snip/ B: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdB/artifactId nameB/name version1.0.0-SNAPSHOT/version packagingpom/packaging parent groupIdtest/groupId artifactIdparent/artifactId version1.0.0-SNAPSHOT/version relativePath../pom.xml/relativePath snip/ Your log says the following: -- cannot find the pom.xml from project A (This I don't understand why) -- jar file of project A cannot be found Try 'mvn install' so that the pom and the jar file is deployed locally because it will not find the jar in the target directory. An install would not be appropiate for this part of the development lifecycle. For argument sake, lets assume that not every module passes all unit tests but all compile and we are in a SNAPSHOT versioning. -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
Re: [maven] Re: Auto building parent and sibling projects as needed
Le 12/09/2011 15:33, Jason Pyeron a écrit : -Original Message- From: Guillaume Polet Sent: Monday, September 12, 2011 3:01 To: Maven Users List Subject: Re: [maven] Re: Auto building parent and sibling projects as needed Le 11/09/2011 17:37, Jason Pyeron a écrit : -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 ofrelativePath../pom.xml/relativePath? No, this simply indicates where to look relatively to find a pom.xml if it is not installed in your local repository (or a remote one where it could be fetched from). Is this a design or bug of the reactor? It is by design. If you want to build a parent, then just go to the parent. If the parent build was triggered, you would not have any possibility to just build a child. 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 snip/ Hard to say why your second build is failing. I just tried a similar setup and it worked in all cases: parent: The difference is that you are saying that the children A B are pom packaged, which does not cause compile to kick off, which inturn does not need the dependency. snip/ You can very well change them into jar's and add a dummy class in A and B project. It still works, I tried it myself. B: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdB/artifactId nameB/name version1.0.0-SNAPSHOT/version packagingpom/packaging parent groupIdtest/groupId artifactIdparent/artifactId version1.0.0-SNAPSHOT/version relativePath../pom.xml/relativePath snip/ Your log says the following: -- cannot find the pom.xml from project A (This I don't understand why) -- jar file of project A cannot be found Try 'mvn install' so that the pom and the jar file is deployed locally because it will not find the jar in the target directory. An install would not be appropiate for this part of the development lifecycle. For argument sake, lets assume that not every module passes all unit tests but all compile and we are in a SNAPSHOT versioning. -Jason OK, maybe some expert Maven user knows how to go around such a situation. AFIK (and my knowledge is not very big), you have two options: 1) You build the parent, the children will follow and you should be fine 2) You do an 'mvn install': since you are using SNAPSHOT it should not be a problem to have unstable jars (although using -DskipTest=true is not recommended, but that's another story) and since 'install' deploys the artifacts locally, you do not pollute anyone else's repository. Sorry if I can't help you more than that. Cheers, Guillaume -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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: 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
Auto building parent and sibling projects as needed
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
