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-xml-tp5718769p5718776.html > Sent from the Camel Development mailing list archive at Nabble.com. > --
