Am 19.08.13 20:01 schrieb "Daniel Kulp" unter <dk...@apache.org>:
>
>On Aug 19, 2013, at 1:25 PM, Babak Vahdat <babak.vah...@swissonline.ch>
>wrote:
>
>> Hi Dan,
>>
>> how exactly does your proposal look like? If I'm getting you right you
>> suggest to push all these properties up into the top most level POM we
>>have,
>> that is org.apache.camel:camel:2.12-SNAPSHOT right? But then again
>>we've got
>> the same problem as already today because these Maven properties would
>>be
>> mixed up with a lot of other stuff. And the intention here in this
>>thread is
>> the other way around, that's extract them out!
>
>I just don't see any value in pulling them out. It doesn't solve any
>problem that isn't "trivial", but then creates an even greater confusion
>by having a more complicated and more non-standard build system.
Yeah indeed everybody is free to have his own opinion, especially when it
comes to the open source community :)
Babak
>
>Seriously, if you do:
>
>git diff a1acd3454e91e7388f4165715b823fa4749502ea parent/pom.xml
>
>(which is the diff between master and 2.11.0)
>
>There is very little that would not be part of the "diff" that would be
>provided from your proposal, but there is additional information in there
>that is important that your proposal would miss. (like the dropping of
>the spring3 profile and the changing of the groupId/artifactId on the
>ehcache things, different Saxon artifact ID)
>
>I would suggest just removing all the camel components from the
>parent/pom.xml and adding <version>${project.version}</version> in the
>places that actually depend on them. Defining dependencies on stuff you
>are building like this in the parent depmngt section is again one of
>those 'kind of non-standard' type things. Most of the components are
>only imported into the assembly and the tests so it's not a "huge" deal.
>
>
>
>
>Dan
>
>
>
>
>>
>> Babak
>>
>>
>> dk...@apache.org wrote
>>> 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.ibsen@
>>
>>> > 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.vahdat@
>>
>>> > 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&;
>>>>>gt;
>>>>> .
>>>>>
>>>>> 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-proper
>>>>>>ties-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/r
>>>>>>>>ead-
>>>>>>>> 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-f
>>>>>or-only-the-dependency-versions-tp5737322p5737472.html
>>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> Red Hat, Inc.
>>>> Email:
>>
>>> cibsen@
>>
>>>> Twitter: davsclaus
>>>> Blog: http://davsclaus.com
>>>> Author of Camel in Action: http://www.manning.com/ibsen
>>>
>>> --
>>> Daniel Kulp
>>
>>> dkulp@
>>
>>> - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>>http://camel.465427.n5.nabble.com/IDEA-Having-a-parent-maven-pom-xml-for-
>>only-the-dependency-versions-tp5737322p5737525.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>
>--
>Daniel Kulp
>dk...@apache.org - http://dankulp.com/blog
>Talend Community Coder - http://coders.talend.com
>
