commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [ALL] Commons Parent pom - any more changes needed?
Date Sun, 08 Jan 2012 01:03:51 GMT
On 7 January 2012 18:34, Jörg Schaible <> wrote:
> Jörg Schaible wrote:
>> sebb wrote:
>>> On 7 January 2012 13:19, Jörg Schaible <> wrote:
>>>> sebb wrote:
>>>>> I'd like to release the next version of CP, i.e. 23.
>>>>> Changes since 22 are:
>>>>> ====
>>>>> New features:
>>>>> o           added java-1.7 profile
>>>>> o           added ssh/scp support to maven-site-plugin in Maven3
>>>>> Changes:
>>>>> o           moved buildNumber plugin to profile activated by presence
>>>>> of .svn directory
>>>> You realize that for submodules this will only work with M3, profile
>>>> activation fails for M2?
>>> No, I did not (this was not contributed by me).
> Might have been me.
>>> Is there a fix for M2?
>> No. The reactor works simply differently. The basedir in M3's reactor mode
>> is always the current project root, while in M2 it was always the
>> directory where the reactor had been started. Therefore the profile is
>> activated in M3, but not in M2 for submodules.
>> However, in this special case it is not really relevant. The profile
>> simply suppresses those unfriendly warnings starting the build from a
>> source package - M2 users will simply have to endure them for submodules
>> as it would be for all users without the profile.
> After thinking about this, we should probably remove the profile, because
> with Subversion 1.7.x clients the profile may no longer be activated
> although the current Maven project root is part of a Subversion working area
> (note, only the root of a working area has a .svn directory starting with
> Subversion 1.7).

Good point.

One could perhaps also check for ../.svn (etc.), but that quickly
becomes rather unwieldy.

Maybe a solution would be to use a profile that is active by default
and can be suppressed on demand.

The plugin is only needed (in Commons at least) to provide input for
creating a manifest.
Is it possible to detect when that is needed?
Another possibility would be to suppress the plugin if the user
provides the SCM details as properties on the command-line (as may be
necessary in some cases).
Ideally combine the two, so the plugin only runs if its output is
needed and has not already been provided.

I'll cancel the CP vote while this is resolved.

> When I proposed the profile I did neither knew about the M2 problem nor
> about this behavior of svn 1.7.x. Actually I will have to drop it in our
> office also ...
> - Jörg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message