Need to fully understand bad implications of combined aggregator and parent pom

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Need to fully understand bad implications of combined aggregator and parent pom

David M. Karr
A while ago, I started working on an existing project with many developers.  The codebase has a large multi-project Maven build.  The top directory is both an "aggregator" and "parent" POM, as it has a "modules" list, and all of the child modules have it as their parent POM, for dependencies and plugins.

I've always believed this is a defective architecture.  I believe that the top-level directory should have an "aggregator" POM that just lists the modules to build, and a subdirectory of the top-level directory should have a project that just defines the parent POM, which defines dependencies and plugins for subprojects to use.

Although I feel this is a "cleaner" architecture, I've never been able to cite specific problems with the other approach, besides the fact that module changes and dependency/plugin changes go in the same file, which is still a "cleanliness" argument.

Today I think I saw a real reason why the present architecture is a problem, but I need to be certain the problem I'm seeing is caused by this, and that the better architecture fixes this problem, and whether there is a simple workaround in the meantime.

I've been modifying the build to use a completely new intranet maven repo and completely different groupids for the build artifacts.

I saw errors like this (with elisions):
-----------------------
[INFO] Reactor Summary:
[INFO]
[INFO] big-parent ......................................... FAILURE [  5.230 s]
[INFO] some-other-module................................... SKIPPED
[INFO] another-module...................................... SKIPPED
[INFO] .....................................................SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8.063 s
[INFO] Finished at: 2016-11-29T16:23:36-08:00
[INFO] Final Memory: 41M/1093M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project some-other-module: Could not resolve dependencies for project com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT: Could not find artifact com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in mycomp-public-group (http://mavencentral.it.mycomp.com:8084/nexus/content/repositories/mycomp-public-group/) -> [Help 1]
[ERROR]
---------------

The "big-parent" module is the top-level directory that is both the aggregator and parent pom.

Conceptually, I think this is happening because Maven is trying to evaluate dependencies before those dependencies are built.  Again, I think the "separated" architecture will resolve this, but before I implement that, I need to understand exactly what is going on here.

In my local workspace, I got around this by simply "cd"ing to the "another-module" directory and doing a "mvn install", then "cd"ing to "some-other-module", doing the same, and then doing the same again at the top level. The reality was messier than this, because I had quite a few modules that I had to build manually this way.

Assuming I'm right that separating the "parent" function from the "aggregator" function would resolve this, can someone explain exactly what is happening here, how my assumed solution would resolve this, and whether there's a cleaner temporary workaround besides "cd"ing into each directory to do a separate install?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Need to fully understand bad implications of combined aggregator and parent pom

Benson Margulies
My experience is precisely the opposite of yours. The most common
practice is for the parent to be the aggregator; it's hard to get the
site plugin, for example, to work right with your preferred structure
where they are different.

I have built many projects with the the one-parent structure, and they
typically have interdependencies between the modules, and they work
fine.  Can you boil this down to a failing case on github? Can you
share some poms?


On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID <[hidden email]> wrote:

> A while ago, I started working on an existing project with many developers.  The codebase has a large multi-project Maven build.  The top directory is both an "aggregator" and "parent" POM, as it has a "modules" list, and all of the child modules have it as their parent POM, for dependencies and plugins.
>
> I've always believed this is a defective architecture.  I believe that the top-level directory should have an "aggregator" POM that just lists the modules to build, and a subdirectory of the top-level directory should have a project that just defines the parent POM, which defines dependencies and plugins for subprojects to use.
>
> Although I feel this is a "cleaner" architecture, I've never been able to cite specific problems with the other approach, besides the fact that module changes and dependency/plugin changes go in the same file, which is still a "cleanliness" argument.
>
> Today I think I saw a real reason why the present architecture is a problem, but I need to be certain the problem I'm seeing is caused by this, and that the better architecture fixes this problem, and whether there is a simple workaround in the meantime.
>
> I've been modifying the build to use a completely new intranet maven repo and completely different groupids for the build artifacts.
>
> I saw errors like this (with elisions):
> -----------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] big-parent ......................................... FAILURE [  5.230 s]
> [INFO] some-other-module................................... SKIPPED
> [INFO] another-module...................................... SKIPPED
> [INFO] .....................................................SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 8.063 s
> [INFO] Finished at: 2016-11-29T16:23:36-08:00
> [INFO] Final Memory: 41M/1093M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project some-other-module: Could not resolve dependencies for project com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT: Could not find artifact com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in mycomp-public-group (http://mavencentral.it.mycomp.com:8084/nexus/content/repositories/mycomp-public-group/) -> [Help 1]
> [ERROR]
> ---------------
>
> The "big-parent" module is the top-level directory that is both the aggregator and parent pom.
>
> Conceptually, I think this is happening because Maven is trying to evaluate dependencies before those dependencies are built.  Again, I think the "separated" architecture will resolve this, but before I implement that, I need to understand exactly what is going on here.
>
> In my local workspace, I got around this by simply "cd"ing to the "another-module" directory and doing a "mvn install", then "cd"ing to "some-other-module", doing the same, and then doing the same again at the top level. The reality was messier than this, because I had quite a few modules that I had to build manually this way.
>
> Assuming I'm right that separating the "parent" function from the "aggregator" function would resolve this, can someone explain exactly what is happening here, how my assumed solution would resolve this, and whether there's a cleaner temporary workaround besides "cd"ing into each directory to do a separate install?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Need to fully understand bad implications of combined aggregator and parent pom

stephenconnolly
You do have relativePath set correctly for the separate parent from
aggregator?

On Wed 30 Nov 2016 at 03:28, Benson Margulies <[hidden email]> wrote:

> My experience is precisely the opposite of yours. The most common
> practice is for the parent to be the aggregator; it's hard to get the
> site plugin, for example, to work right with your preferred structure
> where they are different.
>
> I have built many projects with the the one-parent structure, and they
> typically have interdependencies between the modules, and they work
> fine.  Can you boil this down to a failing case on github? Can you
> share some poms?
>
>
> On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID <[hidden email]> wrote:
> > A while ago, I started working on an existing project with many
> developers.  The codebase has a large multi-project Maven build.  The top
> directory is both an "aggregator" and "parent" POM, as it has a "modules"
> list, and all of the child modules have it as their parent POM, for
> dependencies and plugins.
> >
> > I've always believed this is a defective architecture.  I believe that
> the top-level directory should have an "aggregator" POM that just lists the
> modules to build, and a subdirectory of the top-level directory should have
> a project that just defines the parent POM, which defines dependencies and
> plugins for subprojects to use.
> >
> > Although I feel this is a "cleaner" architecture, I've never been able
> to cite specific problems with the other approach, besides the fact that
> module changes and dependency/plugin changes go in the same file, which is
> still a "cleanliness" argument.
> >
> > Today I think I saw a real reason why the present architecture is a
> problem, but I need to be certain the problem I'm seeing is caused by this,
> and that the better architecture fixes this problem, and whether there is a
> simple workaround in the meantime.
> >
> > I've been modifying the build to use a completely new intranet maven
> repo and completely different groupids for the build artifacts.
> >
> > I saw errors like this (with elisions):
> > -----------------------
> > [INFO] Reactor Summary:
> > [INFO]
> > [INFO] big-parent ......................................... FAILURE [
> 5.230 s]
> > [INFO] some-other-module................................... SKIPPED
> > [INFO] another-module...................................... SKIPPED
> > [INFO] .....................................................SKIPPED
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO] BUILD FAILURE
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO] Total time: 8.063 s
> > [INFO] Finished at: 2016-11-29T16:23:36-08:00
> > [INFO] Final Memory: 41M/1093M
> > [INFO]
> ------------------------------------------------------------------------
> > [ERROR] Failed to execute goal on project some-other-module: Could not
> resolve dependencies for project
> com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT: Could not find
> artifact com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
> mycomp-public-group (
> http://mavencentral.it.mycomp.com:8084/nexus/content/repositories/mycomp-public-group/)
> -> [Help 1]
> > [ERROR]
> > ---------------
> >
> > The "big-parent" module is the top-level directory that is both the
> aggregator and parent pom.
> >
> > Conceptually, I think this is happening because Maven is trying to
> evaluate dependencies before those dependencies are built.  Again, I think
> the "separated" architecture will resolve this, but before I implement
> that, I need to understand exactly what is going on here.
> >
> > In my local workspace, I got around this by simply "cd"ing to the
> "another-module" directory and doing a "mvn install", then "cd"ing to
> "some-other-module", doing the same, and then doing the same again at the
> top level. The reality was messier than this, because I had quite a few
> modules that I had to build manually this way.
> >
> > Assuming I'm right that separating the "parent" function from the
> "aggregator" function would resolve this, can someone explain exactly what
> is happening here, how my assumed solution would resolve this, and whether
> there's a cleaner temporary workaround besides "cd"ing into each directory
> to do a separate install?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

RE: Need to fully understand bad implications of combined aggregator and parent pom

David M. Karr
> -----Original Message-----
> From: Stephen Connolly [mailto:[hidden email]]
> Sent: Wednesday, November 30, 2016 1:01 PM
> To: Maven Users List <[hidden email]>
> Subject: Re: Need to fully understand bad implications of combined
> aggregator and parent pom
>
> You do have relativePath set correctly for the separate parent from
> aggregator?

Not sure whether you're addressing Benson or me, but setting relativePath is definitely a requirement, and I think the error message you get is pretty clear when you don’t have it, so I imagine that's not Benson's issue.

In my case, I did some cut/pasting and some global replaces to separate the POM into parent and aggregator, and now my build works from the top with empty repositories.

I don't use the site plugin.

> On Wed 30 Nov 2016 at 03:28, Benson Margulies <[hidden email]>
> wrote:
>
> > My experience is precisely the opposite of yours. The most common
> > practice is for the parent to be the aggregator; it's hard to get the
> > site plugin, for example, to work right with your preferred structure
> > where they are different.
> >
> > I have built many projects with the the one-parent structure, and they
> > typically have interdependencies between the modules, and they work
> > fine.  Can you boil this down to a failing case on github? Can you
> > share some poms?
> >
> >
> > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID <[hidden email]> wrote:
> > > A while ago, I started working on an existing project with many
> > developers.  The codebase has a large multi-project Maven build.  The
> > top directory is both an "aggregator" and "parent" POM, as it has a
> "modules"
> > list, and all of the child modules have it as their parent POM, for
> > dependencies and plugins.
> > >
> > > I've always believed this is a defective architecture.  I believe
> > > that
> > the top-level directory should have an "aggregator" POM that just
> > lists the modules to build, and a subdirectory of the top-level
> > directory should have a project that just defines the parent POM,
> > which defines dependencies and plugins for subprojects to use.
> > >
> > > Although I feel this is a "cleaner" architecture, I've never been
> > > able
> > to cite specific problems with the other approach, besides the fact
> > that module changes and dependency/plugin changes go in the same file,
> > which is still a "cleanliness" argument.
> > >
> > > Today I think I saw a real reason why the present architecture is a
> > problem, but I need to be certain the problem I'm seeing is caused by
> > this, and that the better architecture fixes this problem, and whether
> > there is a simple workaround in the meantime.
> > >
> > > I've been modifying the build to use a completely new intranet maven
> > repo and completely different groupids for the build artifacts.
> > >
> > > I saw errors like this (with elisions):
> > > -----------------------
> > > [INFO] Reactor Summary:
> > > [INFO]
> > > [INFO] big-parent ......................................... FAILURE
> > > [
> > 5.230 s]
> > > [INFO] some-other-module................................... SKIPPED
> > > [INFO] another-module...................................... SKIPPED
> > > [INFO] .....................................................SKIPPED
> > > [INFO]
> > ----------------------------------------------------------------------
> > --
> > > [INFO] BUILD FAILURE
> > > [INFO]
> > ----------------------------------------------------------------------
> > --
> > > [INFO] Total time: 8.063 s
> > > [INFO] Finished at: 2016-11-29T16:23:36-08:00 [INFO] Final Memory:
> > > 41M/1093M [INFO]
> > ----------------------------------------------------------------------
> > --
> > > [ERROR] Failed to execute goal on project some-other-module: Could
> > > not
> > resolve dependencies for project
> > com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT: Could not
> > find artifact com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
> > mycomp-public-group (
> > http://mavencentral.it.mycomp.com:8084/nexus/content/repositories/myco
> > mp-public-group/)
> > -> [Help 1]
> > > [ERROR]
> > > ---------------
> > >
> > > The "big-parent" module is the top-level directory that is both the
> > aggregator and parent pom.
> > >
> > > Conceptually, I think this is happening because Maven is trying to
> > evaluate dependencies before those dependencies are built.  Again, I
> > think the "separated" architecture will resolve this, but before I
> > implement that, I need to understand exactly what is going on here.
> > >
> > > In my local workspace, I got around this by simply "cd"ing to the
> > "another-module" directory and doing a "mvn install", then "cd"ing to
> > "some-other-module", doing the same, and then doing the same again at
> > the top level. The reality was messier than this, because I had quite
> > a few modules that I had to build manually this way.
> > >
> > > Assuming I'm right that separating the "parent" function from the
> > "aggregator" function would resolve this, can someone explain exactly
> > what is happening here, how my assumed solution would resolve this,
> > and whether there's a cleaner temporary workaround besides "cd"ing
> > into each directory to do a separate install?
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> > --
> Sent from my phone

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Need to fully understand bad implications of combined aggregator and parent pom

Dan Tran
I concur with Ben,  aggregator module is banned at my work. Top level
parent hosts all modules

On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <[hidden email]> wrote:

> > -----Original Message-----
> > From: Stephen Connolly [mailto:[hidden email]]
> > Sent: Wednesday, November 30, 2016 1:01 PM
> > To: Maven Users List <[hidden email]>
> > Subject: Re: Need to fully understand bad implications of combined
> > aggregator and parent pom
> >
> > You do have relativePath set correctly for the separate parent from
> > aggregator?
>
> Not sure whether you're addressing Benson or me, but setting relativePath
> is definitely a requirement, and I think the error message you get is
> pretty clear when you don’t have it, so I imagine that's not Benson's issue.
>
> In my case, I did some cut/pasting and some global replaces to separate
> the POM into parent and aggregator, and now my build works from the top
> with empty repositories.
>
> I don't use the site plugin.
>
> > On Wed 30 Nov 2016 at 03:28, Benson Margulies <[hidden email]>
> > wrote:
> >
> > > My experience is precisely the opposite of yours. The most common
> > > practice is for the parent to be the aggregator; it's hard to get the
> > > site plugin, for example, to work right with your preferred structure
> > > where they are different.
> > >
> > > I have built many projects with the the one-parent structure, and they
> > > typically have interdependencies between the modules, and they work
> > > fine.  Can you boil this down to a failing case on github? Can you
> > > share some poms?
> > >
> > >
> > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID <[hidden email]> wrote:
> > > > A while ago, I started working on an existing project with many
> > > developers.  The codebase has a large multi-project Maven build.  The
> > > top directory is both an "aggregator" and "parent" POM, as it has a
> > "modules"
> > > list, and all of the child modules have it as their parent POM, for
> > > dependencies and plugins.
> > > >
> > > > I've always believed this is a defective architecture.  I believe
> > > > that
> > > the top-level directory should have an "aggregator" POM that just
> > > lists the modules to build, and a subdirectory of the top-level
> > > directory should have a project that just defines the parent POM,
> > > which defines dependencies and plugins for subprojects to use.
> > > >
> > > > Although I feel this is a "cleaner" architecture, I've never been
> > > > able
> > > to cite specific problems with the other approach, besides the fact
> > > that module changes and dependency/plugin changes go in the same file,
> > > which is still a "cleanliness" argument.
> > > >
> > > > Today I think I saw a real reason why the present architecture is a
> > > problem, but I need to be certain the problem I'm seeing is caused by
> > > this, and that the better architecture fixes this problem, and whether
> > > there is a simple workaround in the meantime.
> > > >
> > > > I've been modifying the build to use a completely new intranet maven
> > > repo and completely different groupids for the build artifacts.
> > > >
> > > > I saw errors like this (with elisions):
> > > > -----------------------
> > > > [INFO] Reactor Summary:
> > > > [INFO]
> > > > [INFO] big-parent ......................................... FAILURE
> > > > [
> > > 5.230 s]
> > > > [INFO] some-other-module................................... SKIPPED
> > > > [INFO] another-module...................................... SKIPPED
> > > > [INFO] .....................................................SKIPPED
> > > > [INFO]
> > > ----------------------------------------------------------------------
> > > --
> > > > [INFO] BUILD FAILURE
> > > > [INFO]
> > > ----------------------------------------------------------------------
> > > --
> > > > [INFO] Total time: 8.063 s
> > > > [INFO] Finished at: 2016-11-29T16:23:36-08:00 [INFO] Final Memory:
> > > > 41M/1093M [INFO]
> > > ----------------------------------------------------------------------
> > > --
> > > > [ERROR] Failed to execute goal on project some-other-module: Could
> > > > not
> > > resolve dependencies for project
> > > com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT: Could not
> > > find artifact com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
> > > mycomp-public-group (
> > > http://mavencentral.it.mycomp.com:8084/nexus/content/repositories/myco
> > > mp-public-group/)
> > > -> [Help 1]
> > > > [ERROR]
> > > > ---------------
> > > >
> > > > The "big-parent" module is the top-level directory that is both the
> > > aggregator and parent pom.
> > > >
> > > > Conceptually, I think this is happening because Maven is trying to
> > > evaluate dependencies before those dependencies are built.  Again, I
> > > think the "separated" architecture will resolve this, but before I
> > > implement that, I need to understand exactly what is going on here.
> > > >
> > > > In my local workspace, I got around this by simply "cd"ing to the
> > > "another-module" directory and doing a "mvn install", then "cd"ing to
> > > "some-other-module", doing the same, and then doing the same again at
> > > the top level. The reality was messier than this, because I had quite
> > > a few modules that I had to build manually this way.
> > > >
> > > > Assuming I'm right that separating the "parent" function from the
> > > "aggregator" function would resolve this, can someone explain exactly
> > > what is happening here, how my assumed solution would resolve this,
> > > and whether there's a cleaner temporary workaround besides "cd"ing
> > > into each directory to do a separate install?
> > > >
> > > > --------------------------------------------------------------------
> > > > - To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > > --
> > Sent from my phone
>
Reply | Threaded
Open this post in threaded view
|

RE: Need to fully understand bad implications of combined aggregator and parent pom

David M. Karr
> -----Original Message-----
> From: Dan Tran [mailto:[hidden email]]
> Sent: Wednesday, November 30, 2016 3:17 PM
> To: Maven Users List <[hidden email]>
> Subject: Re: Need to fully understand bad implications of combined
> aggregator and parent pom
>
> I concur with Ben,  aggregator module is banned at my work. Top level
> parent hosts all modules

So does this mean that you utilize "relativePath" in the child module's parent definitions?  Otherwise, the child modules are being built before the POM for the top-level POM is installed (which happens at the end of the build).

> On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <[hidden email]> wrote:
>
> > > -----Original Message-----
> > > From: Stephen Connolly [mailto:[hidden email]]
> > > Sent: Wednesday, November 30, 2016 1:01 PM
> > > To: Maven Users List <[hidden email]>
> > > Subject: Re: Need to fully understand bad implications of combined
> > > aggregator and parent pom
> > >
> > > You do have relativePath set correctly for the separate parent from
> > > aggregator?
> >
> > Not sure whether you're addressing Benson or me, but setting
> > relativePath is definitely a requirement, and I think the error
> > message you get is pretty clear when you don’t have it, so I imagine
> that's not Benson's issue.
> >
> > In my case, I did some cut/pasting and some global replaces to
> > separate the POM into parent and aggregator, and now my build works
> > from the top with empty repositories.
> >
> > I don't use the site plugin.
> >
> > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
> > > <[hidden email]>
> > > wrote:
> > >
> > > > My experience is precisely the opposite of yours. The most common
> > > > practice is for the parent to be the aggregator; it's hard to get
> > > > the site plugin, for example, to work right with your preferred
> > > > structure where they are different.
> > > >
> > > > I have built many projects with the the one-parent structure, and
> > > > they typically have interdependencies between the modules, and
> > > > they work fine.  Can you boil this down to a failing case on
> > > > github? Can you share some poms?
> > > >
> > > >
> > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID <[hidden email]>
> wrote:
> > > > > A while ago, I started working on an existing project with many
> > > > developers.  The codebase has a large multi-project Maven build.
> > > > The top directory is both an "aggregator" and "parent" POM, as it
> > > > has a
> > > "modules"
> > > > list, and all of the child modules have it as their parent POM,
> > > > for dependencies and plugins.
> > > > >
> > > > > I've always believed this is a defective architecture.  I
> > > > > believe that
> > > > the top-level directory should have an "aggregator" POM that just
> > > > lists the modules to build, and a subdirectory of the top-level
> > > > directory should have a project that just defines the parent POM,
> > > > which defines dependencies and plugins for subprojects to use.
> > > > >
> > > > > Although I feel this is a "cleaner" architecture, I've never
> > > > > been able
> > > > to cite specific problems with the other approach, besides the
> > > > fact that module changes and dependency/plugin changes go in the
> > > > same file, which is still a "cleanliness" argument.
> > > > >
> > > > > Today I think I saw a real reason why the present architecture
> > > > > is a
> > > > problem, but I need to be certain the problem I'm seeing is caused
> > > > by this, and that the better architecture fixes this problem, and
> > > > whether there is a simple workaround in the meantime.
> > > > >
> > > > > I've been modifying the build to use a completely new intranet
> > > > > maven
> > > > repo and completely different groupids for the build artifacts.
> > > > >
> > > > > I saw errors like this (with elisions):
> > > > > -----------------------
> > > > > [INFO] Reactor Summary:
> > > > > [INFO]
> > > > > [INFO] big-parent .........................................
> > > > > FAILURE [
> > > > 5.230 s]
> > > > > [INFO] some-other-module...................................
> > > > > SKIPPED [INFO]
> > > > > another-module...................................... SKIPPED
> > > > > [INFO]
> > > > > .....................................................SKIPPED
> > > > > [INFO]
> > > > ------------------------------------------------------------------
> > > > ----
> > > > --
> > > > > [INFO] BUILD FAILURE
> > > > > [INFO]
> > > > ------------------------------------------------------------------
> > > > ----
> > > > --
> > > > > [INFO] Total time: 8.063 s
> > > > > [INFO] Finished at: 2016-11-29T16:23:36-08:00 [INFO] Final
> Memory:
> > > > > 41M/1093M [INFO]
> > > > ------------------------------------------------------------------
> > > > ----
> > > > --
> > > > > [ERROR] Failed to execute goal on project some-other-module:
> > > > > Could not
> > > > resolve dependencies for project
> > > > com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT: Could
> > > > not find artifact
> > > > com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
> > > > mycomp-public-group (
> > > > http://mavencentral.it.mycomp.com:8084/nexus/content/repositories/
> > > > myco
> > > > mp-public-group/)
> > > > -> [Help 1]
> > > > > [ERROR]
> > > > > ---------------
> > > > >
> > > > > The "big-parent" module is the top-level directory that is both
> > > > > the
> > > > aggregator and parent pom.
> > > > >
> > > > > Conceptually, I think this is happening because Maven is trying
> > > > > to
> > > > evaluate dependencies before those dependencies are built.  Again,
> > > > I think the "separated" architecture will resolve this, but before
> > > > I implement that, I need to understand exactly what is going on
> here.
> > > > >
> > > > > In my local workspace, I got around this by simply "cd"ing to
> > > > > the
> > > > "another-module" directory and doing a "mvn install", then "cd"ing
> > > > to "some-other-module", doing the same, and then doing the same
> > > > again at the top level. The reality was messier than this, because
> > > > I had quite a few modules that I had to build manually this way.
> > > > >
> > > > > Assuming I'm right that separating the "parent" function from
> > > > > the
> > > > "aggregator" function would resolve this, can someone explain
> > > > exactly what is happening here, how my assumed solution would
> > > > resolve this, and whether there's a cleaner temporary workaround
> > > > besides "cd"ing into each directory to do a separate install?
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > - To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > --- To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > --
> > > Sent from my phone
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Need to fully understand bad implications of combined aggregator and parent pom

Dan Tran
Correct we dont ever enter relativePath. The implicit one should work and
should never see warning that a module can't find its parent

On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID <[hidden email]> wrote:

> > -----Original Message-----
> > From: Dan Tran [mailto:[hidden email]]
> > Sent: Wednesday, November 30, 2016 3:17 PM
> > To: Maven Users List <[hidden email]>
> > Subject: Re: Need to fully understand bad implications of combined
> > aggregator and parent pom
> >
> > I concur with Ben,  aggregator module is banned at my work. Top level
> > parent hosts all modules
>
> So does this mean that you utilize "relativePath" in the child module's
> parent definitions?  Otherwise, the child modules are being built before
> the POM for the top-level POM is installed (which happens at the end of the
> build).
>
> > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <[hidden email]> wrote:
> >
> > > > -----Original Message-----
> > > > From: Stephen Connolly [mailto:[hidden email]]
> > > > Sent: Wednesday, November 30, 2016 1:01 PM
> > > > To: Maven Users List <[hidden email]>
> > > > Subject: Re: Need to fully understand bad implications of combined
> > > > aggregator and parent pom
> > > >
> > > > You do have relativePath set correctly for the separate parent from
> > > > aggregator?
> > >
> > > Not sure whether you're addressing Benson or me, but setting
> > > relativePath is definitely a requirement, and I think the error
> > > message you get is pretty clear when you don’t have it, so I imagine
> > that's not Benson's issue.
> > >
> > > In my case, I did some cut/pasting and some global replaces to
> > > separate the POM into parent and aggregator, and now my build works
> > > from the top with empty repositories.
> > >
> > > I don't use the site plugin.
> > >
> > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
> > > > <[hidden email]>
> > > > wrote:
> > > >
> > > > > My experience is precisely the opposite of yours. The most common
> > > > > practice is for the parent to be the aggregator; it's hard to get
> > > > > the site plugin, for example, to work right with your preferred
> > > > > structure where they are different.
> > > > >
> > > > > I have built many projects with the the one-parent structure, and
> > > > > they typically have interdependencies between the modules, and
> > > > > they work fine.  Can you boil this down to a failing case on
> > > > > github? Can you share some poms?
> > > > >
> > > > >
> > > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID <[hidden email]>
> > wrote:
> > > > > > A while ago, I started working on an existing project with many
> > > > > developers.  The codebase has a large multi-project Maven build.
> > > > > The top directory is both an "aggregator" and "parent" POM, as it
> > > > > has a
> > > > "modules"
> > > > > list, and all of the child modules have it as their parent POM,
> > > > > for dependencies and plugins.
> > > > > >
> > > > > > I've always believed this is a defective architecture.  I
> > > > > > believe that
> > > > > the top-level directory should have an "aggregator" POM that just
> > > > > lists the modules to build, and a subdirectory of the top-level
> > > > > directory should have a project that just defines the parent POM,
> > > > > which defines dependencies and plugins for subprojects to use.
> > > > > >
> > > > > > Although I feel this is a "cleaner" architecture, I've never
> > > > > > been able
> > > > > to cite specific problems with the other approach, besides the
> > > > > fact that module changes and dependency/plugin changes go in the
> > > > > same file, which is still a "cleanliness" argument.
> > > > > >
> > > > > > Today I think I saw a real reason why the present architecture
> > > > > > is a
> > > > > problem, but I need to be certain the problem I'm seeing is caused
> > > > > by this, and that the better architecture fixes this problem, and
> > > > > whether there is a simple workaround in the meantime.
> > > > > >
> > > > > > I've been modifying the build to use a completely new intranet
> > > > > > maven
> > > > > repo and completely different groupids for the build artifacts.
> > > > > >
> > > > > > I saw errors like this (with elisions):
> > > > > > -----------------------
> > > > > > [INFO] Reactor Summary:
> > > > > > [INFO]
> > > > > > [INFO] big-parent .........................................
> > > > > > FAILURE [
> > > > > 5.230 s]
> > > > > > [INFO] some-other-module...................................
> > > > > > SKIPPED [INFO]
> > > > > > another-module...................................... SKIPPED
> > > > > > [INFO]
> > > > > > .....................................................SKIPPED
> > > > > > [INFO]
> > > > > ------------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > > [INFO] BUILD FAILURE
> > > > > > [INFO]
> > > > > ------------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > > [INFO] Total time: 8.063 s
> > > > > > [INFO] Finished at: 2016-11-29T16:23:36-08:00 [INFO] Final
> > Memory:
> > > > > > 41M/1093M [INFO]
> > > > > ------------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > > [ERROR] Failed to execute goal on project some-other-module:
> > > > > > Could not
> > > > > resolve dependencies for project
> > > > > com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT: Could
> > > > > not find artifact
> > > > > com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
> > > > > mycomp-public-group (
> > > > > http://mavencentral.it.mycomp.com:8084/nexus/content/repositories/
> > > > > myco
> > > > > mp-public-group/)
> > > > > -> [Help 1]
> > > > > > [ERROR]
> > > > > > ---------------
> > > > > >
> > > > > > The "big-parent" module is the top-level directory that is both
> > > > > > the
> > > > > aggregator and parent pom.
> > > > > >
> > > > > > Conceptually, I think this is happening because Maven is trying
> > > > > > to
> > > > > evaluate dependencies before those dependencies are built.  Again,
> > > > > I think the "separated" architecture will resolve this, but before
> > > > > I implement that, I need to understand exactly what is going on
> > here.
> > > > > >
> > > > > > In my local workspace, I got around this by simply "cd"ing to
> > > > > > the
> > > > > "another-module" directory and doing a "mvn install", then "cd"ing
> > > > > to "some-other-module", doing the same, and then doing the same
> > > > > again at the top level. The reality was messier than this, because
> > > > > I had quite a few modules that I had to build manually this way.
> > > > > >
> > > > > > Assuming I'm right that separating the "parent" function from
> > > > > > the
> > > > > "aggregator" function would resolve this, can someone explain
> > > > > exactly what is happening here, how my assumed solution would
> > > > > resolve this, and whether there's a cleaner temporary workaround
> > > > > besides "cd"ing into each directory to do a separate install?
> > > > > >
> > > > > > ----------------------------------------------------------------
> > > > > > ----
> > > > > > - To unsubscribe, e-mail: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > > > >
> > > > >
> > > > > ------------------------------------------------------------------
> > > > > --- To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > > --
> > > > Sent from my phone
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

RE: Need to fully understand bad implications of combined aggregator and parent pom

David M. Karr
> -----Original Message-----
> From: Dan Tran [mailto:[hidden email]]
> Sent: Wednesday, November 30, 2016 5:10 PM
> To: Maven Users List <[hidden email]>
> Subject: Re: Need to fully understand bad implications of combined
> aggregator and parent pom
>
> Correct we dont ever enter relativePath. The implicit one should work
> and should never see warning that a module can't find its parent

Uh, whatever.  You're clearly disagreeing with me, so saying "correct" just confuses things.

The fact is, when I ensured that both the local and intranet repo is EMPTY of build artifacts, including the parent pom, the child modules fail to build because they can't find the parent pom, which just resides in the parent directory of each child module.

I never tried adding a "<relativePath>..</relativePath> to all of the parent pom references, but I was able to get it to work by splitting out the parent pom responsibilities into a separate child module pom, and having all the references specify the relative path to that.

> On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID <[hidden email]> wrote:
>
> > > -----Original Message-----
> > > From: Dan Tran [mailto:[hidden email]]
> > > Sent: Wednesday, November 30, 2016 3:17 PM
> > > To: Maven Users List <[hidden email]>
> > > Subject: Re: Need to fully understand bad implications of combined
> > > aggregator and parent pom
> > >
> > > I concur with Ben,  aggregator module is banned at my work. Top
> > > level parent hosts all modules
> >
> > So does this mean that you utilize "relativePath" in the child
> > module's parent definitions?  Otherwise, the child modules are being
> > built before the POM for the top-level POM is installed (which happens
> > at the end of the build).
> >
> > > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <[hidden email]> wrote:
> > >
> > > > > -----Original Message-----
> > > > > From: Stephen Connolly [mailto:[hidden email]]
> > > > > Sent: Wednesday, November 30, 2016 1:01 PM
> > > > > To: Maven Users List <[hidden email]>
> > > > > Subject: Re: Need to fully understand bad implications of
> > > > > combined aggregator and parent pom
> > > > >
> > > > > You do have relativePath set correctly for the separate parent
> > > > > from aggregator?
> > > >
> > > > Not sure whether you're addressing Benson or me, but setting
> > > > relativePath is definitely a requirement, and I think the error
> > > > message you get is pretty clear when you don’t have it, so I
> > > > imagine
> > > that's not Benson's issue.
> > > >
> > > > In my case, I did some cut/pasting and some global replaces to
> > > > separate the POM into parent and aggregator, and now my build
> > > > works from the top with empty repositories.
> > > >
> > > > I don't use the site plugin.
> > > >
> > > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
> > > > > <[hidden email]>
> > > > > wrote:
> > > > >
> > > > > > My experience is precisely the opposite of yours. The most
> > > > > > common practice is for the parent to be the aggregator; it's
> > > > > > hard to get the site plugin, for example, to work right with
> > > > > > your preferred structure where they are different.
> > > > > >
> > > > > > I have built many projects with the the one-parent structure,
> > > > > > and they typically have interdependencies between the modules,
> > > > > > and they work fine.  Can you boil this down to a failing case
> > > > > > on github? Can you share some poms?
> > > > > >
> > > > > >
> > > > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID <[hidden email]>
> > > wrote:
> > > > > > > A while ago, I started working on an existing project with
> > > > > > > many
> > > > > > developers.  The codebase has a large multi-project Maven
> build.
> > > > > > The top directory is both an "aggregator" and "parent" POM, as
> > > > > > it has a
> > > > > "modules"
> > > > > > list, and all of the child modules have it as their parent
> > > > > > POM, for dependencies and plugins.
> > > > > > >
> > > > > > > I've always believed this is a defective architecture.  I
> > > > > > > believe that
> > > > > > the top-level directory should have an "aggregator" POM that
> > > > > > just lists the modules to build, and a subdirectory of the
> > > > > > top-level directory should have a project that just defines
> > > > > > the parent POM, which defines dependencies and plugins for
> subprojects to use.
> > > > > > >
> > > > > > > Although I feel this is a "cleaner" architecture, I've never
> > > > > > > been able
> > > > > > to cite specific problems with the other approach, besides the
> > > > > > fact that module changes and dependency/plugin changes go in
> > > > > > the same file, which is still a "cleanliness" argument.
> > > > > > >
> > > > > > > Today I think I saw a real reason why the present
> > > > > > > architecture is a
> > > > > > problem, but I need to be certain the problem I'm seeing is
> > > > > > caused by this, and that the better architecture fixes this
> > > > > > problem, and whether there is a simple workaround in the
> meantime.
> > > > > > >
> > > > > > > I've been modifying the build to use a completely new
> > > > > > > intranet maven
> > > > > > repo and completely different groupids for the build
> artifacts.
> > > > > > >
> > > > > > > I saw errors like this (with elisions):
> > > > > > > -----------------------
> > > > > > > [INFO] Reactor Summary:
> > > > > > > [INFO]
> > > > > > > [INFO] big-parent .........................................
> > > > > > > FAILURE [
> > > > > > 5.230 s]
> > > > > > > [INFO] some-other-module...................................
> > > > > > > SKIPPED [INFO]
> > > > > > > another-module...................................... SKIPPED
> > > > > > > [INFO]
> > > > > > > .....................................................SKIPPED
> > > > > > > [INFO]
> > > > > > --------------------------------------------------------------
> > > > > > ----
> > > > > > ----
> > > > > > --
> > > > > > > [INFO] BUILD FAILURE
> > > > > > > [INFO]
> > > > > > --------------------------------------------------------------
> > > > > > ----
> > > > > > ----
> > > > > > --
> > > > > > > [INFO] Total time: 8.063 s
> > > > > > > [INFO] Finished at: 2016-11-29T16:23:36-08:00 [INFO] Final
> > > Memory:
> > > > > > > 41M/1093M [INFO]
> > > > > > --------------------------------------------------------------
> > > > > > ----
> > > > > > ----
> > > > > > --
> > > > > > > [ERROR] Failed to execute goal on project some-other-module:
> > > > > > > Could not
> > > > > > resolve dependencies for project
> > > > > > com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT:
> > > > > > Could not find artifact
> > > > > > com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
> > > > > > mycomp-public-group (
> > > > > > http://mavencentral.it.mycomp.com:8084/nexus/content/repositor
> > > > > > ies/
> > > > > > myco
> > > > > > mp-public-group/)
> > > > > > -> [Help 1]
> > > > > > > [ERROR]
> > > > > > > ---------------
> > > > > > >
> > > > > > > The "big-parent" module is the top-level directory that is
> > > > > > > both the
> > > > > > aggregator and parent pom.
> > > > > > >
> > > > > > > Conceptually, I think this is happening because Maven is
> > > > > > > trying to
> > > > > > evaluate dependencies before those dependencies are built.
> > > > > > Again, I think the "separated" architecture will resolve this,
> > > > > > but before I implement that, I need to understand exactly what
> > > > > > is going on
> > > here.
> > > > > > >
> > > > > > > In my local workspace, I got around this by simply "cd"ing
> > > > > > > to the
> > > > > > "another-module" directory and doing a "mvn install", then
> > > > > > "cd"ing to "some-other-module", doing the same, and then doing
> > > > > > the same again at the top level. The reality was messier than
> > > > > > this, because I had quite a few modules that I had to build
> manually this way.
> > > > > > >
> > > > > > > Assuming I'm right that separating the "parent" function
> > > > > > > from the
> > > > > > "aggregator" function would resolve this, can someone explain
> > > > > > exactly what is happening here, how my assumed solution would
> > > > > > resolve this, and whether there's a cleaner temporary
> > > > > > workaround besides "cd"ing into each directory to do a
> separate install?
> > > > > > >
> > > > > > > ------------------------------------------------------------
> > > > > > > ----
> > > > > > > ----
> > > > > > > - To unsubscribe, e-mail: [hidden email]
> > > > > > > For additional commands, e-mail: [hidden email]
> > > > > > >
> > > > > >
> > > > > > --------------------------------------------------------------
> > > > > > ----
> > > > > > --- To unsubscribe, e-mail: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > > > >
> > > > > > --
> > > > > Sent from my phone
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Need to fully understand bad implications of combined aggregator and parent pom

Curtis Rueden
Hi David,

> The fact is, when I ensured that both the local and intranet repo is
> EMPTY of build artifacts, including the parent pom, the child modules
> fail to build because they can't find the parent pom, which just
> resides in the parent directory of each child module.

I have never had that problem with multi-module projects that use a
combined parent/aggregator in the top-level directory. This sounds like a
bug to me. Can you please create an SSCCE / MCVE? Then maybe the community
can comment further on what is going wrong for you.

Regards,
Curtis


--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software


On Wed, Nov 30, 2016 at 7:59 PM, KARR, DAVID <[hidden email]> wrote:

> > -----Original Message-----
> > From: Dan Tran [mailto:[hidden email]]
> > Sent: Wednesday, November 30, 2016 5:10 PM
> > To: Maven Users List <[hidden email]>
> > Subject: Re: Need to fully understand bad implications of combined
> > aggregator and parent pom
> >
> > Correct we dont ever enter relativePath. The implicit one should work
> > and should never see warning that a module can't find its parent
>
> Uh, whatever.  You're clearly disagreeing with me, so saying "correct"
> just confuses things.
>
> The fact is, when I ensured that both the local and intranet repo is EMPTY
> of build artifacts, including the parent pom, the child modules fail to
> build because they can't find the parent pom, which just resides in the
> parent directory of each child module.
>
> I never tried adding a "<relativePath>..</relativePath> to all of the
> parent pom references, but I was able to get it to work by splitting out
> the parent pom responsibilities into a separate child module pom, and
> having all the references specify the relative path to that.
>
> > On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID <[hidden email]> wrote:
> >
> > > > -----Original Message-----
> > > > From: Dan Tran [mailto:[hidden email]]
> > > > Sent: Wednesday, November 30, 2016 3:17 PM
> > > > To: Maven Users List <[hidden email]>
> > > > Subject: Re: Need to fully understand bad implications of combined
> > > > aggregator and parent pom
> > > >
> > > > I concur with Ben,  aggregator module is banned at my work. Top
> > > > level parent hosts all modules
> > >
> > > So does this mean that you utilize "relativePath" in the child
> > > module's parent definitions?  Otherwise, the child modules are being
> > > built before the POM for the top-level POM is installed (which happens
> > > at the end of the build).
> > >
> > > > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <[hidden email]> wrote:
> > > >
> > > > > > -----Original Message-----
> > > > > > From: Stephen Connolly [mailto:[hidden email]]
> > > > > > Sent: Wednesday, November 30, 2016 1:01 PM
> > > > > > To: Maven Users List <[hidden email]>
> > > > > > Subject: Re: Need to fully understand bad implications of
> > > > > > combined aggregator and parent pom
> > > > > >
> > > > > > You do have relativePath set correctly for the separate parent
> > > > > > from aggregator?
> > > > >
> > > > > Not sure whether you're addressing Benson or me, but setting
> > > > > relativePath is definitely a requirement, and I think the error
> > > > > message you get is pretty clear when you don’t have it, so I
> > > > > imagine
> > > > that's not Benson's issue.
> > > > >
> > > > > In my case, I did some cut/pasting and some global replaces to
> > > > > separate the POM into parent and aggregator, and now my build
> > > > > works from the top with empty repositories.
> > > > >
> > > > > I don't use the site plugin.
> > > > >
> > > > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
> > > > > > <[hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > My experience is precisely the opposite of yours. The most
> > > > > > > common practice is for the parent to be the aggregator; it's
> > > > > > > hard to get the site plugin, for example, to work right with
> > > > > > > your preferred structure where they are different.
> > > > > > >
> > > > > > > I have built many projects with the the one-parent structure,
> > > > > > > and they typically have interdependencies between the modules,
> > > > > > > and they work fine.  Can you boil this down to a failing case
> > > > > > > on github? Can you share some poms?
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID <[hidden email]>
> > > > wrote:
> > > > > > > > A while ago, I started working on an existing project with
> > > > > > > > many
> > > > > > > developers.  The codebase has a large multi-project Maven
> > build.
> > > > > > > The top directory is both an "aggregator" and "parent" POM, as
> > > > > > > it has a
> > > > > > "modules"
> > > > > > > list, and all of the child modules have it as their parent
> > > > > > > POM, for dependencies and plugins.
> > > > > > > >
> > > > > > > > I've always believed this is a defective architecture.  I
> > > > > > > > believe that
> > > > > > > the top-level directory should have an "aggregator" POM that
> > > > > > > just lists the modules to build, and a subdirectory of the
> > > > > > > top-level directory should have a project that just defines
> > > > > > > the parent POM, which defines dependencies and plugins for
> > subprojects to use.
> > > > > > > >
> > > > > > > > Although I feel this is a "cleaner" architecture, I've never
> > > > > > > > been able
> > > > > > > to cite specific problems with the other approach, besides the
> > > > > > > fact that module changes and dependency/plugin changes go in
> > > > > > > the same file, which is still a "cleanliness" argument.
> > > > > > > >
> > > > > > > > Today I think I saw a real reason why the present
> > > > > > > > architecture is a
> > > > > > > problem, but I need to be certain the problem I'm seeing is
> > > > > > > caused by this, and that the better architecture fixes this
> > > > > > > problem, and whether there is a simple workaround in the
> > meantime.
> > > > > > > >
> > > > > > > > I've been modifying the build to use a completely new
> > > > > > > > intranet maven
> > > > > > > repo and completely different groupids for the build
> > artifacts.
> > > > > > > >
> > > > > > > > I saw errors like this (with elisions):
> > > > > > > > -----------------------
> > > > > > > > [INFO] Reactor Summary:
> > > > > > > > [INFO]
> > > > > > > > [INFO] big-parent .........................................
> > > > > > > > FAILURE [
> > > > > > > 5.230 s]
> > > > > > > > [INFO] some-other-module...................................
> > > > > > > > SKIPPED [INFO]
> > > > > > > > another-module...................................... SKIPPED
> > > > > > > > [INFO]
> > > > > > > > .....................................................SKIPPED
> > > > > > > > [INFO]
> > > > > > > --------------------------------------------------------------
> > > > > > > ----
> > > > > > > ----
> > > > > > > --
> > > > > > > > [INFO] BUILD FAILURE
> > > > > > > > [INFO]
> > > > > > > --------------------------------------------------------------
> > > > > > > ----
> > > > > > > ----
> > > > > > > --
> > > > > > > > [INFO] Total time: 8.063 s
> > > > > > > > [INFO] Finished at: 2016-11-29T16:23:36-08:00 [INFO] Final
> > > > Memory:
> > > > > > > > 41M/1093M [INFO]
> > > > > > > --------------------------------------------------------------
> > > > > > > ----
> > > > > > > ----
> > > > > > > --
> > > > > > > > [ERROR] Failed to execute goal on project some-other-module:
> > > > > > > > Could not
> > > > > > > resolve dependencies for project
> > > > > > > com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT:
> > > > > > > Could not find artifact
> > > > > > > com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
> > > > > > > mycomp-public-group (
> > > > > > > http://mavencentral.it.mycomp.com:8084/nexus/content/repositor
> > > > > > > ies/
> > > > > > > myco
> > > > > > > mp-public-group/)
> > > > > > > -> [Help 1]
> > > > > > > > [ERROR]
> > > > > > > > ---------------
> > > > > > > >
> > > > > > > > The "big-parent" module is the top-level directory that is
> > > > > > > > both the
> > > > > > > aggregator and parent pom.
> > > > > > > >
> > > > > > > > Conceptually, I think this is happening because Maven is
> > > > > > > > trying to
> > > > > > > evaluate dependencies before those dependencies are built.
> > > > > > > Again, I think the "separated" architecture will resolve this,
> > > > > > > but before I implement that, I need to understand exactly what
> > > > > > > is going on
> > > > here.
> > > > > > > >
> > > > > > > > In my local workspace, I got around this by simply "cd"ing
> > > > > > > > to the
> > > > > > > "another-module" directory and doing a "mvn install", then
> > > > > > > "cd"ing to "some-other-module", doing the same, and then doing
> > > > > > > the same again at the top level. The reality was messier than
> > > > > > > this, because I had quite a few modules that I had to build
> > manually this way.
> > > > > > > >
> > > > > > > > Assuming I'm right that separating the "parent" function
> > > > > > > > from the
> > > > > > > "aggregator" function would resolve this, can someone explain
> > > > > > > exactly what is happening here, how my assumed solution would
> > > > > > > resolve this, and whether there's a cleaner temporary
> > > > > > > workaround besides "cd"ing into each directory to do a
> > separate install?
> > > > > > > >
> > > > > > > > ------------------------------------------------------------
> > > > > > > > ----
> > > > > > > > ----
> > > > > > > > - To unsubscribe, e-mail: [hidden email]
> > > > > > > > For additional commands, e-mail: [hidden email]
> > > > > > > >
> > > > > > >
> > > > > > > --------------------------------------------------------------
> > > > > > > ----
> > > > > > > --- To unsubscribe, e-mail: [hidden email]
> > > > > > > For additional commands, e-mail: [hidden email]
> > > > > > >
> > > > > > > --
> > > > > > Sent from my phone
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
>
Reply | Threaded
Open this post in threaded view
|

Re: Need to fully understand bad implications of combined aggregator and parent pom

João Cabrita
My experience has been that combining parent and aggregator concerns into
the root module causes trouble for "aggregator-style" goals like
"javadoc-aggregate" that depend on artifacts generated by the submodules.

The reason seems to be that, when using such goals, there is a cyclic
dependency: the parent/aggregator depends on its submodules for the
artifacts and the submodules depend on the parent/aggregator for it's
configuration.
This leads me to believe that filing this as a bug isn't entirely correct.

To be more specific, for a module A that is both parent and aggregator of
submodules B and C, the build order is A B C.
When A is just an aggregator and B, C and P are submodules of A, with P
being parent of B and C, the build order is P B C A.
Notice that the aggregator has moved from the start of the list (because
the children depend on it) to the end (because they no longer do).

João Cabrita

On 1 December 2016 at 04:26, Curtis Rueden <[hidden email]> wrote:

> Hi David,
>
> > The fact is, when I ensured that both the local and intranet repo is
> > EMPTY of build artifacts, including the parent pom, the child modules
> > fail to build because they can't find the parent pom, which just
> > resides in the parent directory of each child module.
>
> I have never had that problem with multi-module projects that use a
> combined parent/aggregator in the top-level directory. This sounds like a
> bug to me. Can you please create an SSCCE / MCVE? Then maybe the community
> can comment further on what is going wrong for you.
>
> Regards,
> Curtis
>
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
>
>
> On Wed, Nov 30, 2016 at 7:59 PM, KARR, DAVID <[hidden email]> wrote:
>
> > > -----Original Message-----
> > > From: Dan Tran [mailto:[hidden email]]
> > > Sent: Wednesday, November 30, 2016 5:10 PM
> > > To: Maven Users List <[hidden email]>
> > > Subject: Re: Need to fully understand bad implications of combined
> > > aggregator and parent pom
> > >
> > > Correct we dont ever enter relativePath. The implicit one should work
> > > and should never see warning that a module can't find its parent
> >
> > Uh, whatever.  You're clearly disagreeing with me, so saying "correct"
> > just confuses things.
> >
> > The fact is, when I ensured that both the local and intranet repo is
> EMPTY
> > of build artifacts, including the parent pom, the child modules fail to
> > build because they can't find the parent pom, which just resides in the
> > parent directory of each child module.
> >
> > I never tried adding a "<relativePath>..</relativePath> to all of the
> > parent pom references, but I was able to get it to work by splitting out
> > the parent pom responsibilities into a separate child module pom, and
> > having all the references specify the relative path to that.
> >
> > > On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID <[hidden email]> wrote:
> > >
> > > > > -----Original Message-----
> > > > > From: Dan Tran [mailto:[hidden email]]
> > > > > Sent: Wednesday, November 30, 2016 3:17 PM
> > > > > To: Maven Users List <[hidden email]>
> > > > > Subject: Re: Need to fully understand bad implications of combined
> > > > > aggregator and parent pom
> > > > >
> > > > > I concur with Ben,  aggregator module is banned at my work. Top
> > > > > level parent hosts all modules
> > > >
> > > > So does this mean that you utilize "relativePath" in the child
> > > > module's parent definitions?  Otherwise, the child modules are being
> > > > built before the POM for the top-level POM is installed (which
> happens
> > > > at the end of the build).
> > > >
> > > > > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <[hidden email]>
> wrote:
> > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Stephen Connolly [mailto:[hidden email]
> ]
> > > > > > > Sent: Wednesday, November 30, 2016 1:01 PM
> > > > > > > To: Maven Users List <[hidden email]>
> > > > > > > Subject: Re: Need to fully understand bad implications of
> > > > > > > combined aggregator and parent pom
> > > > > > >
> > > > > > > You do have relativePath set correctly for the separate parent
> > > > > > > from aggregator?
> > > > > >
> > > > > > Not sure whether you're addressing Benson or me, but setting
> > > > > > relativePath is definitely a requirement, and I think the error
> > > > > > message you get is pretty clear when you don’t have it, so I
> > > > > > imagine
> > > > > that's not Benson's issue.
> > > > > >
> > > > > > In my case, I did some cut/pasting and some global replaces to
> > > > > > separate the POM into parent and aggregator, and now my build
> > > > > > works from the top with empty repositories.
> > > > > >
> > > > > > I don't use the site plugin.
> > > > > >
> > > > > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
> > > > > > > <[hidden email]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > My experience is precisely the opposite of yours. The most
> > > > > > > > common practice is for the parent to be the aggregator; it's
> > > > > > > > hard to get the site plugin, for example, to work right with
> > > > > > > > your preferred structure where they are different.
> > > > > > > >
> > > > > > > > I have built many projects with the the one-parent structure,
> > > > > > > > and they typically have interdependencies between the
> modules,
> > > > > > > > and they work fine.  Can you boil this down to a failing case
> > > > > > > > on github? Can you share some poms?
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID <[hidden email]
> >
> > > > > wrote:
> > > > > > > > > A while ago, I started working on an existing project with
> > > > > > > > > many
> > > > > > > > developers.  The codebase has a large multi-project Maven
> > > build.
> > > > > > > > The top directory is both an "aggregator" and "parent" POM,
> as
> > > > > > > > it has a
> > > > > > > "modules"
> > > > > > > > list, and all of the child modules have it as their parent
> > > > > > > > POM, for dependencies and plugins.
> > > > > > > > >
> > > > > > > > > I've always believed this is a defective architecture.  I
> > > > > > > > > believe that
> > > > > > > > the top-level directory should have an "aggregator" POM that
> > > > > > > > just lists the modules to build, and a subdirectory of the
> > > > > > > > top-level directory should have a project that just defines
> > > > > > > > the parent POM, which defines dependencies and plugins for
> > > subprojects to use.
> > > > > > > > >
> > > > > > > > > Although I feel this is a "cleaner" architecture, I've
> never
> > > > > > > > > been able
> > > > > > > > to cite specific problems with the other approach, besides
> the
> > > > > > > > fact that module changes and dependency/plugin changes go in
> > > > > > > > the same file, which is still a "cleanliness" argument.
> > > > > > > > >
> > > > > > > > > Today I think I saw a real reason why the present
> > > > > > > > > architecture is a
> > > > > > > > problem, but I need to be certain the problem I'm seeing is
> > > > > > > > caused by this, and that the better architecture fixes this
> > > > > > > > problem, and whether there is a simple workaround in the
> > > meantime.
> > > > > > > > >
> > > > > > > > > I've been modifying the build to use a completely new
> > > > > > > > > intranet maven
> > > > > > > > repo and completely different groupids for the build
> > > artifacts.
> > > > > > > > >
> > > > > > > > > I saw errors like this (with elisions):
> > > > > > > > > -----------------------
> > > > > > > > > [INFO] Reactor Summary:
> > > > > > > > > [INFO]
> > > > > > > > > [INFO] big-parent ..............................
> ...........
> > > > > > > > > FAILURE [
> > > > > > > > 5.230 s]
> > > > > > > > > [INFO] some-other-module.............
> ......................
> > > > > > > > > SKIPPED [INFO]
> > > > > > > > > another-module......................................
> SKIPPED
> > > > > > > > > [INFO]
> > > > > > > > > ..............................
> .......................SKIPPED
> > > > > > > > > [INFO]
> > > > > > > > ------------------------------------------------------------
> --
> > > > > > > > ----
> > > > > > > > ----
> > > > > > > > --
> > > > > > > > > [INFO] BUILD FAILURE
> > > > > > > > > [INFO]
> > > > > > > > ------------------------------------------------------------
> --
> > > > > > > > ----
> > > > > > > > ----
> > > > > > > > --
> > > > > > > > > [INFO] Total time: 8.063 s
> > > > > > > > > [INFO] Finished at: 2016-11-29T16:23:36-08:00 [INFO] Final
> > > > > Memory:
> > > > > > > > > 41M/1093M [INFO]
> > > > > > > > ------------------------------------------------------------
> --
> > > > > > > > ----
> > > > > > > > ----
> > > > > > > > --
> > > > > > > > > [ERROR] Failed to execute goal on project
> some-other-module:
> > > > > > > > > Could not
> > > > > > > > resolve dependencies for project
> > > > > > > > com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT:
> > > > > > > > Could not find artifact
> > > > > > > > com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
> > > > > > > > mycomp-public-group (
> > > > > > > > http://mavencentral.it.mycomp.com:8084/nexus/content/
> repositor
> > > > > > > > ies/
> > > > > > > > myco
> > > > > > > > mp-public-group/)
> > > > > > > > -> [Help 1]
> > > > > > > > > [ERROR]
> > > > > > > > > ---------------
> > > > > > > > >
> > > > > > > > > The "big-parent" module is the top-level directory that is
> > > > > > > > > both the
> > > > > > > > aggregator and parent pom.
> > > > > > > > >
> > > > > > > > > Conceptually, I think this is happening because Maven is
> > > > > > > > > trying to
> > > > > > > > evaluate dependencies before those dependencies are built.
> > > > > > > > Again, I think the "separated" architecture will resolve
> this,
> > > > > > > > but before I implement that, I need to understand exactly
> what
> > > > > > > > is going on
> > > > > here.
> > > > > > > > >
> > > > > > > > > In my local workspace, I got around this by simply "cd"ing
> > > > > > > > > to the
> > > > > > > > "another-module" directory and doing a "mvn install", then
> > > > > > > > "cd"ing to "some-other-module", doing the same, and then
> doing
> > > > > > > > the same again at the top level. The reality was messier than
> > > > > > > > this, because I had quite a few modules that I had to build
> > > manually this way.
> > > > > > > > >
> > > > > > > > > Assuming I'm right that separating the "parent" function
> > > > > > > > > from the
> > > > > > > > "aggregator" function would resolve this, can someone explain
> > > > > > > > exactly what is happening here, how my assumed solution would
> > > > > > > > resolve this, and whether there's a cleaner temporary
> > > > > > > > workaround besides "cd"ing into each directory to do a
> > > separate install?
> > > > > > > > >
> > > > > > > > > ------------------------------
> ------------------------------
> > > > > > > > > ----
> > > > > > > > > ----
> > > > > > > > > - To unsubscribe, e-mail: users-unsubscribe@maven.
> apache.org
> > > > > > > > > For additional commands, e-mail:
> [hidden email]
> > > > > > > > >
> > > > > > > >
> > > > > > > > ------------------------------------------------------------
> --
> > > > > > > > ----
> > > > > > > > --- To unsubscribe, e-mail: users-unsubscribe@maven.
> apache.org
> > > > > > > > For additional commands, e-mail: [hidden email]
> > > > > > > >
> > > > > > > > --
> > > > > > > Sent from my phone
> > > > > >
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Need to fully understand bad implications of combined aggregator and parent pom

Hilco Wijbenga-3
Indeed, combining the parent and aggregator concerns in one POM is not
a good idea. I would go so far as to call it an anti-pattern. A very
common one, unfortunately.

First, you get a cycle per module. Cycles are never a good thing,
though sometimes they are unavoidable. Maven seems to be fine with
this particular type of cycle but you still get strange behaviour on
occasion. A build may break (especially when starting with an empty
repository) with a strange error message but a second attempt may
succeed. That's also (probably) why it is usually not recognised as a
problem. If the second build succeeds you tend to shrug your shoulders
and move on.

Let's say you have an enormous Java file of 10,000 lines of code. I
don't think anyone would consider that good design. Similarly, if you
have a single project with some 4,000 Java files. Again, I don't think
anyone would consider that an example of good design. In both cases,
we would argue that it needs to be broken up because, clearly,
separate/independent concerns have been conflated. And it is all just
too hard to understand, too hard to test, and too hard to maintain.

So why would it be a good idea to put all POM related concerns in one
place? Especially when it comes to modules, they are *only* relevant
at compile time. There is absolutely no reason to know about this at
any other time. In fact, my aggregator POMs have a version "modules"
(that looks nice in the build output) that never changes and they all
set <maven.deploy.skip>.

But it goes beyond that. If you have a JAR project and a WAR project
then it makes sense to have a separate parent-jar-pom and
parent-war-pom. The parent-jar-pom would only need to know about
compiling Java code and putting it in a JAR. Very simple. The
parent-war-pom, however, would need to know about JSP compilation
(e.g.) and how to run the WAR with Tomcat or Jetty. Perhaps the
parent-war-pom extends the parent-jar-pom but in any case there is no
need for this additional complexity to be in the parent-jar-pom.

I think the core difference between these philosophies is choosing
between "easy" and "simple". It may be easy to put everything in one
POM, but it will cost you in maintenance effort. It takes more effort
and thought to simplify things and try and separate independent
concerns into separate POMs but your maintenance burden will be
lighter. Why? Because if you change something about the JSP
compilation only your WAR projects will be affected. Such cause and
effect is easy to explain and understand: it's simple. :-) Remember,
we're not just going to have to explain this to our colleagues but
also (e.g.) our manager and the change control board.

With a single parent-pom, naturally, you could simply not upgrade your
JAR project to the latest parent POM (the one with the JSP compilation
changes) but then you are forcing your maintenance developers to know
the difference between multiple versions of the parent POM. And this
very quickly becomes more than 2 and for more than 1 project. This is
your typical "throw it over the fence" approach. Having been on the
other side of that fence, I would consider that "not nice".

On 2 December 2016 at 04:02, João Cabrita <[hidden email]> wrote:

> My experience has been that combining parent and aggregator concerns into
> the root module causes trouble for "aggregator-style" goals like
> "javadoc-aggregate" that depend on artifacts generated by the submodules.
>
> The reason seems to be that, when using such goals, there is a cyclic
> dependency: the parent/aggregator depends on its submodules for the
> artifacts and the submodules depend on the parent/aggregator for it's
> configuration.
> This leads me to believe that filing this as a bug isn't entirely correct.
>
> To be more specific, for a module A that is both parent and aggregator of
> submodules B and C, the build order is A B C.
> When A is just an aggregator and B, C and P are submodules of A, with P
> being parent of B and C, the build order is P B C A.
> Notice that the aggregator has moved from the start of the list (because
> the children depend on it) to the end (because they no longer do).
>
> João Cabrita
>
> On 1 December 2016 at 04:26, Curtis Rueden <[hidden email]> wrote:
>
>> Hi David,
>>
>> > The fact is, when I ensured that both the local and intranet repo is
>> > EMPTY of build artifacts, including the parent pom, the child modules
>> > fail to build because they can't find the parent pom, which just
>> > resides in the parent directory of each child module.
>>
>> I have never had that problem with multi-module projects that use a
>> combined parent/aggregator in the top-level directory. This sounds like a
>> bug to me. Can you please create an SSCCE / MCVE? Then maybe the community
>> can comment further on what is going wrong for you.
>>
>> Regards,
>> Curtis
>>
>>
>> --
>> Curtis Rueden
>> LOCI software architect - http://loci.wisc.edu/software
>>
>>
>> On Wed, Nov 30, 2016 at 7:59 PM, KARR, DAVID <[hidden email]> wrote:
>>
>> > > -----Original Message-----
>> > > From: Dan Tran [mailto:[hidden email]]
>> > > Sent: Wednesday, November 30, 2016 5:10 PM
>> > > To: Maven Users List <[hidden email]>
>> > > Subject: Re: Need to fully understand bad implications of combined
>> > > aggregator and parent pom
>> > >
>> > > Correct we dont ever enter relativePath. The implicit one should work
>> > > and should never see warning that a module can't find its parent
>> >
>> > Uh, whatever.  You're clearly disagreeing with me, so saying "correct"
>> > just confuses things.
>> >
>> > The fact is, when I ensured that both the local and intranet repo is
>> EMPTY
>> > of build artifacts, including the parent pom, the child modules fail to
>> > build because they can't find the parent pom, which just resides in the
>> > parent directory of each child module.
>> >
>> > I never tried adding a "<relativePath>..</relativePath> to all of the
>> > parent pom references, but I was able to get it to work by splitting out
>> > the parent pom responsibilities into a separate child module pom, and
>> > having all the references specify the relative path to that.
>> >
>> > > On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID <[hidden email]> wrote:
>> > >
>> > > > > -----Original Message-----
>> > > > > From: Dan Tran [mailto:[hidden email]]
>> > > > > Sent: Wednesday, November 30, 2016 3:17 PM
>> > > > > To: Maven Users List <[hidden email]>
>> > > > > Subject: Re: Need to fully understand bad implications of combined
>> > > > > aggregator and parent pom
>> > > > >
>> > > > > I concur with Ben,  aggregator module is banned at my work. Top
>> > > > > level parent hosts all modules
>> > > >
>> > > > So does this mean that you utilize "relativePath" in the child
>> > > > module's parent definitions?  Otherwise, the child modules are being
>> > > > built before the POM for the top-level POM is installed (which
>> happens
>> > > > at the end of the build).
>> > > >
>> > > > > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <[hidden email]>
>> wrote:
>> > > > >
>> > > > > > > -----Original Message-----
>> > > > > > > From: Stephen Connolly [mailto:[hidden email]
>> ]
>> > > > > > > Sent: Wednesday, November 30, 2016 1:01 PM
>> > > > > > > To: Maven Users List <[hidden email]>
>> > > > > > > Subject: Re: Need to fully understand bad implications of
>> > > > > > > combined aggregator and parent pom
>> > > > > > >
>> > > > > > > You do have relativePath set correctly for the separate parent
>> > > > > > > from aggregator?
>> > > > > >
>> > > > > > Not sure whether you're addressing Benson or me, but setting
>> > > > > > relativePath is definitely a requirement, and I think the error
>> > > > > > message you get is pretty clear when you don’t have it, so I
>> > > > > > imagine
>> > > > > that's not Benson's issue.
>> > > > > >
>> > > > > > In my case, I did some cut/pasting and some global replaces to
>> > > > > > separate the POM into parent and aggregator, and now my build
>> > > > > > works from the top with empty repositories.
>> > > > > >
>> > > > > > I don't use the site plugin.
>> > > > > >
>> > > > > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
>> > > > > > > <[hidden email]>
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > My experience is precisely the opposite of yours. The most
>> > > > > > > > common practice is for the parent to be the aggregator; it's
>> > > > > > > > hard to get the site plugin, for example, to work right with
>> > > > > > > > your preferred structure where they are different.
>> > > > > > > >
>> > > > > > > > I have built many projects with the the one-parent structure,
>> > > > > > > > and they typically have interdependencies between the
>> modules,
>> > > > > > > > and they work fine.  Can you boil this down to a failing case
>> > > > > > > > on github? Can you share some poms?
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID <[hidden email]
>> >
>> > > > > wrote:
>> > > > > > > > > A while ago, I started working on an existing project with
>> > > > > > > > > many
>> > > > > > > > developers.  The codebase has a large multi-project Maven
>> > > build.
>> > > > > > > > The top directory is both an "aggregator" and "parent" POM,
>> as
>> > > > > > > > it has a
>> > > > > > > "modules"
>> > > > > > > > list, and all of the child modules have it as their parent
>> > > > > > > > POM, for dependencies and plugins.
>> > > > > > > > >
>> > > > > > > > > I've always believed this is a defective architecture.  I
>> > > > > > > > > believe that
>> > > > > > > > the top-level directory should have an "aggregator" POM that
>> > > > > > > > just lists the modules to build, and a subdirectory of the
>> > > > > > > > top-level directory should have a project that just defines
>> > > > > > > > the parent POM, which defines dependencies and plugins for
>> > > subprojects to use.
>> > > > > > > > >
>> > > > > > > > > Although I feel this is a "cleaner" architecture, I've
>> never
>> > > > > > > > > been able
>> > > > > > > > to cite specific problems with the other approach, besides
>> the
>> > > > > > > > fact that module changes and dependency/plugin changes go in
>> > > > > > > > the same file, which is still a "cleanliness" argument.
>> > > > > > > > >
>> > > > > > > > > Today I think I saw a real reason why the present
>> > > > > > > > > architecture is a
>> > > > > > > > problem, but I need to be certain the problem I'm seeing is
>> > > > > > > > caused by this, and that the better architecture fixes this
>> > > > > > > > problem, and whether there is a simple workaround in the
>> > > meantime.
>> > > > > > > > >
>> > > > > > > > > I've been modifying the build to use a completely new
>> > > > > > > > > intranet maven
>> > > > > > > > repo and completely different groupids for the build
>> > > artifacts.
>> > > > > > > > >
>> > > > > > > > > I saw errors like this (with elisions):
>> > > > > > > > > -----------------------
>> > > > > > > > > [INFO] Reactor Summary:
>> > > > > > > > > [INFO]
>> > > > > > > > > [INFO] big-parent ..............................
>> ...........
>> > > > > > > > > FAILURE [
>> > > > > > > > 5.230 s]
>> > > > > > > > > [INFO] some-other-module.............
>> ......................
>> > > > > > > > > SKIPPED [INFO]
>> > > > > > > > > another-module......................................
>> SKIPPED
>> > > > > > > > > [INFO]
>> > > > > > > > > ..............................
>> .......................SKIPPED
>> > > > > > > > > [INFO]
>> > > > > > > > ------------------------------------------------------------
>> --
>> > > > > > > > ----
>> > > > > > > > ----
>> > > > > > > > --
>> > > > > > > > > [INFO] BUILD FAILURE
>> > > > > > > > > [INFO]
>> > > > > > > > ------------------------------------------------------------
>> --
>> > > > > > > > ----
>> > > > > > > > ----
>> > > > > > > > --
>> > > > > > > > > [INFO] Total time: 8.063 s
>> > > > > > > > > [INFO] Finished at: 2016-11-29T16:23:36-08:00 [INFO] Final
>> > > > > Memory:
>> > > > > > > > > 41M/1093M [INFO]
>> > > > > > > > ------------------------------------------------------------
>> --
>> > > > > > > > ----
>> > > > > > > > ----
>> > > > > > > > --
>> > > > > > > > > [ERROR] Failed to execute goal on project
>> some-other-module:
>> > > > > > > > > Could not
>> > > > > > > > resolve dependencies for project
>> > > > > > > > com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT:
>> > > > > > > > Could not find artifact
>> > > > > > > > com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
>> > > > > > > > mycomp-public-group (
>> > > > > > > > http://mavencentral.it.mycomp.com:8084/nexus/content/
>> repositor
>> > > > > > > > ies/
>> > > > > > > > myco
>> > > > > > > > mp-public-group/)
>> > > > > > > > -> [Help 1]
>> > > > > > > > > [ERROR]
>> > > > > > > > > ---------------
>> > > > > > > > >
>> > > > > > > > > The "big-parent" module is the top-level directory that is
>> > > > > > > > > both the
>> > > > > > > > aggregator and parent pom.
>> > > > > > > > >
>> > > > > > > > > Conceptually, I think this is happening because Maven is
>> > > > > > > > > trying to
>> > > > > > > > evaluate dependencies before those dependencies are built.
>> > > > > > > > Again, I think the "separated" architecture will resolve
>> this,
>> > > > > > > > but before I implement that, I need to understand exactly
>> what
>> > > > > > > > is going on
>> > > > > here.
>> > > > > > > > >
>> > > > > > > > > In my local workspace, I got around this by simply "cd"ing
>> > > > > > > > > to the
>> > > > > > > > "another-module" directory and doing a "mvn install", then
>> > > > > > > > "cd"ing to "some-other-module", doing the same, and then
>> doing
>> > > > > > > > the same again at the top level. The reality was messier than
>> > > > > > > > this, because I had quite a few modules that I had to build
>> > > manually this way.
>> > > > > > > > >
>> > > > > > > > > Assuming I'm right that separating the "parent" function
>> > > > > > > > > from the
>> > > > > > > > "aggregator" function would resolve this, can someone explain
>> > > > > > > > exactly what is happening here, how my assumed solution would
>> > > > > > > > resolve this, and whether there's a cleaner temporary
>> > > > > > > > workaround besides "cd"ing into each directory to do a
>> > > separate install?
>> > > > > > > > >
>> > > > > > > > > ------------------------------
>> ------------------------------
>> > > > > > > > > ----
>> > > > > > > > > ----
>> > > > > > > > > - To unsubscribe, e-mail: users-unsubscribe@maven.
>> apache.org
>> > > > > > > > > For additional commands, e-mail:
>> [hidden email]
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > > ------------------------------------------------------------
>> --
>> > > > > > > > ----
>> > > > > > > > --- To unsubscribe, e-mail: users-unsubscribe@maven.
>> apache.org
>> > > > > > > > For additional commands, e-mail: [hidden email]
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > Sent from my phone
>> > > > > >
>> > > >
>> > > > ------------------------------------------------------------
>> ---------
>> > > > To unsubscribe, e-mail: [hidden email]
>> > > > For additional commands, e-mail: [hidden email]
>> > > >
>> >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Need to fully understand bad implications of combined aggregator and parent pom

Sander Verhagen
Simple and easy may be in the eye of the beholder. I get a lot of your points (except for the cycles breaking your build, I'm not recognizing that), but my environment is just dramatically different, and the things that you are describing as necessary for your environment, would be unneeded complexity for mine. We have a lot more entirely separate projects, each of which with their own (smaller) constellation (ancestry) of Maven projects. There's a company POM. Each project has a parent POM, that inherits the company POM, and yes, it's an aggregator too. That's never a problem, because the child projects are all unique and different, and aside from a few shared plugin configurations, that we are perfectly happy to have in the company POM, and a few enforcer rules that we are happy to share across the entire project, all the real meat is in the leaf node POM files. I don’t know what JSP compilation you speak of, nor do we have any significant WAR configuration to be shared across modules. I currently have 716 POM files checked out locally (just a quick "find"), just to give you some feeling that my application of Maven isn't just trivial. But it is DIFFERENT than yours. And I like my shared aggregator/parent POMs. Maybe if it hadn't been designed like this, by Maven, for many years now as it is, whatever the world would look like would've been fine too, but now I'm fond of this approach, to be honest :)

One more note, I have learned to be sparse on what to put into the inheritance hierarchy (composition over inheritance, that good stuff), so our parent POMs are also a lot leaner than what I've seen (myself and others do) in the past. Something like this may play into your observations also.

Thanks for everyone's perspective on this, it's interesting!


Sander Verhagen
[hidden email]  ]

NOTICE: my e-mail address has changed. Please remove [hidden email] now and start using [hidden email] from now on. Please update your address book. Thank you!

-----Original Message-----
From: Hilco Wijbenga [mailto:[hidden email]]
Sent: Sunday, December 4, 2016 17:16
To: Maven Users List <[hidden email]>
Subject: Re: Need to fully understand bad implications of combined aggregator and parent pom

Indeed, combining the parent and aggregator concerns in one POM is not a good idea. I would go so far as to call it an anti-pattern. A very common one, unfortunately.

First, you get a cycle per module. Cycles are never a good thing, though sometimes they are unavoidable. Maven seems to be fine with this particular type of cycle but you still get strange behaviour on occasion. A build may break (especially when starting with an empty
repository) with a strange error message but a second attempt may succeed. That's also (probably) why it is usually not recognised as a problem. If the second build succeeds you tend to shrug your shoulders and move on.

Let's say you have an enormous Java file of 10,000 lines of code. I don't think anyone would consider that good design. Similarly, if you have a single project with some 4,000 Java files. Again, I don't think anyone would consider that an example of good design. In both cases, we would argue that it needs to be broken up because, clearly, separate/independent concerns have been conflated. And it is all just too hard to understand, too hard to test, and too hard to maintain.

So why would it be a good idea to put all POM related concerns in one place? Especially when it comes to modules, they are *only* relevant at compile time. There is absolutely no reason to know about this at any other time. In fact, my aggregator POMs have a version "modules"
(that looks nice in the build output) that never changes and they all set <maven.deploy.skip>.

But it goes beyond that. If you have a JAR project and a WAR project then it makes sense to have a separate parent-jar-pom and parent-war-pom. The parent-jar-pom would only need to know about compiling Java code and putting it in a JAR. Very simple. The parent-war-pom, however, would need to know about JSP compilation
(e.g.) and how to run the WAR with Tomcat or Jetty. Perhaps the parent-war-pom extends the parent-jar-pom but in any case there is no need for this additional complexity to be in the parent-jar-pom.

I think the core difference between these philosophies is choosing between "easy" and "simple". It may be easy to put everything in one POM, but it will cost you in maintenance effort. It takes more effort and thought to simplify things and try and separate independent concerns into separate POMs but your maintenance burden will be lighter. Why? Because if you change something about the JSP compilation only your WAR projects will be affected. Such cause and effect is easy to explain and understand: it's simple. :-) Remember, we're not just going to have to explain this to our colleagues but also (e.g.) our manager and the change control board.

With a single parent-pom, naturally, you could simply not upgrade your JAR project to the latest parent POM (the one with the JSP compilation
changes) but then you are forcing your maintenance developers to know the difference between multiple versions of the parent POM. And this very quickly becomes more than 2 and for more than 1 project. This is your typical "throw it over the fence" approach. Having been on the other side of that fence, I would consider that "not nice".

On 2 December 2016 at 04:02, João Cabrita <[hidden email]> wrote:

> My experience has been that combining parent and aggregator concerns
> into the root module causes trouble for "aggregator-style" goals like
> "javadoc-aggregate" that depend on artifacts generated by the submodules.
>
> The reason seems to be that, when using such goals, there is a cyclic
> dependency: the parent/aggregator depends on its submodules for the
> artifacts and the submodules depend on the parent/aggregator for it's
> configuration.
> This leads me to believe that filing this as a bug isn't entirely correct.
>
> To be more specific, for a module A that is both parent and aggregator
> of submodules B and C, the build order is A B C.
> When A is just an aggregator and B, C and P are submodules of A, with
> P being parent of B and C, the build order is P B C A.
> Notice that the aggregator has moved from the start of the list
> (because the children depend on it) to the end (because they no longer do).
>
> João Cabrita
>
> On 1 December 2016 at 04:26, Curtis Rueden <[hidden email]> wrote:
>
>> Hi David,
>>
>> > The fact is, when I ensured that both the local and intranet repo
>> > is EMPTY of build artifacts, including the parent pom, the child
>> > modules fail to build because they can't find the parent pom, which
>> > just resides in the parent directory of each child module.
>>
>> I have never had that problem with multi-module projects that use a
>> combined parent/aggregator in the top-level directory. This sounds
>> like a bug to me. Can you please create an SSCCE / MCVE? Then maybe
>> the community can comment further on what is going wrong for you.
>>
>> Regards,
>> Curtis
>>
>>
>> --
>> Curtis Rueden
>> LOCI software architect - http://loci.wisc.edu/software
>>
>>
>> On Wed, Nov 30, 2016 at 7:59 PM, KARR, DAVID <[hidden email]> wrote:
>>
>> > > -----Original Message-----
>> > > From: Dan Tran [mailto:[hidden email]]
>> > > Sent: Wednesday, November 30, 2016 5:10 PM
>> > > To: Maven Users List <[hidden email]>
>> > > Subject: Re: Need to fully understand bad implications of
>> > > combined aggregator and parent pom
>> > >
>> > > Correct we dont ever enter relativePath. The implicit one should
>> > > work and should never see warning that a module can't find its
>> > > parent
>> >
>> > Uh, whatever.  You're clearly disagreeing with me, so saying "correct"
>> > just confuses things.
>> >
>> > The fact is, when I ensured that both the local and intranet repo
>> > is
>> EMPTY
>> > of build artifacts, including the parent pom, the child modules
>> > fail to build because they can't find the parent pom, which just
>> > resides in the parent directory of each child module.
>> >
>> > I never tried adding a "<relativePath>..</relativePath> to all of
>> > the parent pom references, but I was able to get it to work by
>> > splitting out the parent pom responsibilities into a separate child
>> > module pom, and having all the references specify the relative path to that.
>> >
>> > > On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID <[hidden email]> wrote:
>> > >
>> > > > > -----Original Message-----
>> > > > > From: Dan Tran [mailto:[hidden email]]
>> > > > > Sent: Wednesday, November 30, 2016 3:17 PM
>> > > > > To: Maven Users List <[hidden email]>
>> > > > > Subject: Re: Need to fully understand bad implications of
>> > > > > combined aggregator and parent pom
>> > > > >
>> > > > > I concur with Ben,  aggregator module is banned at my work.
>> > > > > Top level parent hosts all modules
>> > > >
>> > > > So does this mean that you utilize "relativePath" in the child
>> > > > module's parent definitions?  Otherwise, the child modules are
>> > > > being built before the POM for the top-level POM is installed
>> > > > (which
>> happens
>> > > > at the end of the build).
>> > > >
>> > > > > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <[hidden email]>
>> wrote:
>> > > > >
>> > > > > > > -----Original Message-----
>> > > > > > > From: Stephen Connolly
>> > > > > > > [mailto:[hidden email]
>> ]
>> > > > > > > Sent: Wednesday, November 30, 2016 1:01 PM
>> > > > > > > To: Maven Users List <[hidden email]>
>> > > > > > > Subject: Re: Need to fully understand bad implications of
>> > > > > > > combined aggregator and parent pom
>> > > > > > >
>> > > > > > > You do have relativePath set correctly for the separate
>> > > > > > > parent from aggregator?
>> > > > > >
>> > > > > > Not sure whether you're addressing Benson or me, but
>> > > > > > setting relativePath is definitely a requirement, and I
>> > > > > > think the error message you get is pretty clear when you
>> > > > > > don’t have it, so I imagine
>> > > > > that's not Benson's issue.
>> > > > > >
>> > > > > > In my case, I did some cut/pasting and some global replaces
>> > > > > > to separate the POM into parent and aggregator, and now my
>> > > > > > build works from the top with empty repositories.
>> > > > > >
>> > > > > > I don't use the site plugin.
>> > > > > >
>> > > > > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
>> > > > > > > <[hidden email]>
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > My experience is precisely the opposite of yours. The
>> > > > > > > > most common practice is for the parent to be the
>> > > > > > > > aggregator; it's hard to get the site plugin, for
>> > > > > > > > example, to work right with your preferred structure where they are different.
>> > > > > > > >
>> > > > > > > > I have built many projects with the the one-parent
>> > > > > > > > structure, and they typically have interdependencies
>> > > > > > > > between the
>> modules,
>> > > > > > > > and they work fine.  Can you boil this down to a
>> > > > > > > > failing case on github? Can you share some poms?
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID
>> > > > > > > > <[hidden email]
>> >
>> > > > > wrote:
>> > > > > > > > > A while ago, I started working on an existing project
>> > > > > > > > > with many
>> > > > > > > > developers.  The codebase has a large multi-project
>> > > > > > > > Maven
>> > > build.
>> > > > > > > > The top directory is both an "aggregator" and "parent"
>> > > > > > > > POM,
>> as
>> > > > > > > > it has a
>> > > > > > > "modules"
>> > > > > > > > list, and all of the child modules have it as their
>> > > > > > > > parent POM, for dependencies and plugins.
>> > > > > > > > >
>> > > > > > > > > I've always believed this is a defective
>> > > > > > > > > architecture.  I believe that
>> > > > > > > > the top-level directory should have an "aggregator" POM
>> > > > > > > > that just lists the modules to build, and a
>> > > > > > > > subdirectory of the top-level directory should have a
>> > > > > > > > project that just defines the parent POM, which defines
>> > > > > > > > dependencies and plugins for
>> > > subprojects to use.
>> > > > > > > > >
>> > > > > > > > > Although I feel this is a "cleaner" architecture,
>> > > > > > > > > I've
>> never
>> > > > > > > > > been able
>> > > > > > > > to cite specific problems with the other approach,
>> > > > > > > > besides
>> the
>> > > > > > > > fact that module changes and dependency/plugin changes
>> > > > > > > > go in the same file, which is still a "cleanliness" argument.
>> > > > > > > > >
>> > > > > > > > > Today I think I saw a real reason why the present
>> > > > > > > > > architecture is a
>> > > > > > > > problem, but I need to be certain the problem I'm
>> > > > > > > > seeing is caused by this, and that the better
>> > > > > > > > architecture fixes this problem, and whether there is a
>> > > > > > > > simple workaround in the
>> > > meantime.
>> > > > > > > > >
>> > > > > > > > > I've been modifying the build to use a completely new
>> > > > > > > > > intranet maven
>> > > > > > > > repo and completely different groupids for the build
>> > > artifacts.
>> > > > > > > > >
>> > > > > > > > > I saw errors like this (with elisions):
>> > > > > > > > > ----------------------- [INFO] Reactor Summary:
>> > > > > > > > > [INFO]
>> > > > > > > > > [INFO] big-parent ..............................
>> ...........
>> > > > > > > > > FAILURE [
>> > > > > > > > 5.230 s]
>> > > > > > > > > [INFO] some-other-module.............
>> ......................
>> > > > > > > > > SKIPPED [INFO]
>> > > > > > > > > another-module......................................
>> SKIPPED
>> > > > > > > > > [INFO]
>> > > > > > > > > ..............................
>> .......................SKIPPED
>> > > > > > > > > [INFO]
>> > > > > > > > -------------------------------------------------------
>> > > > > > > > -----
>> --
>> > > > > > > > ----
>> > > > > > > > ----
>> > > > > > > > --
>> > > > > > > > > [INFO] BUILD FAILURE
>> > > > > > > > > [INFO]
>> > > > > > > > -------------------------------------------------------
>> > > > > > > > -----
>> --
>> > > > > > > > ----
>> > > > > > > > ----
>> > > > > > > > --
>> > > > > > > > > [INFO] Total time: 8.063 s [INFO] Finished at:
>> > > > > > > > > 2016-11-29T16:23:36-08:00 [INFO] Final
>> > > > > Memory:
>> > > > > > > > > 41M/1093M [INFO]
>> > > > > > > > -------------------------------------------------------
>> > > > > > > > -----
>> --
>> > > > > > > > ----
>> > > > > > > > ----
>> > > > > > > > --
>> > > > > > > > > [ERROR] Failed to execute goal on project
>> some-other-module:
>> > > > > > > > > Could not
>> > > > > > > > resolve dependencies for project
>> > > > > > > > com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT:
>> > > > > > > > Could not find artifact
>> > > > > > > > com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
>> > > > > > > > mycomp-public-group (
>> > > > > > > > http://mavencentral.it.mycomp.com:8084/nexus/content/
>> repositor
>> > > > > > > > ies/
>> > > > > > > > myco
>> > > > > > > > mp-public-group/)
>> > > > > > > > -> [Help 1]
>> > > > > > > > > [ERROR]
>> > > > > > > > > ---------------
>> > > > > > > > >
>> > > > > > > > > The "big-parent" module is the top-level directory
>> > > > > > > > > that is both the
>> > > > > > > > aggregator and parent pom.
>> > > > > > > > >
>> > > > > > > > > Conceptually, I think this is happening because Maven
>> > > > > > > > > is trying to
>> > > > > > > > evaluate dependencies before those dependencies are built.
>> > > > > > > > Again, I think the "separated" architecture will
>> > > > > > > > resolve
>> this,
>> > > > > > > > but before I implement that, I need to understand
>> > > > > > > > exactly
>> what
>> > > > > > > > is going on
>> > > > > here.
>> > > > > > > > >
>> > > > > > > > > In my local workspace, I got around this by simply
>> > > > > > > > > "cd"ing to the
>> > > > > > > > "another-module" directory and doing a "mvn install",
>> > > > > > > > then "cd"ing to "some-other-module", doing the same,
>> > > > > > > > and then
>> doing
>> > > > > > > > the same again at the top level. The reality was
>> > > > > > > > messier than this, because I had quite a few modules
>> > > > > > > > that I had to build
>> > > manually this way.
>> > > > > > > > >
>> > > > > > > > > Assuming I'm right that separating the "parent"
>> > > > > > > > > function from the
>> > > > > > > > "aggregator" function would resolve this, can someone
>> > > > > > > > explain exactly what is happening here, how my assumed
>> > > > > > > > solution would resolve this, and whether there's a
>> > > > > > > > cleaner temporary workaround besides "cd"ing into each
>> > > > > > > > directory to do a
>> > > separate install?
>> > > > > > > > >
>> > > > > > > > > ------------------------------
>> ------------------------------
>> > > > > > > > > ----
>> > > > > > > > > ----
>> > > > > > > > > - To unsubscribe, e-mail: users-unsubscribe@maven.
>> apache.org
>> > > > > > > > > For additional commands, e-mail:
>> [hidden email]
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > > -------------------------------------------------------
>> > > > > > > > -----
>> --
>> > > > > > > > ----
>> > > > > > > > --- To unsubscribe, e-mail: users-unsubscribe@maven.
>> apache.org
>> > > > > > > > For additional commands, e-mail:
>> > > > > > > > [hidden email]
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > Sent from my phone
>> > > > > >
>> > > >
>> > > > ------------------------------------------------------------
>> ---------
>> > > > To unsubscribe, e-mail: [hidden email]
>> > > > For additional commands, e-mail: [hidden email]
>> > > >
>> >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Need to fully understand bad implications of combined aggregator and parent pom

Mirko Friedenhagen-2
Hello,

I use the combined aggregator/parent pom as well. While multiple poms may
be cleaner because of separation of concerns, you might easily end in
duplications for e.g. plugin definitions, which is a shame as well.

Regards
Mirko
--
Sent from my mobile

Am 05.12.2016 10:56 schrieb "Sander Verhagen" <[hidden email]>:

> Simple and easy may be in the eye of the beholder. I get a lot of your
> points (except for the cycles breaking your build, I'm not recognizing
> that), but my environment is just dramatically different, and the things
> that you are describing as necessary for your environment, would be
> unneeded complexity for mine. We have a lot more entirely separate
> projects, each of which with their own (smaller) constellation (ancestry)
> of Maven projects. There's a company POM. Each project has a parent POM,
> that inherits the company POM, and yes, it's an aggregator too. That's
> never a problem, because the child projects are all unique and different,
> and aside from a few shared plugin configurations, that we are perfectly
> happy to have in the company POM, and a few enforcer rules that we are
> happy to share across the entire project, all the real meat is in the leaf
> node POM files. I don’t know what JSP compilation you speak of, nor do we
> have any significant WAR configuration to be shared across modules. I
> currently have 716 POM files checked out locally (just a quick "find"),
> just to give you some feeling that my application of Maven isn't just
> trivial. But it is DIFFERENT than yours. And I like my shared
> aggregator/parent POMs. Maybe if it hadn't been designed like this, by
> Maven, for many years now as it is, whatever the world would look like
> would've been fine too, but now I'm fond of this approach, to be honest :)
>
> One more note, I have learned to be sparse on what to put into the
> inheritance hierarchy (composition over inheritance, that good stuff), so
> our parent POMs are also a lot leaner than what I've seen (myself and
> others do) in the past. Something like this may play into your observations
> also.
>
> Thanks for everyone's perspective on this, it's interesting!
>
>
> Sander Verhagen
> [  [hidden email]  ]
>
> NOTICE: my e-mail address has changed. Please remove [hidden email]
> now and start using [hidden email] from now on. Please update
> your address book. Thank you!
>
> -----Original Message-----
> From: Hilco Wijbenga [mailto:[hidden email]]
> Sent: Sunday, December 4, 2016 17:16
> To: Maven Users List <[hidden email]>
> Subject: Re: Need to fully understand bad implications of combined
> aggregator and parent pom
>
> Indeed, combining the parent and aggregator concerns in one POM is not a
> good idea. I would go so far as to call it an anti-pattern. A very common
> one, unfortunately.
>
> First, you get a cycle per module. Cycles are never a good thing, though
> sometimes they are unavoidable. Maven seems to be fine with this particular
> type of cycle but you still get strange behaviour on occasion. A build may
> break (especially when starting with an empty
> repository) with a strange error message but a second attempt may succeed.
> That's also (probably) why it is usually not recognised as a problem. If
> the second build succeeds you tend to shrug your shoulders and move on.
>
> Let's say you have an enormous Java file of 10,000 lines of code. I don't
> think anyone would consider that good design. Similarly, if you have a
> single project with some 4,000 Java files. Again, I don't think anyone
> would consider that an example of good design. In both cases, we would
> argue that it needs to be broken up because, clearly, separate/independent
> concerns have been conflated. And it is all just too hard to understand,
> too hard to test, and too hard to maintain.
>
> So why would it be a good idea to put all POM related concerns in one
> place? Especially when it comes to modules, they are *only* relevant at
> compile time. There is absolutely no reason to know about this at any other
> time. In fact, my aggregator POMs have a version "modules"
> (that looks nice in the build output) that never changes and they all set
> <maven.deploy.skip>.
>
> But it goes beyond that. If you have a JAR project and a WAR project then
> it makes sense to have a separate parent-jar-pom and parent-war-pom. The
> parent-jar-pom would only need to know about compiling Java code and
> putting it in a JAR. Very simple. The parent-war-pom, however, would need
> to know about JSP compilation
> (e.g.) and how to run the WAR with Tomcat or Jetty. Perhaps the
> parent-war-pom extends the parent-jar-pom but in any case there is no need
> for this additional complexity to be in the parent-jar-pom.
>
> I think the core difference between these philosophies is choosing between
> "easy" and "simple". It may be easy to put everything in one POM, but it
> will cost you in maintenance effort. It takes more effort and thought to
> simplify things and try and separate independent concerns into separate
> POMs but your maintenance burden will be lighter. Why? Because if you
> change something about the JSP compilation only your WAR projects will be
> affected. Such cause and effect is easy to explain and understand: it's
> simple. :-) Remember, we're not just going to have to explain this to our
> colleagues but also (e.g.) our manager and the change control board.
>
> With a single parent-pom, naturally, you could simply not upgrade your JAR
> project to the latest parent POM (the one with the JSP compilation
> changes) but then you are forcing your maintenance developers to know the
> difference between multiple versions of the parent POM. And this very
> quickly becomes more than 2 and for more than 1 project. This is your
> typical "throw it over the fence" approach. Having been on the other side
> of that fence, I would consider that "not nice".
>
> On 2 December 2016 at 04:02, João Cabrita <[hidden email]>
> wrote:
> > My experience has been that combining parent and aggregator concerns
> > into the root module causes trouble for "aggregator-style" goals like
> > "javadoc-aggregate" that depend on artifacts generated by the submodules.
> >
> > The reason seems to be that, when using such goals, there is a cyclic
> > dependency: the parent/aggregator depends on its submodules for the
> > artifacts and the submodules depend on the parent/aggregator for it's
> > configuration.
> > This leads me to believe that filing this as a bug isn't entirely
> correct.
> >
> > To be more specific, for a module A that is both parent and aggregator
> > of submodules B and C, the build order is A B C.
> > When A is just an aggregator and B, C and P are submodules of A, with
> > P being parent of B and C, the build order is P B C A.
> > Notice that the aggregator has moved from the start of the list
> > (because the children depend on it) to the end (because they no longer
> do).
> >
> > João Cabrita
> >
> > On 1 December 2016 at 04:26, Curtis Rueden <[hidden email]> wrote:
> >
> >> Hi David,
> >>
> >> > The fact is, when I ensured that both the local and intranet repo
> >> > is EMPTY of build artifacts, including the parent pom, the child
> >> > modules fail to build because they can't find the parent pom, which
> >> > just resides in the parent directory of each child module.
> >>
> >> I have never had that problem with multi-module projects that use a
> >> combined parent/aggregator in the top-level directory. This sounds
> >> like a bug to me. Can you please create an SSCCE / MCVE? Then maybe
> >> the community can comment further on what is going wrong for you.
> >>
> >> Regards,
> >> Curtis
> >>
> >>
> >> --
> >> Curtis Rueden
> >> LOCI software architect - http://loci.wisc.edu/software
> >>
> >>
> >> On Wed, Nov 30, 2016 at 7:59 PM, KARR, DAVID <[hidden email]> wrote:
> >>
> >> > > -----Original Message-----
> >> > > From: Dan Tran [mailto:[hidden email]]
> >> > > Sent: Wednesday, November 30, 2016 5:10 PM
> >> > > To: Maven Users List <[hidden email]>
> >> > > Subject: Re: Need to fully understand bad implications of
> >> > > combined aggregator and parent pom
> >> > >
> >> > > Correct we dont ever enter relativePath. The implicit one should
> >> > > work and should never see warning that a module can't find its
> >> > > parent
> >> >
> >> > Uh, whatever.  You're clearly disagreeing with me, so saying "correct"
> >> > just confuses things.
> >> >
> >> > The fact is, when I ensured that both the local and intranet repo
> >> > is
> >> EMPTY
> >> > of build artifacts, including the parent pom, the child modules
> >> > fail to build because they can't find the parent pom, which just
> >> > resides in the parent directory of each child module.
> >> >
> >> > I never tried adding a "<relativePath>..</relativePath> to all of
> >> > the parent pom references, but I was able to get it to work by
> >> > splitting out the parent pom responsibilities into a separate child
> >> > module pom, and having all the references specify the relative path
> to that.
> >> >
> >> > > On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID <[hidden email]>
> wrote:
> >> > >
> >> > > > > -----Original Message-----
> >> > > > > From: Dan Tran [mailto:[hidden email]]
> >> > > > > Sent: Wednesday, November 30, 2016 3:17 PM
> >> > > > > To: Maven Users List <[hidden email]>
> >> > > > > Subject: Re: Need to fully understand bad implications of
> >> > > > > combined aggregator and parent pom
> >> > > > >
> >> > > > > I concur with Ben,  aggregator module is banned at my work.
> >> > > > > Top level parent hosts all modules
> >> > > >
> >> > > > So does this mean that you utilize "relativePath" in the child
> >> > > > module's parent definitions?  Otherwise, the child modules are
> >> > > > being built before the POM for the top-level POM is installed
> >> > > > (which
> >> happens
> >> > > > at the end of the build).
> >> > > >
> >> > > > > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <[hidden email]>
> >> wrote:
> >> > > > >
> >> > > > > > > -----Original Message-----
> >> > > > > > > From: Stephen Connolly
> >> > > > > > > [mailto:[hidden email]
> >> ]
> >> > > > > > > Sent: Wednesday, November 30, 2016 1:01 PM
> >> > > > > > > To: Maven Users List <[hidden email]>
> >> > > > > > > Subject: Re: Need to fully understand bad implications of
> >> > > > > > > combined aggregator and parent pom
> >> > > > > > >
> >> > > > > > > You do have relativePath set correctly for the separate
> >> > > > > > > parent from aggregator?
> >> > > > > >
> >> > > > > > Not sure whether you're addressing Benson or me, but
> >> > > > > > setting relativePath is definitely a requirement, and I
> >> > > > > > think the error message you get is pretty clear when you
> >> > > > > > don’t have it, so I imagine
> >> > > > > that's not Benson's issue.
> >> > > > > >
> >> > > > > > In my case, I did some cut/pasting and some global replaces
> >> > > > > > to separate the POM into parent and aggregator, and now my
> >> > > > > > build works from the top with empty repositories.
> >> > > > > >
> >> > > > > > I don't use the site plugin.
> >> > > > > >
> >> > > > > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
> >> > > > > > > <[hidden email]>
> >> > > > > > > wrote:
> >> > > > > > >
> >> > > > > > > > My experience is precisely the opposite of yours. The
> >> > > > > > > > most common practice is for the parent to be the
> >> > > > > > > > aggregator; it's hard to get the site plugin, for
> >> > > > > > > > example, to work right with your preferred structure
> where they are different.
> >> > > > > > > >
> >> > > > > > > > I have built many projects with the the one-parent
> >> > > > > > > > structure, and they typically have interdependencies
> >> > > > > > > > between the
> >> modules,
> >> > > > > > > > and they work fine.  Can you boil this down to a
> >> > > > > > > > failing case on github? Can you share some poms?
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID
> >> > > > > > > > <[hidden email]
> >> >
> >> > > > > wrote:
> >> > > > > > > > > A while ago, I started working on an existing project
> >> > > > > > > > > with many
> >> > > > > > > > developers.  The codebase has a large multi-project
> >> > > > > > > > Maven
> >> > > build.
> >> > > > > > > > The top directory is both an "aggregator" and "parent"
> >> > > > > > > > POM,
> >> as
> >> > > > > > > > it has a
> >> > > > > > > "modules"
> >> > > > > > > > list, and all of the child modules have it as their
> >> > > > > > > > parent POM, for dependencies and plugins.
> >> > > > > > > > >
> >> > > > > > > > > I've always believed this is a defective
> >> > > > > > > > > architecture.  I believe that
> >> > > > > > > > the top-level directory should have an "aggregator" POM
> >> > > > > > > > that just lists the modules to build, and a
> >> > > > > > > > subdirectory of the top-level directory should have a
> >> > > > > > > > project that just defines the parent POM, which defines
> >> > > > > > > > dependencies and plugins for
> >> > > subprojects to use.
> >> > > > > > > > >
> >> > > > > > > > > Although I feel this is a "cleaner" architecture,
> >> > > > > > > > > I've
> >> never
> >> > > > > > > > > been able
> >> > > > > > > > to cite specific problems with the other approach,
> >> > > > > > > > besides
> >> the
> >> > > > > > > > fact that module changes and dependency/plugin changes
> >> > > > > > > > go in the same file, which is still a "cleanliness"
> argument.
> >> > > > > > > > >
> >> > > > > > > > > Today I think I saw a real reason why the present
> >> > > > > > > > > architecture is a
> >> > > > > > > > problem, but I need to be certain the problem I'm
> >> > > > > > > > seeing is caused by this, and that the better
> >> > > > > > > > architecture fixes this problem, and whether there is a
> >> > > > > > > > simple workaround in the
> >> > > meantime.
> >> > > > > > > > >
> >> > > > > > > > > I've been modifying the build to use a completely new
> >> > > > > > > > > intranet maven
> >> > > > > > > > repo and completely different groupids for the build
> >> > > artifacts.
> >> > > > > > > > >
> >> > > > > > > > > I saw errors like this (with elisions):
> >> > > > > > > > > ----------------------- [INFO] Reactor Summary:
> >> > > > > > > > > [INFO]
> >> > > > > > > > > [INFO] big-parent ..............................
> >> ...........
> >> > > > > > > > > FAILURE [
> >> > > > > > > > 5.230 s]
> >> > > > > > > > > [INFO] some-other-module.............
> >> ......................
> >> > > > > > > > > SKIPPED [INFO]
> >> > > > > > > > > another-module......................................
> >> SKIPPED
> >> > > > > > > > > [INFO]
> >> > > > > > > > > ..............................
> >> .......................SKIPPED
> >> > > > > > > > > [INFO]
> >> > > > > > > > -------------------------------------------------------
> >> > > > > > > > -----
> >> --
> >> > > > > > > > ----
> >> > > > > > > > ----
> >> > > > > > > > --
> >> > > > > > > > > [INFO] BUILD FAILURE
> >> > > > > > > > > [INFO]
> >> > > > > > > > -------------------------------------------------------
> >> > > > > > > > -----
> >> --
> >> > > > > > > > ----
> >> > > > > > > > ----
> >> > > > > > > > --
> >> > > > > > > > > [INFO] Total time: 8.063 s [INFO] Finished at:
> >> > > > > > > > > 2016-11-29T16:23:36-08:00 [INFO] Final
> >> > > > > Memory:
> >> > > > > > > > > 41M/1093M [INFO]
> >> > > > > > > > -------------------------------------------------------
> >> > > > > > > > -----
> >> --
> >> > > > > > > > ----
> >> > > > > > > > ----
> >> > > > > > > > --
> >> > > > > > > > > [ERROR] Failed to execute goal on project
> >> some-other-module:
> >> > > > > > > > > Could not
> >> > > > > > > > resolve dependencies for project
> >> > > > > > > > com.mycomp.detsusl:some-other-
> module:bundle:2.0.0-SNAPSHOT:
> >> > > > > > > > Could not find artifact
> >> > > > > > > > com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
> >> > > > > > > > mycomp-public-group (
> >> > > > > > > > http://mavencentral.it.mycomp.com:8084/nexus/content/
> >> repositor
> >> > > > > > > > ies/
> >> > > > > > > > myco
> >> > > > > > > > mp-public-group/)
> >> > > > > > > > -> [Help 1]
> >> > > > > > > > > [ERROR]
> >> > > > > > > > > ---------------
> >> > > > > > > > >
> >> > > > > > > > > The "big-parent" module is the top-level directory
> >> > > > > > > > > that is both the
> >> > > > > > > > aggregator and parent pom.
> >> > > > > > > > >
> >> > > > > > > > > Conceptually, I think this is happening because Maven
> >> > > > > > > > > is trying to
> >> > > > > > > > evaluate dependencies before those dependencies are built.
> >> > > > > > > > Again, I think the "separated" architecture will
> >> > > > > > > > resolve
> >> this,
> >> > > > > > > > but before I implement that, I need to understand
> >> > > > > > > > exactly
> >> what
> >> > > > > > > > is going on
> >> > > > > here.
> >> > > > > > > > >
> >> > > > > > > > > In my local workspace, I got around this by simply
> >> > > > > > > > > "cd"ing to the
> >> > > > > > > > "another-module" directory and doing a "mvn install",
> >> > > > > > > > then "cd"ing to "some-other-module", doing the same,
> >> > > > > > > > and then
> >> doing
> >> > > > > > > > the same again at the top level. The reality was
> >> > > > > > > > messier than this, because I had quite a few modules
> >> > > > > > > > that I had to build
> >> > > manually this way.
> >> > > > > > > > >
> >> > > > > > > > > Assuming I'm right that separating the "parent"
> >> > > > > > > > > function from the
> >> > > > > > > > "aggregator" function would resolve this, can someone
> >> > > > > > > > explain exactly what is happening here, how my assumed
> >> > > > > > > > solution would resolve this, and whether there's a
> >> > > > > > > > cleaner temporary workaround besides "cd"ing into each
> >> > > > > > > > directory to do a
> >> > > separate install?
> >> > > > > > > > >
> >> > > > > > > > > ------------------------------
> >> ------------------------------
> >> > > > > > > > > ----
> >> > > > > > > > > ----
> >> > > > > > > > > - To unsubscribe, e-mail: users-unsubscribe@maven.
> >> apache.org
> >> > > > > > > > > For additional commands, e-mail:
> >> [hidden email]
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > > > -------------------------------------------------------
> >> > > > > > > > -----
> >> --
> >> > > > > > > > ----
> >> > > > > > > > --- To unsubscribe, e-mail: users-unsubscribe@maven.
> >> apache.org
> >> > > > > > > > For additional commands, e-mail:
> >> > > > > > > > [hidden email]
> >> > > > > > > >
> >> > > > > > > > --
> >> > > > > > > Sent from my phone
> >> > > > > >
> >> > > >
> >> > > > ------------------------------------------------------------
> >> ---------
> >> > > > To unsubscribe, e-mail: [hidden email]
> >> > > > For additional commands, e-mail: [hidden email]
> >> > > >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: Need to fully understand bad implications of combined aggregator and parent pom

