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.
>>
>
>
>
>--
