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