Re: Reactor doesn't build parent poms first?
Same use case for me. Most of the time users work on single module. But we also create artificially (using svn:externals) big multimodule builds with an aggregator pom. This is to allow a full clean build on CI platform. relativePath is set to empty in order to avoid maven complains when working on a single component. So in our big build we have A, B and C in this order where B is parent of A and C. Doing mvn clean install, A will get old parent from repo (when available) while C will get newest parent that was installed just before. I feel reordering reactor by taking parent relationship into account can solve this issue. Regards Julien - Mail original - > De : Laird Nelson > À : Maven Users List > Cc : > Envoyé le : Lundi 22 Août 2011 17h38 > Objet : Re: Reactor doesn't build parent poms first? > > On Mon, Aug 22, 2011 at 11:22 AM, Benson Margulies > wrote: > >> I'm foggy on one point here. How can the pom in the reactor differ >> from the pom reached by relative path? Different property >> substitutions? Or is the issue here the case in which there is no rel >> path, but it is in the reactor? >> > > (I'll quickly chime in with my background use case--or at least the reason > why I brought up all this stuff initially.) > > In my organization we have lots of modules. Developers typically only work > on a given module at a time. We've set things up in a pretty standard > fashion so that they can check that module out and work on it without having > to check out the other modules. We've got Nexus proxying various > repositories; all artifacts that are depended upon basically get downloaded > through that. Standard Maven stuff. > > Of course, the developers often do have the whole project checked out. That > used to cause some weird problems, detailed below. > > Some of our modules have parents that are other modules. So we have a > standard -pomtypes-jpa module, for example, that does some stuff in its > section to do things like generate the list of entity classes that > should be included in a persistence.xml during unit/integration testing. > Other modules may extend this as their parent to pick up this behavior. > > Occasionally, we need to make changes to these mid-level modules. > > Back in the day, we had a bunch of relativePath elements. But developers > were getting confused, because if they were working on a JPA module that > inherited from this -pomtypes-jpa module, then if they hadn't > version-control-updated their -pomtypes-jpa module, the relativePath element > would kick in and try to use the working copy in their workspace. Oops. > > The solution in this case was: if you have the -pomtypes-jpa module checked > out, make sure you svn update it religiously so that when relativePath finds > it, you're getting the most recent copy from Subversion. > > OK, fine, so we finally decided, forget this, the relativePath element is > kind of a hack anyway (or at least didn't fit our needs at all). So now all > pom resolution comes from the repository. That's cool; that's like > every > other Maven artifact. Smooth sailing. We update the -pomtypes-jpa pom.xml, > and all children who extend it pick it up automatically (we're still in > SNAPSHOT mode). > > However, this is kind of odd when we're doing a full build. Suppose one of > these developers hasn't done a full build in ages and ages. Or, for that > matter, hasn't worked on a JPA module, so hasn't caused Maven to go look > for > a new SNAPSHOT version of that -pomtypes-jpa project. > > Now, when we execute that full build right after a global svn update, the > full build will go use the (comparatively ancient) 1.0-SNAPSHOT version of > -pomtypes-jpa's pom.xml from the local repository (or the remote), which is, > of course, the most recent *deployed* version, but might very well not be > the most recent version *in Subversion* that they just checked out to their > workspace. Really since we're doing a full build, we'd like it to > use...well, the one that should be built right now. :-) We would like it > to realize that one of the artifacts that a module extends from is actually > *in the build plan currently being executed*, so gee, it would be nice if > Maven would sort it all the way up in the topologically sorted list of > reactor projects. Obviously it could potentially affect property > substitution and the like for child poms, so you'd want to make sure this > thing was built first. > > Maybe that's all backwards and wrong-headed, but it's where I was coming > from. One "customer"'s input. > > The workar
Re: Reactor doesn't build parent poms first?
Yes, I've also found that I have to "mvn install -N" on the first build of a parent (when it does not exist in local or remote repo) otherwise the build fails. If that is what you are experiencing, then me too. I've never looked further, as it happens so infrequently. On Mon, Aug 22, 2011 at 10:38 AM, Laird Nelson wrote: > On Mon, Aug 22, 2011 at 11:22 AM, Benson Margulies >wrote: > > > I'm foggy on one point here. How can the pom in the reactor differ > > from the pom reached by relative path? Different property > > substitutions? Or is the issue here the case in which there is no rel > > path, but it is in the reactor? > > > > (I'll quickly chime in with my background use case--or at least the reason > why I brought up all this stuff initially.) > > In my organization we have lots of modules. Developers typically only work > on a given module at a time. We've set things up in a pretty standard > fashion so that they can check that module out and work on it without > having > to check out the other modules. We've got Nexus proxying various > repositories; all artifacts that are depended upon basically get downloaded > through that. Standard Maven stuff. > > Of course, the developers often do have the whole project checked out. > That > used to cause some weird problems, detailed below. > > Some of our modules have parents that are other modules. So we have a > standard -pomtypes-jpa module, for example, that does some stuff in its > section to do things like generate the list of entity classes that > should be included in a persistence.xml during unit/integration testing. > Other modules may extend this as their parent to pick up this behavior. > > Occasionally, we need to make changes to these mid-level modules. > > Back in the day, we had a bunch of relativePath elements. But developers > were getting confused, because if they were working on a JPA module that > inherited from this -pomtypes-jpa module, then if they hadn't > version-control-updated their -pomtypes-jpa module, the relativePath > element > would kick in and try to use the working copy in their workspace. Oops. > > The solution in this case was: if you have the -pomtypes-jpa module checked > out, make sure you svn update it religiously so that when relativePath > finds > it, you're getting the most recent copy from Subversion. > > OK, fine, so we finally decided, forget this, the relativePath element is > kind of a hack anyway (or at least didn't fit our needs at all). So now > all > pom resolution comes from the repository. That's cool; that's like every > other Maven artifact. Smooth sailing. We update the -pomtypes-jpa > pom.xml, > and all children who extend it pick it up automatically (we're still in > SNAPSHOT mode). > > However, this is kind of odd when we're doing a full build. Suppose one of > these developers hasn't done a full build in ages and ages. Or, for that > matter, hasn't worked on a JPA module, so hasn't caused Maven to go look > for > a new SNAPSHOT version of that -pomtypes-jpa project. > > Now, when we execute that full build right after a global svn update, the > full build will go use the (comparatively ancient) 1.0-SNAPSHOT version of > -pomtypes-jpa's pom.xml from the local repository (or the remote), which > is, > of course, the most recent *deployed* version, but might very well not be > the most recent version *in Subversion* that they just checked out to their > workspace. Really since we're doing a full build, we'd like it to > use...well, the one that should be built right now. :-) We would like it > to realize that one of the artifacts that a module extends from is actually > *in the build plan currently being executed*, so gee, it would be nice if > Maven would sort it all the way up in the topologically sorted list of > reactor projects. Obviously it could potentially affect property > substitution and the like for child poms, so you'd want to make sure this > thing was built first. > > Maybe that's all backwards and wrong-headed, but it's where I was coming > from. One "customer"'s input. > > The workaround for us is to wrap Maven so that we do mvn -o clean install > on > the parent poms first, in topological order, then run mvn clean install > from > the root. I was looking for this sort of thing to be handled natively by > the reactor. > > Best, > Laird > > -- > http://about.me/lairdnelson >
Re: Reactor doesn't build parent poms first?
On Mon, Aug 22, 2011 at 11:22 AM, Benson Margulies wrote: > I'm foggy on one point here. How can the pom in the reactor differ > from the pom reached by relative path? Different property > substitutions? Or is the issue here the case in which there is no rel > path, but it is in the reactor? > (I'll quickly chime in with my background use case--or at least the reason why I brought up all this stuff initially.) In my organization we have lots of modules. Developers typically only work on a given module at a time. We've set things up in a pretty standard fashion so that they can check that module out and work on it without having to check out the other modules. We've got Nexus proxying various repositories; all artifacts that are depended upon basically get downloaded through that. Standard Maven stuff. Of course, the developers often do have the whole project checked out. That used to cause some weird problems, detailed below. Some of our modules have parents that are other modules. So we have a standard -pomtypes-jpa module, for example, that does some stuff in its section to do things like generate the list of entity classes that should be included in a persistence.xml during unit/integration testing. Other modules may extend this as their parent to pick up this behavior. Occasionally, we need to make changes to these mid-level modules. Back in the day, we had a bunch of relativePath elements. But developers were getting confused, because if they were working on a JPA module that inherited from this -pomtypes-jpa module, then if they hadn't version-control-updated their -pomtypes-jpa module, the relativePath element would kick in and try to use the working copy in their workspace. Oops. The solution in this case was: if you have the -pomtypes-jpa module checked out, make sure you svn update it religiously so that when relativePath finds it, you're getting the most recent copy from Subversion. OK, fine, so we finally decided, forget this, the relativePath element is kind of a hack anyway (or at least didn't fit our needs at all). So now all pom resolution comes from the repository. That's cool; that's like every other Maven artifact. Smooth sailing. We update the -pomtypes-jpa pom.xml, and all children who extend it pick it up automatically (we're still in SNAPSHOT mode). However, this is kind of odd when we're doing a full build. Suppose one of these developers hasn't done a full build in ages and ages. Or, for that matter, hasn't worked on a JPA module, so hasn't caused Maven to go look for a new SNAPSHOT version of that -pomtypes-jpa project. Now, when we execute that full build right after a global svn update, the full build will go use the (comparatively ancient) 1.0-SNAPSHOT version of -pomtypes-jpa's pom.xml from the local repository (or the remote), which is, of course, the most recent *deployed* version, but might very well not be the most recent version *in Subversion* that they just checked out to their workspace. Really since we're doing a full build, we'd like it to use...well, the one that should be built right now. :-) We would like it to realize that one of the artifacts that a module extends from is actually *in the build plan currently being executed*, so gee, it would be nice if Maven would sort it all the way up in the topologically sorted list of reactor projects. Obviously it could potentially affect property substitution and the like for child poms, so you'd want to make sure this thing was built first. Maybe that's all backwards and wrong-headed, but it's where I was coming from. One "customer"'s input. The workaround for us is to wrap Maven so that we do mvn -o clean install on the parent poms first, in topological order, then run mvn clean install from the root. I was looking for this sort of thing to be handled natively by the reactor. Best, Laird -- http://about.me/lairdnelson
Re: Reactor doesn't build parent poms first?
On Mon, Aug 22, 2011 at 10:46 AM, Julien HENRY wrote: > According to my own tests, with Maven 3 the parent pom is resolved according > to the following algorithm: > > IF relativePath != "" > THEN > > IF pom is found at relativePath location and GAV match > THEN use this pom as parent > ELSE log a warning and useRepo=true > ENDIF > > ELSE > useRepo=true > > ENDIF > > Maven 3 will never use the pom from the reactor, and the reactor order will > not reorder parent before children. I'm foggy on one point here. How can the pom in the reactor differ from the pom reached by relative path? Different property substitutions? Or is the issue here the case in which there is no rel path, but it is in the reactor? > > See > https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ParentPOMResolution > > Please correct me if I am wrong. > > Regards, > > Julien > > >>____ >>De : Stephen Connolly >>À : Maven Users List >>Envoyé le : Lundi 22 Août 2011 16h16 >>Objet : Re: Reactor doesn't build parent poms first? >> >>On 22 August 2011 14:37, Laird Nelson wrote: >>> On Mon, Aug 22, 2011 at 7:48 AM, Stephen Connolly < >>> stephen.alan.conno...@gmail.com> wrote: >>> >>>> > Should have mentioned I was talking about SNAPSHOTs; sorry. Does that >>>> > change the picture? >>>> >>>> Nope. >>> >>> >>> Just to be clear, then: >>> >>> You're saying that in a multimodule project, where my root >>> pom.xmlaggregates several submodules, and where one of those >>> submodules is a >>> pom.xml that serves as a parent to some other submodules--you're saying that >>> even when all these things are declared as version 1.0-SNAPSHOT, Maven will >>> use the repo copy of the parent, even though the very reactor plan it is >>> executing tells it that it should be building the most recent copy? >>> >>> Or, using the same letters that I used in my prior message's example, if A, >>> B and C are all 1.0-SNAPSHOT, and the version of B deployed to the >>> repository is 75 days old, Maven will begin a full build from the root (A) >>> by first scanning the module paths to see what projects are there (A, B and >>> C), and because C references B as a parent, the 75-day-old copy of B will be >>> retrieved from the (local) repo rather than Maven realizing that B is in the >>> reactor plan as a module in its own right? >>> >> >>No I am saying that if C references B 0.9-SNAPSHOT as its parent then >>the reactor will not require B 1.0-SNAPSHOT (from the reactor) to be >>built before C 1.0-SNAPSHOT. >> >>If the parent GAV is present in the reactor, then that is what will be used >>if the parent GA is present in the reactor only with a different V, >>then you might be lucky and see a warning if the relativePath points >>to it, otherwise Maven will not see an issue as long as the requested >>GAV is in a repo >> >>> Best, >>> Laird >>> >>> -- >>> http://about.me/lairdnelson >>> >> >>- >>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 > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Reactor doesn't build parent poms first?
According to my own tests, with Maven 3 the parent pom is resolved according to the following algorithm: IF relativePath != "" THEN IF pom is found at relativePath location and GAV match THEN use this pom as parent ELSE log a warning and useRepo=true ENDIF ELSE useRepo=true ENDIF Maven 3 will never use the pom from the reactor, and the reactor order will not reorder parent before children. See https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ParentPOMResolution Please correct me if I am wrong. Regards, Julien > >De : Stephen Connolly >À : Maven Users List >Envoyé le : Lundi 22 Août 2011 16h16 >Objet : Re: Reactor doesn't build parent poms first? > >On 22 August 2011 14:37, Laird Nelson wrote: >> On Mon, Aug 22, 2011 at 7:48 AM, Stephen Connolly < >> stephen.alan.conno...@gmail.com> wrote: >> >>> > Should have mentioned I was talking about SNAPSHOTs; sorry. Does that >>> > change the picture? >>> >>> Nope. >> >> >> Just to be clear, then: >> >> You're saying that in a multimodule project, where my root >> pom.xmlaggregates several submodules, and where one of those >> submodules is a >> pom.xml that serves as a parent to some other submodules--you're saying that >> even when all these things are declared as version 1.0-SNAPSHOT, Maven will >> use the repo copy of the parent, even though the very reactor plan it is >> executing tells it that it should be building the most recent copy? >> >> Or, using the same letters that I used in my prior message's example, if A, >> B and C are all 1.0-SNAPSHOT, and the version of B deployed to the >> repository is 75 days old, Maven will begin a full build from the root (A) >> by first scanning the module paths to see what projects are there (A, B and >> C), and because C references B as a parent, the 75-day-old copy of B will be >> retrieved from the (local) repo rather than Maven realizing that B is in the >> reactor plan as a module in its own right? >> > >No I am saying that if C references B 0.9-SNAPSHOT as its parent then >the reactor will not require B 1.0-SNAPSHOT (from the reactor) to be >built before C 1.0-SNAPSHOT. > >If the parent GAV is present in the reactor, then that is what will be used >if the parent GA is present in the reactor only with a different V, >then you might be lucky and see a warning if the relativePath points >to it, otherwise Maven will not see an issue as long as the requested >GAV is in a repo > >> Best, >> Laird >> >> -- >> http://about.me/lairdnelson >> > >- >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: Reactor doesn't build parent poms first?
On 22 August 2011 14:37, Laird Nelson wrote: > On Mon, Aug 22, 2011 at 7:48 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> > Should have mentioned I was talking about SNAPSHOTs; sorry. Does that >> > change the picture? >> >> Nope. > > > Just to be clear, then: > > You're saying that in a multimodule project, where my root > pom.xmlaggregates several submodules, and where one of those > submodules is a > pom.xml that serves as a parent to some other submodules--you're saying that > even when all these things are declared as version 1.0-SNAPSHOT, Maven will > use the repo copy of the parent, even though the very reactor plan it is > executing tells it that it should be building the most recent copy? > > Or, using the same letters that I used in my prior message's example, if A, > B and C are all 1.0-SNAPSHOT, and the version of B deployed to the > repository is 75 days old, Maven will begin a full build from the root (A) > by first scanning the module paths to see what projects are there (A, B and > C), and because C references B as a parent, the 75-day-old copy of B will be > retrieved from the (local) repo rather than Maven realizing that B is in the > reactor plan as a module in its own right? > No I am saying that if C references B 0.9-SNAPSHOT as its parent then the reactor will not require B 1.0-SNAPSHOT (from the reactor) to be built before C 1.0-SNAPSHOT. If the parent GAV is present in the reactor, then that is what will be used if the parent GA is present in the reactor only with a different V, then you might be lucky and see a warning if the relativePath points to it, otherwise Maven will not see an issue as long as the requested GAV is in a repo > Best, > Laird > > -- > http://about.me/lairdnelson > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Reactor doesn't build parent poms first?
On Mon, Aug 22, 2011 at 7:48 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > > Should have mentioned I was talking about SNAPSHOTs; sorry. Does that > > change the picture? > > Nope. Just to be clear, then: You're saying that in a multimodule project, where my root pom.xmlaggregates several submodules, and where one of those submodules is a pom.xml that serves as a parent to some other submodules--you're saying that even when all these things are declared as version 1.0-SNAPSHOT, Maven will use the repo copy of the parent, even though the very reactor plan it is executing tells it that it should be building the most recent copy? Or, using the same letters that I used in my prior message's example, if A, B and C are all 1.0-SNAPSHOT, and the version of B deployed to the repository is 75 days old, Maven will begin a full build from the root (A) by first scanning the module paths to see what projects are there (A, B and C), and because C references B as a parent, the 75-day-old copy of B will be retrieved from the (local) repo rather than Maven realizing that B is in the reactor plan as a module in its own right? Best, Laird -- http://about.me/lairdnelson
Re: Reactor doesn't build parent poms first?
On 22 August 2011 12:41, Laird Nelson wrote: > On Mon, Aug 22, 2011 at 2:45 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> if the versions do not match, then the reactor does not have a constraint. >> > > Should have mentioned I was talking about SNAPSHOTs; sorry. Does that > change the picture? Nope. > > when relative path is set, you get a warning of a version mismatch (or maybe >> an error, cannot remember exactly) >> > > Right; makes sense when we're talking about release versions. > make sense when talking about any version. > >> it is perfectly legal to have a reactor with C depending on the previous >> release of B >> > > Sure; thanks. And you could even be depending on a different -SNAPSHOT version in that same reactor... though personally I cannot think of a good use case for such a reactor. > > Best, > Laird > -- > http://about.me/lairdnelson > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Reactor doesn't build parent poms first?
On Mon, Aug 22, 2011 at 2:45 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > if the versions do not match, then the reactor does not have a constraint. > Should have mentioned I was talking about SNAPSHOTs; sorry. Does that change the picture? when relative path is set, you get a warning of a version mismatch (or maybe > an error, cannot remember exactly) > Right; makes sense when we're talking about release versions. > it is perfectly legal to have a reactor with C depending on the previous > release of B > Sure; thanks. Best, Laird -- http://about.me/lairdnelson
Re: Reactor doesn't build parent poms first?
if the versions do not match, then the reactor does not have a constraint. when relative path is set, you get a warning of a version mismatch (or maybe an error, cannot remember exactly) it is perfectly legal to have a reactor with C depending on the previous release of B - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 21 Aug 2011 22:14, "Laird Nelson" wrote: > This is probably some sort of misunderstanding on my part, but I thought I'd > check. > > When executing a multi-module build, it appears that Maven will not detect > that certain parent POMs in the project need to be built before an effective > project scan can be completed. > > That is, suppose that you have a project structure with an aggregator, A, a > module that is a parent pom, B, and a module that is a child of B (C). > > So A aggregates B and C; C extends from B. > > Assume also that (deliberately) the stanza does not have its > set. (This is because in a large team with moderately > skilled developers, there are all sorts of problems if the developer forgets > to svn update B--the relative path of C's parent will pick up the workspace > copy of B, not the most recent copy in the Maven repository.) > > If you run the reactor here it will use the repository copy of B, rather > than realizing (as I think it should) that B is something that it can build > to get a more recent copy. > > I would expect there to be a two-part scanning algorithm: first scan all > modules and see if their parents are modules in the build. If so, then > build those modules first. Then build the other projects in dependency > order. > > Am I missing something? My apologies if so. > > Best, > Laird > > -- > http://about.me/lairdnelson
Reactor doesn't build parent poms first?
This is probably some sort of misunderstanding on my part, but I thought I'd check. When executing a multi-module build, it appears that Maven will not detect that certain parent POMs in the project need to be built before an effective project scan can be completed. That is, suppose that you have a project structure with an aggregator, A, a module that is a parent pom, B, and a module that is a child of B (C). So A aggregates B and C; C extends from B. Assume also that (deliberately) the stanza does not have its set. (This is because in a large team with moderately skilled developers, there are all sorts of problems if the developer forgets to svn update B--the relative path of C's parent will pick up the workspace copy of B, not the most recent copy in the Maven repository.) If you run the reactor here it will use the repository copy of B, rather than realizing (as I think it should) that B is something that it can build to get a more recent copy. I would expect there to be a two-part scanning algorithm: first scan all modules and see if their parents are modules in the build. If so, then build those modules first. Then build the other projects in dependency order. Am I missing something? My apologies if so. Best, Laird -- http://about.me/lairdnelson