dkarr
Why would there be plugin duplications?  Are you thinking there would
be plugin definitions in the aggregator pom?  The point of the
aggregator pom is that it defines the GAV of the artifact and has the
modules list and NOTHING else.

On Mon, Dec 5, 2016 at 11:27 AM, Mirko Friedenhagen
<[hidden email]> wrote:

> Hello,
>
> I use the combined aggregator/parent pom as well. While multiple poms may
> be cleaner because of separation of concerns, you might easily end in
> duplications for e.g. plugin definitions, which is a shame as well.
>
> Regards
> Mirko
> --
> Sent from my mobile
>
> Am 05.12.2016 10:56 schrieb "Sander Verhagen" <[hidden email]>:
>
>> Simple and easy may be in the eye of the beholder. I get a lot of your
>> points (except for the cycles breaking your build, I'm not recognizing
>> that), but my environment is just dramatically different, and the things
>> that you are describing as necessary for your environment, would be
>> unneeded complexity for mine. We have a lot more entirely separate
>> projects, each of which with their own (smaller) constellation (ancestry)
>> of Maven projects. There's a company POM. Each project has a parent POM,
>> that inherits the company POM, and yes, it's an aggregator too. That's
>> never a problem, because the child projects are all unique and different,
>> and aside from a few shared plugin configurations, that we are perfectly
>> happy to have in the company POM, and a few enforcer rules that we are
>> happy to share across the entire project, all the real meat is in the leaf
>> node POM files. I don’t know what JSP compilation you speak of, nor do we
>> have any significant WAR configuration to be shared across modules. I
>> currently have 716 POM files checked out locally (just a quick "find"),
>> just to give you some feeling that my application of Maven isn't just
>> trivial. But it is DIFFERENT than yours. And I like my shared
>> aggregator/parent POMs. Maybe if it hadn't been designed like this, by
>> Maven, for many years now as it is, whatever the world would look like
>> would've been fine too, but now I'm fond of this approach, to be honest :)
>>
>> One more note, I have learned to be sparse on what to put into the
>> inheritance hierarchy (composition over inheritance, that good stuff), so
>> our parent POMs are also a lot leaner than what I've seen (myself and
>> others do) in the past. Something like this may play into your observations
>> also.
>>
>> Thanks for everyone's perspective on this, it's interesting!
>>
>>
>> Sander Verhagen
>> [  [hidden email]  ]
>>
>> NOTICE: my e-mail address has changed. Please remove [hidden email]
>> now and start using [hidden email] from now on. Please update
>> your address book. Thank you!
>>
>> -----Original Message-----
>> From: Hilco Wijbenga [mailto:[hidden email]]
>> Sent: Sunday, December 4, 2016 17:16
>> To: Maven Users List <[hidden email]>
>> Subject: Re: Need to fully understand bad implications of combined
>> aggregator and parent pom
>>
>> Indeed, combining the parent and aggregator concerns in one POM is not a
>> good idea. I would go so far as to call it an anti-pattern. A very common
>> one, unfortunately.
>>
>> First, you get a cycle per module. Cycles are never a good thing, though
>> sometimes they are unavoidable. Maven seems to be fine with this particular
>> type of cycle but you still get strange behaviour on occasion. A build may
>> break (especially when starting with an empty
>> repository) with a strange error message but a second attempt may succeed.
>> That's also (probably) why it is usually not recognised as a problem. If
>> the second build succeeds you tend to shrug your shoulders and move on.
>>
>> Let's say you have an enormous Java file of 10,000 lines of code. I don't
>> think anyone would consider that good design. Similarly, if you have a
>> single project with some 4,000 Java files. Again, I don't think anyone
>> would consider that an example of good design. In both cases, we would
>> argue that it needs to be broken up because, clearly, separate/independent
>> concerns have been conflated. And it is all just too hard to understand,
>> too hard to test, and too hard to maintain.
>>
>> So why would it be a good idea to put all POM related concerns in one
>> place? Especially when it comes to modules, they are *only* relevant at
>> compile time. There is absolutely no reason to know about this at any other
>> time. In fact, my aggregator POMs have a version "modules"
>> (that looks nice in the build output) that never changes and they all set
>> <maven.deploy.skip>.
>>
>> But it goes beyond that. If you have a JAR project and a WAR project then
>> it makes sense to have a separate parent-jar-pom and parent-war-pom. The
>> parent-jar-pom would only need to know about compiling Java code and
>> putting it in a JAR. Very simple. The parent-war-pom, however, would need
>> to know about JSP compilation
>> (e.g.) and how to run the WAR with Tomcat or Jetty. Perhaps the
>> parent-war-pom extends the parent-jar-pom but in any case there is no need
>> for this additional complexity to be in the parent-jar-pom.
>>
>> I think the core difference between these philosophies is choosing between
>> "easy" and "simple". It may be easy to put everything in one POM, but it
>> will cost you in maintenance effort. It takes more effort and thought to
>> simplify things and try and separate independent concerns into separate
>> POMs but your maintenance burden will be lighter. Why? Because if you
>> change something about the JSP compilation only your WAR projects will be
>> affected. Such cause and effect is easy to explain and understand: it's
>> simple. :-) Remember, we're not just going to have to explain this to our
>> colleagues but also (e.g.) our manager and the change control board.
>>
>> With a single parent-pom, naturally, you could simply not upgrade your JAR
>> project to the latest parent POM (the one with the JSP compilation
>> changes) but then you are forcing your maintenance developers to know the
>> difference between multiple versions of the parent POM. And this very
>> quickly becomes more than 2 and for more than 1 project. This is your
>> typical "throw it over the fence" approach. Having been on the other side
>> of that fence, I would consider that "not nice".
>>
>> On 2 December 2016 at 04:02, João Cabrita <[hidden email]>
>> wrote:
>> > My experience has been that combining parent and aggregator concerns
>> > into the root module causes trouble for "aggregator-style" goals like
>> > "javadoc-aggregate" that depend on artifacts generated by the submodules.
>> >
>> > The reason seems to be that, when using such goals, there is a cyclic
>> > dependency: the parent/aggregator depends on its submodules for the
>> > artifacts and the submodules depend on the parent/aggregator for it's
>> > configuration.
>> > This leads me to believe that filing this as a bug isn't entirely
>> correct.
>> >
>> > To be more specific, for a module A that is both parent and aggregator
>> > of submodules B and C, the build order is A B C.
>> > When A is just an aggregator and B, C and P are submodules of A, with
>> > P being parent of B and C, the build order is P B C A.
>> > Notice that the aggregator has moved from the start of the list
>> > (because the children depend on it) to the end (because they no longer
>> do).
>> >
>> > João Cabrita
>> >
>> > On 1 December 2016 at 04:26, Curtis Rueden <[hidden email]> wrote:
>> >
>> >> Hi David,
>> >>
>> >> > The fact is, when I ensured that both the local and intranet repo
>> >> > is EMPTY of build artifacts, including the parent pom, the child
>> >> > modules fail to build because they can't find the parent pom, which
>> >> > just resides in the parent directory of each child module.
>> >>
>> >> I have never had that problem with multi-module projects that use a
>> >> combined parent/aggregator in the top-level directory. This sounds
>> >> like a bug to me. Can you please create an SSCCE / MCVE? Then maybe
>> >> the community can comment further on what is going wrong for you.
>> >>
>> >> Regards,
>> >> Curtis
>> >>
>> >>
>> >> --
>> >> Curtis Rueden
>> >> LOCI software architect - http://loci.wisc.edu/software
>> >>
>> >>
>> >> On Wed, Nov 30, 2016 at 7:59 PM, KARR, DAVID <[hidden email]> wrote:
>> >>
>> >> > > -----Original Message-----
>> >> > > From: Dan Tran [mailto:[hidden email]]
>> >> > > Sent: Wednesday, November 30, 2016 5:10 PM
>> >> > > To: Maven Users List <[hidden email]>
>> >> > > Subject: Re: Need to fully understand bad implications of
>> >> > > combined aggregator and parent pom
>> >> > >
>> >> > > Correct we dont ever enter relativePath. The implicit one should
>> >> > > work and should never see warning that a module can't find its
>> >> > > parent
>> >> >
>> >> > Uh, whatever.  You're clearly disagreeing with me, so saying "correct"
>> >> > just confuses things.
>> >> >
>> >> > The fact is, when I ensured that both the local and intranet repo
>> >> > is
>> >> EMPTY
>> >> > of build artifacts, including the parent pom, the child modules
>> >> > fail to build because they can't find the parent pom, which just
>> >> > resides in the parent directory of each child module.
>> >> >
>> >> > I never tried adding a "<relativePath>..</relativePath> to all of
>> >> > the parent pom references, but I was able to get it to work by
>> >> > splitting out the parent pom responsibilities into a separate child
>> >> > module pom, and having all the references specify the relative path
>> to that.
>> >> >
>> >> > > On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID <[hidden email]>
>> wrote:
>> >> > >
>> >> > > > > -----Original Message-----
>> >> > > > > From: Dan Tran [mailto:[hidden email]]
>> >> > > > > Sent: Wednesday, November 30, 2016 3:17 PM
>> >> > > > > To: Maven Users List <[hidden email]>
>> >> > > > > Subject: Re: Need to fully understand bad implications of
>> >> > > > > combined aggregator and parent pom
>> >> > > > >
>> >> > > > > I concur with Ben,  aggregator module is banned at my work.
>> >> > > > > Top level parent hosts all modules
>> >> > > >
>> >> > > > So does this mean that you utilize "relativePath" in the child
>> >> > > > module's parent definitions?  Otherwise, the child modules are
>> >> > > > being built before the POM for the top-level POM is installed
>> >> > > > (which
>> >> happens
>> >> > > > at the end of the build).
>> >> > > >
>> >> > > > > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <[hidden email]>
>> >> wrote:
>> >> > > > >
>> >> > > > > > > -----Original Message-----
>> >> > > > > > > From: Stephen Connolly
>> >> > > > > > > [mailto:[hidden email]
>> >> ]
>> >> > > > > > > Sent: Wednesday, November 30, 2016 1:01 PM
>> >> > > > > > > To: Maven Users List <[hidden email]>
>> >> > > > > > > Subject: Re: Need to fully understand bad implications of
>> >> > > > > > > combined aggregator and parent pom
>> >> > > > > > >
>> >> > > > > > > You do have relativePath set correctly for the separate
>> >> > > > > > > parent from aggregator?
>> >> > > > > >
>> >> > > > > > Not sure whether you're addressing Benson or me, but
>> >> > > > > > setting relativePath is definitely a requirement, and I
>> >> > > > > > think the error message you get is pretty clear when you
>> >> > > > > > don’t have it, so I imagine
>> >> > > > > that's not Benson's issue.
>> >> > > > > >
>> >> > > > > > In my case, I did some cut/pasting and some global replaces
>> >> > > > > > to separate the POM into parent and aggregator, and now my
>> >> > > > > > build works from the top with empty repositories.
>> >> > > > > >
>> >> > > > > > I don't use the site plugin.
>> >> > > > > >
>> >> > > > > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
>> >> > > > > > > <[hidden email]>
>> >> > > > > > > wrote:
>> >> > > > > > >
>> >> > > > > > > > My experience is precisely the opposite of yours. The
>> >> > > > > > > > most common practice is for the parent to be the
>> >> > > > > > > > aggregator; it's hard to get the site plugin, for
>> >> > > > > > > > example, to work right with your preferred structure
>> where they are different.
>> >> > > > > > > >
>> >> > > > > > > > I have built many projects with the the one-parent
>> >> > > > > > > > structure, and they typically have interdependencies
>> >> > > > > > > > between the
>> >> modules,
>> >> > > > > > > > and they work fine.  Can you boil this down to a
>> >> > > > > > > > failing case on github? Can you share some poms?
>> >> > > > > > > >
>> >> > > > > > > >
>> >> > > > > > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID
>> >> > > > > > > > <[hidden email]
>> >> >
>> >> > > > > wrote:
>> >> > > > > > > > > A while ago, I started working on an existing project
>> >> > > > > > > > > with many
>> >> > > > > > > > developers.  The codebase has a large multi-project
>> >> > > > > > > > Maven
>> >> > > build.
>> >> > > > > > > > The top directory is both an "aggregator" and "parent"
>> >> > > > > > > > POM,
>> >> as
>> >> > > > > > > > it has a
>> >> > > > > > > "modules"
>> >> > > > > > > > list, and all of the child modules have it as their
>> >> > > > > > > > parent POM, for dependencies and plugins.
>> >> > > > > > > > >
>> >> > > > > > > > > I've always believed this is a defective
>> >> > > > > > > > > architecture.  I believe that
>> >> > > > > > > > the top-level directory should have an "aggregator" POM
>> >> > > > > > > > that just lists the modules to build, and a
>> >> > > > > > > > subdirectory of the top-level directory should have a
>> >> > > > > > > > project that just defines the parent POM, which defines
>> >> > > > > > > > dependencies and plugins for
>> >> > > subprojects to use.
>> >> > > > > > > > >
>> >> > > > > > > > > Although I feel this is a "cleaner" architecture,
>> >> > > > > > > > > I've
>> >> never
>> >> > > > > > > > > been able
>> >> > > > > > > > to cite specific problems with the other approach,
>> >> > > > > > > > besides
>> >> the
>> >> > > > > > > > fact that module changes and dependency/plugin changes
>> >> > > > > > > > go in the same file, which is still a "cleanliness"
>> argument.
>> >> > > > > > > > >
>> >> > > > > > > > > Today I think I saw a real reason why the present
>> >> > > > > > > > > architecture is a
>> >> > > > > > > > problem, but I need to be certain the problem I'm
>> >> > > > > > > > seeing is caused by this, and that the better
>> >> > > > > > > > architecture fixes this problem, and whether there is a
>> >> > > > > > > > simple workaround in the
>> >> > > meantime.
>> >> > > > > > > > >
>> >> > > > > > > > > I've been modifying the build to use a completely new
>> >> > > > > > > > > intranet maven
>> >> > > > > > > > repo and completely different groupids for the build
>> >> > > artifacts.
>> >> > > > > > > > >
>> >> > > > > > > > > I saw errors like this (with elisions):
>> >> > > > > > > > > ----------------------- [INFO] Reactor Summary:
>> >> > > > > > > > > [INFO]
>> >> > > > > > > > > [INFO] big-parent ..............................
>> >> ...........
>> >> > > > > > > > > FAILURE [
>> >> > > > > > > > 5.230 s]
>> >> > > > > > > > > [INFO] some-other-module.............
>> >> ......................
>> >> > > > > > > > > SKIPPED [INFO]
>> >> > > > > > > > > another-module......................................
>> >> SKIPPED
>> >> > > > > > > > > [INFO]
>> >> > > > > > > > > ..............................
>> >> .......................SKIPPED
>> >> > > > > > > > > [INFO]
>> >> > > > > > > > -------------------------------------------------------
>> >> > > > > > > > -----
>> >> --
>> >> > > > > > > > ----
>> >> > > > > > > > ----
>> >> > > > > > > > --
>> >> > > > > > > > > [INFO] BUILD FAILURE
>> >> > > > > > > > > [INFO]
>> >> > > > > > > > -------------------------------------------------------
>> >> > > > > > > > -----
>> >> --
>> >> > > > > > > > ----
>> >> > > > > > > > ----
>> >> > > > > > > > --
>> >> > > > > > > > > [INFO] Total time: 8.063 s [INFO] Finished at:
>> >> > > > > > > > > 2016-11-29T16:23:36-08:00 [INFO] Final
>> >> > > > > Memory:
>> >> > > > > > > > > 41M/1093M [INFO]
>> >> > > > > > > > -------------------------------------------------------
>> >> > > > > > > > -----
>> >> --
>> >> > > > > > > > ----
>> >> > > > > > > > ----
>> >> > > > > > > > --
>> >> > > > > > > > > [ERROR] Failed to execute goal on project
>> >> some-other-module:
>> >> > > > > > > > > Could not
>> >> > > > > > > > resolve dependencies for project
>> >> > > > > > > > com.mycomp.detsusl:some-other-
>> module:bundle:2.0.0-SNAPSHOT:
>> >> > > > > > > > Could not find artifact
>> >> > > > > > > > com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
>> >> > > > > > > > mycomp-public-group (
>> >> > > > > > > > http://mavencentral.it.mycomp.com:8084/nexus/content/
>> >> repositor
>> >> > > > > > > > ies/
>> >> > > > > > > > myco
>> >> > > > > > > > mp-public-group/)
>> >> > > > > > > > -> [Help 1]
>> >> > > > > > > > > [ERROR]
>> >> > > > > > > > > ---------------
>> >> > > > > > > > >
>> >> > > > > > > > > The "big-parent" module is the top-level directory
>> >> > > > > > > > > that is both the
>> >> > > > > > > > aggregator and parent pom.
>> >> > > > > > > > >
>> >> > > > > > > > > Conceptually, I think this is happening because Maven
>> >> > > > > > > > > is trying to
>> >> > > > > > > > evaluate dependencies before those dependencies are built.
>> >> > > > > > > > Again, I think the "separated" architecture will
>> >> > > > > > > > resolve
>> >> this,
>> >> > > > > > > > but before I implement that, I need to understand
>> >> > > > > > > > exactly
>> >> what
>> >> > > > > > > > is going on
>> >> > > > > here.
>> >> > > > > > > > >
>> >> > > > > > > > > In my local workspace, I got around this by simply
>> >> > > > > > > > > "cd"ing to the
>> >> > > > > > > > "another-module" directory and doing a "mvn install",
>> >> > > > > > > > then "cd"ing to "some-other-module", doing the same,
>> >> > > > > > > > and then
>> >> doing
>> >> > > > > > > > the same again at the top level. The reality was
>> >> > > > > > > > messier than this, because I had quite a few modules
>> >> > > > > > > > that I had to build
>> >> > > manually this way.
>> >> > > > > > > > >
>> >> > > > > > > > > Assuming I'm right that separating the "parent"
>> >> > > > > > > > > function from the
>> >> > > > > > > > "aggregator" function would resolve this, can someone
>> >> > > > > > > > explain exactly what is happening here, how my assumed
>> >> > > > > > > > solution would resolve this, and whether there's a
>> >> > > > > > > > cleaner temporary workaround besides "cd"ing into each
>> >> > > > > > > > directory to do a
>> >> > > separate install?
>> >> > > > > > > > >
>> >> > > > > > > > > ------------------------------
>> >> ------------------------------
>> >> > > > > > > > > ----
>> >> > > > > > > > > ----
>> >> > > > > > > > > - To unsubscribe, e-mail: users-unsubscribe@maven.
>> >> apache.org
>> >> > > > > > > > > For additional commands, e-mail:
>> >> [hidden email]
>> >> > > > > > > > >
>> >> > > > > > > >
>> >> > > > > > > > -------------------------------------------------------
>> >> > > > > > > > -----
>> >> --
>> >> > > > > > > > ----
>> >> > > > > > > > --- To unsubscribe, e-mail: users-unsubscribe@maven.
>> >> apache.org
>> >> > > > > > > > For additional commands, e-mail:
>> >> > > > > > > > [hidden email]
>> >> > > > > > > >
>> >> > > > > > > > --
>> >> > > > > > > Sent from my phone
>> >> > > > > >
>> >> > > >
>> >> > > > ------------------------------------------------------------
>> >> ---------
>> >> > > > To unsubscribe, e-mail: [hidden email]
>> >> > > > For additional commands, e-mail: [hidden email]
>> >> > > >
>> >> >
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]