cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Maven poms structure
Date Mon, 27 Aug 2012 13:59:03 GMT

On Aug 26, 2012, at 9:46 PM, Darren Shepherd <darren@godaddy.com> wrote:

> I don't think there was any intention of releasing things individually. 
> If you want to get rid of parent/pom.xml (and move all the contents to
> /pom.xml) I think that would make sense.  Honestly, the only reason the
> structure is how it is is because I copied the exact structure of Apache
> CXF.

LOL…  wow.  I did not expect that….

As the the primary author of the CXF structure, I can give you a little history on why this
was done, just for educational reasons.   

CXF has been using Maven 2.x for a very very long time.   It was one of the first projects
to move to Maven 2 (before CXF even came to the ASF).  We're talking very very early Maven
2.0.x versions.   As early adopters, we hit many many bugs in Maven and the various plugins.
  I earned my commit privileges on Maven due to fixing issues.

Originally, we had a completely self contained build with our "buildtools" module as part
of the main build.   The buildtools has things like checkstyle configs, PMD configs, shade
plugin configs, etc….   Since CXF runs Checkstyle and PMD as part of the "normal" build
we could not use a normal setup like:

root
   /buildtools
   /sub1
   /sub2

as we could not define the checkstyle plugin in the root pom as you end up with a circular
issue where the root pom needs buildtools, but buildtools' parent is the root.   We just couldn't
get it working at the time.   Thus, we split things with the root pom really being just "project
level" settings and the parent subdir is the real parent for all the "jar" related things.

There was also an issue with Maven 2.0.x (maybe 2.2.x as well, I know 3.0.x is OK) where in
a multi-module build, the first time a plugin is encountered is the only time the plugin dependencies
are examined.  We had problems with plugins defined in buildtools that we needed to redo in
the other submodules.   Don't really remember all the details.  Had a couple other modules
that required very different configs as well were we just set the parent to the "root" pom
and not the parent/pom.xml  so we didn't pick up the "common" stuff.   Really don't remember
why though and those issues have long since been removed.


That said, things have changed in the last 7 years.    For one, we moved the buildtools stuff
into it's own subproject with it's own release schedule, etc…  Thus, the structure isn't
needed anymore.    For the latest CXF projects (Fediz and DOSGi), I explicitly made sure they
DIDN'T duplicate that structure.   We likely could merge everything in parent/pom.xml into
the root pom.   Would just take some effort.  Big issue would be porting fixes back to the
fixes branches unless we did the same change on all the branches.  

Anyway, I certainly wouldn't duplicate that setup anymore.    :-)

Dan





> 
> Darren
> 
> 
> 
> 
>> -------- Original Message --------
>> Subject: Maven poms structure
>> From: Olivier Lamy <olamy@apache.org>
>> Date: Sun, August 26, 2012 12:28 am
>> To: cloudstack-dev@incubator.apache.org
>> 
>> 
>> Hi,
>> The current structure is:
>> 
>> pom.xml (org.apache.cloudstack:cloudstack [1])
>> /parent/pom.xml (org.apache.cloudstack:cloud-parent [2])
>> 
>> The [2] has [1] as parent. I don't really understand the need of this [2].
>> If the goal was to have a flat structure, pom [1] must be only a
>> aggregator pom and all informations must in pom [2] which must be the
>> real parent.
>> I propose to :
>> * remove /parent/pom.xml
>> or
>> * /parent/pom.xml must be a real parent. (For reference see how we on
>> maven side for such structure:
>> http://svn.apache.org/repos/asf/maven/plugins/trunk/).
>> Is the goal to be able to release stuff independently or everything is
>> release every time (in this second case having a flat structure is not
>> needed IMHO)
>> 
>> Thanks,
>> -- 
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message