maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "KARR, DAVID" <dk0...@att.com>
Subject RE: Need to fully understand bad implications of combined aggregator and parent pom
Date Thu, 01 Dec 2016 00:54:25 GMT
> -----Original Message-----
> From: Dan Tran [mailto:dantran@gmail.com]
> Sent: Wednesday, November 30, 2016 3:17 PM
> To: Maven Users List <users@maven.apache.org>
> 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 <dk068x@att.com> wrote:
> 
> > > -----Original Message-----
> > > From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> > > Sent: Wednesday, November 30, 2016 1:01 PM
> > > To: Maven Users List <users@maven.apache.org>
> > > 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
> > > <bimargulies@gmail.com>
> > > 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 <dk068x@att.com>
> 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: users-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: users-help@maven.apache.org
> > > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > --- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > > --
> > > Sent from my phone
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Mime
View raw message