Thank you for your responses :-).
There are two ideas here:
1) have the configuration pick the right version, using
${project.parent.version}
2) refactor the parent into two parts, to avoid duplication.
1) is like the previous suggestion, but gets around the issue of having children
at different version levels. But 1) requires that you do 2), so that when you
build new sub-parent containing the reference to the build-resources-bundle, it
has now a parent at the proper version level to make that reference work.
This feels to me to be very clever, but perhaps "brittle" with respect to future
maintenance... but that could be fixed with some careful comments, I suppose.
1) also requires that all build parent-poms be at the same level, which I think
is fine, but is, again, somewhat "brittle" in the sense above.
I guess this brittleness can be avoided by not doing the 1) part, and instead,
"hard-coding" the version (maybe in just one place, using a <property>) in the
parent-pom with the configuration(s) referring to it.
-Marshall
On 10/28/2010 2:29 AM, Vincent Latombe wrote:
> I thought of that as well, but if it is a parent pom, children will most
> likely redefine ${project.version} to have their own.
>
> Marshall, I think you can refine your scenario by doing the following :
> - remove the configuration part from your parent pom
> - release it together with your build-resources-bundle project
> - create a new artifact that declares as parent your parent pom, and add the
> configuration for build-resources-bundle (you can even use
> ${project.parent.version} to reference it)
> - make your project artifacts inherit from this new pom.
>
> This way, you avoid duplication of configuration.
>
> 2010/10/28 Anders Hammar <and...@hammar.net>
>
>> I think by using ${project.version}.
>>
>> /Anders
>>
>> On Wed, Oct 27, 2010 at 20:57, Marshall Schor <m...@schor.com> wrote:
>>
>>> We have a common project parent-pom, and a build-resources-bundle project
>>> containing various "build" resources, bundled into a Jar artifact. One
>> of
>>> these
>>> resources is used in configuring the maven remote-resources-plugin, for
>>> instance.
>>>
>>> We start with the configuration where both the parent-pom and
>>> build-resources-bundle are at version 1-SNAPSHOT.
>>>
>>> The parent-pom is set up as an aggregator pom, with one child: the
>>> build-resources-bundle project.
>>>
>>> Executing mvn release:prepare on the parent-pom causes the prepare phase
>> to
>>> go
>>> and update the versions of these from 1-SNAPSHOT to "1" for the "tag".
>>> However,
>>> this process does not notice that the remote-resource-plugin's
>>> configuration in
>>> the parent-pom is specifying the build-resources-bundle at version
>>> 1-SNAPSHOT -
>>> so that version is *not* updated.
>>>
>>> If a release:perform were to be done, it would build from the tag
>> checkout,
>>> and
>>> configure the remote-resources-plugin to use the 1-SNAPSHOT version of
>> the
>>> build-resources-bundle; I want it to be using the "1" version of the
>>> bundle.
>>>
>>> To work around this, I could run the release:prepare, and then update
>>> manually,
>>> the tag, to update the reference from 1-SNAPSHOT to 1.
>>>
>>> The other thing I could imagine doing is uncoupling these two artifacts,
>>> and
>>> releasing the build-resources-bundle separately. This would require that
>> I
>>> duplicate a bunch of things from the common project parent-pom, into the
>>> build-resources-bundle, and do a separate release cycle, just for it, and
>>> then
>>> have the parent-pom depend on the released version.
>>>
>>> What is the "maven way" for doing this kind of thing?
>>>
>>> -Marshall Schor
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
