You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Müller <ch...@gmail.com> on 2012/09/07 13:35:09 UTC
[HEADS UP] Bigger changes in parent/pom.xml
I did bigger changes in parent/pom.xml regarding to [1]. At present, I'm
running a full build on my machine to check I didn't something really bad.
If it's successful, I will commit it in some minutes and will have an eye
on the CI server. The changes in general are:
- moving plugin management definitions from pom.xml into parent/pom.xml
- use parent/pom.xml as parent in the buildingtools mudule
- upgrade to org.apache/apache/11/pom.xml
- ordered the plugin management section in parent/pom.xml alphabetical
- fixed the indention of the xml files (using two spaces)
Afterwards I will work on the following things:
- check for duplicated plugin definitions
- move the dependency versions from platforms/karaf/features/pom.xml into
parent/pom.xml to make it easier to check we are using the same version
numbers for our jar files and osgi bundles
[1] https://issues.apache.org/jira/browse/CAMEL-4643
--
Re: [HEADS UP] Bigger changes in parent/pom.xml
Posted by Christian Müller <ch...@gmail.com>.
+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
<ba...@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
> <ch...@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
> ><ba...@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.
> >>
> >
> >
> >
> >--
>
>
>
--
Re: [HEADS UP] Bigger changes in parent/pom.xml
Posted by Babak Vahdat <ba...@swissonline.ch>.
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
<ch...@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
><ba...@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.
>>
>
>
>
>--
Re: [HEADS UP] Bigger changes in parent/pom.xml
Posted by Babak Vahdat <ba...@swissonline.ch>.
That sounds just great :-)
Babak
Am 07.09.12 18:05 schrieb "Christian Müller" unter
<ch...@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
><ba...@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.
>>
>
>
>
>--
Re: [HEADS UP] Bigger changes in parent/pom.xml
Posted by Christian Müller <ch...@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 <ba...@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-xml-tp5718769p5718776.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
--
Re: [HEADS UP] Bigger changes in parent/pom.xml
Posted by Babak Vahdat <ba...@swissonline.ch>.
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-xml-tp5718769p5718776.html
Sent from the Camel Development mailing list archive at Nabble.com.