Personally, I was going to suggest going the other direction and completely get rid of the "parent" pom and move everything into the top level pom. We already have a non-standard maven layout due to the parent pom which can be confusing for people (and tools). I'd much rather try and find a way to go back to a more standard layout than introduce yet another layer in there to make it even more non-standard.
That's my opinion. Dan On Aug 18, 2013, at 8:35 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > Yeah Babak's idea sounds good. Having that 2-level of parents. > > On Sun, Aug 18, 2013 at 1:55 PM, Babak Vahdat > <babak.vah...@swissonline.ch> wrote: >> I just tried out a different approach which: >> >> - doesn't require any Maven plugin usage. >> - doesn't require to convert the Maven properties from the XML format to the >> Java properties file format etc. >> - is really simple. >> >> So the idea is to simply bump one more level of parent-child dependency into >> our POM hierarchy (org.apache.camel:camel-dependencies:2.12-SNAPSHOT) which >> contains all the Maven properties of our 3rd party dependencies. And this is >> the diff for it dependencies.diff >> <http://camel.465427.n5.nabble.com/file/n5737472/dependencies.diff> . >> >> Then for the release notes of the upcomming 2.12.0 release we could just add >> the following link about our 3rd party dependencies, of course right now >> this resource doesn't exist on the central repo :-) >> http://search.maven.org/remotecontent?filepath=org/apache/camel/camel-dependencies/2.12.0/camel-dependencies-2.12.0.pom >> >> >> For example in case of our Camel Parent POM of the 2.11.1 release the link >> is: >> http://search.maven.org/remotecontent?filepath=org/apache/camel/camel-parent/2.11.1/camel-parent-2.11.1.pom >> >> Babak >> >> >> R. Sirchia wrote >>> Hi, >>> >>> Why don't you do it the other way around? >>> >>> I understand from Claus that his desire is not so much to manage the >>> dependencies and their versions in a different file, but just to provide a >>> file where the version properties can be easily read from and diffed >>> between releases. >>> >>> In that case, you could simply leave everything as it is and use the >>> properties maven plugin to write the existing properties to a properties >>> file: >>> http://mojo.codehaus.org/properties-maven-plugin/write-project-properties-mojo.html >>> >>> Optionally, the end result can be filtered using for example a >>> maven-antrun-plugin goal to leave out any non-version properties, which >>> should be easy as the version definitions (can easilly be made to) follow >>> a >>> certain naming convention. >>> >>> The end result (a clean *.properties file) can then be attached using the >>> build-helper plugin. It is then available in Maven Central to be >>> referenced >>> from the release notes, diffed or imported by any user, etc. >>> >>> Riccardo >>> >>> >>> >>> On Sat, Aug 17, 2013 at 10:23 PM, Jan Matèrne (jhm) < >> >>> apache@ >> >>> >wrote: >>> >>>> I just played with that maven plugin. >>>> The problem is that it loads the properties after the validation phase. >>>> >>>> That wont work: >>>> >>>> >> >>>> >>> <project> >>>> >>> <modelVersion> >>> 4.0.0 >>> </modelVersion> >>>> >>>> >>> <groupId> >>> just-test >>> </groupId> >>>> >>> <artifactId> >>> version-test >>> </artifactId> >>>> >>> <version> >>> 1.0 >>> </version> >>>> >>>> >>> <build> >>>> >>> <plugins> >>>> >>> <plugin> >>>> >>> <groupId> >>> org.codehaus.mojo >>> </groupId> >>>> >>> <artifactId> >>> properties-maven-plugin >>> </artifactId> >>>> >>> <version> >>> 1.0-alpha-2 >>> </version> >>>> >>> <executions> >>>> >>> <execution> >>>> >>> <phase> >>> initialize >>> </phase> >>>> >>> <goals> >>>> >>> <goal> >>> read-project-properties >>> </goal> >>>> >>> </goals> >>>> >>> <configuration> >>>> >>> <files> >>>> >>> <file> >>> versions.properties >>> </file> >>>> >>> </files> >>>> >>> </configuration> >>>> >>> </execution> >>>> >>> </executions> >>>> >>> </plugin> >>>> >>> </plugins> >>>> >>> </build> >>>> >>>> >>> <dependencies> >>>> >>> <dependency> >>>> >>> <groupId> >>> junit >>> </groupId> >>>> >>> <artifactId> >>> junit >>> </artifactId> >>>> >>> <version> >>> ${junit} >>> </version> >>>> >>> </dependency> >>>> >>> </dependencies> >>>> >>> </project> >>>> >>>> >>>> I also tried putting a >>>> >>> <properties> >>>> >>> <junit> >>> 1 >>> </junit> >>>> >>> </properties> >>>> as placeholder for the validation doesnt work. >>>> The property is not changed to the stored junit=4.9 in my file. >>>> >>>> >>>> Current ideas: >>>> - building our own mvn plugin (enhancing that plugin) for loading the >>>> props >>>> and overwrite existing properties >>>> - generate a valid pom from the version-list >>>> >>>> >>>> Jan >>>> >>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: Babak Vahdat [mailto: >> >>> babak.vahdat@ >> >>> ] >>>>> Gesendet: Samstag, 17. August 2013 21:48 >>>>> An: >> >>> dev@.apache >> >>>>> Betreff: Re: [IDEA] - Having a parent maven pom.xml for only the >>>>> dependency versions >>>>> >>>>> Hi >>>>> >>>>> what I'm aware of for this purpose is the following plugin: >>>>> >>>>> http://mojo.codehaus.org/properties-maven-plugin/usage.html >>>>> >>>>> However it's not maintained anymore since 2009! >>>>> >>>>> The other option would be to use the Kuali's plugin but I'm not sure >>>>> about it's licence (it's already available in central repo): >>>>> >>>>> http://site.kuali.org/maven/plugins/properties-maven-plugin/1.1.9/read- >>>>> project-properties-mojo.html >>>>> >>>>> No matter which one we would want to make use of, the tough part of >>>>> this would be to convert the lines like: >>>>> >>>>> >>> <ahc-version> >>> 1.7.19 >>> </ahc-version> >>>>> >>>>> into: >>>>> >>>>> ahc-version=1.7.19 >>>>> >>>>> But it should be possible to automate this conversion with couple of >>>>> lines of code, or maybe even a new Camel date format for this purpose >>>>> :-) >>>>> >>>>> Babak >>>>> >>>>> >>>>> Claus Ibsen-2 wrote >>>>>> Hi >>>>>> >>>>>> Today we have the parent/pom.xml file which has both all the versions >>>>>> of the 3rd party JARs we have as dependencies. And also a list of all >>>>>> the camel components and some other stuff. >>>>>> >>>>>> I wonder if we could have all the dependency versions in a single >>>>>> file, without all the other stuff. >>>>>> >>>>>> This would make it easier for ppl to see what are the version changes >>>>>> between any two Camel versions, but just diff the 2 files? >>>>>> >>>>>> And also we could just have such a link in the release notes so we >>>>>> dont have to manually keep all the versions upgrades in the release >>>>>> notes up to date as well. >>>>>> >>>>>> -- >>>>>> Claus Ibsen >>>>>> ----------------- >>>>>> Red Hat, Inc. >>>>>> Email: >>>>> >>>>>> cibsen@ >>>>> >>>>>> Twitter: davsclaus >>>>>> Blog: http://davsclaus.com >>>>>> Author of Camel in Action: http://www.manning.com/ibsen >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: http://camel.465427.n5.nabble.com/IDEA- >>>>> Having-a-parent-maven-pom-xml-for-only-the-dependency-versions- >>>>> tp5737322p5737460.html >>>>> Sent from the Camel Development mailing list archive at Nabble.com. >>>> >>>> >> >> >> >> >> >> -- >> View this message in context: >> http://camel.465427.n5.nabble.com/IDEA-Having-a-parent-maven-pom-xml-for-only-the-dependency-versions-tp5737322p5737472.html >> Sent from the Camel Development mailing list archive at Nabble.com. > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > Email: cib...@redhat.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
