On Aug 26, 2012, at 9:46 PM, Darren Shepherd <dar...@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 <ol...@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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
