+1
I will have a look at it and go ahead with the proposed changes (as I also
think this is Maven best practice).
Best,
Christian
On Fri, Sep 7, 2012 at 10:31 PM, Babak Vahdat
<babak.vah...@swissonline.ch>wrote:
>
> There's another weird thing by some Camel Maven modules as well, currently
> we've got 134-1 Camel POM modules:
>
> ~/dev/workspace/camel/components>find . -name pom.xml | wc
> 134 134 3086
>
> 114 of them claim to have org.apache.camel:camel-parent:2.11-SNAPSHOT as
> the parent which is a "Maven Parent POM":
>
> ~/dev/workspace/camel/components>find . -name pom.xml -exec grep -l
> "<artifactId>camel-parent</artifactId>" {} \; | wc
> 115 115 2612
>
>
> And the rest (19 in count) have org.apache.camel:components:2.11-SNAPSHOT
> as the parent which is a "Maven Aggregator POM" *and* owns the parent POM
> itself as it's own parent:
>
> ~/dev/workspace/camel/components>find . -name pom.xml -exec grep -l
> "<artifactId>components</artifactId>" {} \; | wc
> 20 20 484
>
>
> I would say better change the 114 POMs to be like the other 14, as in
> Camel we've got a hybrid "Aggregator and Parent POM" usage where the
> Aggregator POM itself has the Parent POM *as it's own parent* (so that it
> already inherits everything from the Parent POM: <dependencyManagement> as
> well as <pluginManagement> configs). So the hierarchy should be better:
>
> Parent POM (org.apache.camel:camel-parent:2.11-SNAPSHOT)
> Aggregator POM (org.apache.camel:components:2.11-SNAPSHOT)
> Module camel-xyz (org.apache.camel:camel-xyz:2.11-SNAPSHOT)
>
> Then we could also get rid of the explicit <relativePath> elements by
> those 114 modules as well:
>
> <relativePath>../../parent</relativePath>
>
> As per default the value of it would be the Aggregator's POM itself
> residing at the default path which is "../pom.xml":
>
> The same applies for other Camel POM hierarchies as well (thinking of
> examples, tests, tooling etc.) however I didn't check them.
>
> Babak
>
> Am 07.09.12 18:05 schrieb "Christian Müller" unter
> <christian.muel...@gmail.com>:
>
> >I polished/cleaned the maven-surefire-plugin definitions. At the moment, I
> >run a full test to check whether I do not break anything. Will commit the
> >change after the test was running successful.
> >Afterwards I will have a look at all the other duplicated plugin
> >definitions, version definitions, ...
> >
> >Best,
> >Christian
> >
> >On Fri, Sep 7, 2012 at 2:29 PM, Babak Vahdat
> ><babak.vah...@swissonline.ch>wrote:
> >
> >> This is for sure a step in the right direction, as IMHO the Camel's
> >>maven
> >> setup needs pretty a lot of face-lifting (parts of them already being
> >> mentioned by you). Some other points comming into my mind are:
> >>
> >> - There are places where we repeat ourselves again and again, for
> >>example
> >> because of derby.log while running unit-test:
> >>
> >> <systemProperties>
> >> <property>
> >> <name>derby.stream.error.file</name>
> >> <value>target/derby.log</value>
> >> </property>
> >> </systemProperties>
> >>
> >> Which we could better say just ONCE inside parent POM using inheritance
> >>of
> >> pluginManagement.
> >>
> >> - Get rid of all those hard-coded version values being used in
> >>components
> >> and better extract them all up to the parent pom so that upgrading to
> >>the
> >> latest & greatest third-party can go smoother, as not too many people
> >>would
> >> go into components/came-xyz/pom.xml to check if there's any dependency
> >>we
> >> could / should upgrade.
> >>
> >> - If possible, it would be great to leverage a set of checkstyle rules
> >>for
> >> the POMs themselves (maybe there're already some ASL software out there
> >>for
> >> these kinds of stuff) as we do already today for the Java source (the
> >> "sourcecheck" profile), then we could keep on a unique formatting of the
> >> POMs such as:
> >>
> >> - No tab inside POM
> >> - Max line length of XXX chars
> >> - Indention using X spaces
> >> - etc.
> >>
> >> - Also IMHO we should better get rid of ALL those
> >> <exclude>**/XXXTest.*</exclude>:
> >>
> >> <artifactId>maven-surefire-plugin</artifactId>
> >> <configuration>
> >> <forkMode>pertest</forkMode>
> >>
> >> <forkedProcessTimeoutInSeconds>300</forkedProcessTimeoutInSeconds>
> >> <excludes>
> >>
> >> <exclude>**/XXXTest.*</exclude>
> >> </excludes>
> >> </configuration>
> >>
> >> as sticking to @Ignore Annotation (JUnit) or @Test(enabled=false)
> >>(TestNG)
> >> is much more conventional. And frankly we would then spot the tests
> >>being
> >> skipped much easier.
> >>
> >> Last but not least many thanks for looking into this :-)
> >>
> >> Babak
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> >>
> http://camel.465427.n5.nabble.com/HEADS-UP-Bigger-changes-in-parent-pom-x
> >>ml-tp5718769p5718776.html
> >> Sent from the Camel Development mailing list archive at Nabble.com.
> >>
> >
> >
> >
> >--
>
>
>
--
