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 Mon, 09 Jan 2012 02:34:32 GMT
On 8 January 2012 16:43, Jörg Schaible <> wrote:
> sebb wrote:
>> 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 <>
>>>>>> 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
>>>>>>> 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.
> The main point for the profile was to suppress the failures of the
> buildnumber plugin automatically when building from the source tarball.

With RC4, that can be achieved by defining buildNumber.skip=true.

> Actually the usage of the plugin means, that the release is not really
> repeatable (missing entries in the manifest)

If you follow that logic to its conclusion, the buildNumber plugin is
effectively unusable.

> unless checked out directly from the tag ... :-/

Which is what should *always* be done.
Releases should always be built from a clean checkout.
If not, they are not guaranteed repeatable, regardless of the use of
the buildNumber plugin.
There has recently been at least one Commons RC which was not built
from a clean checkout, and that caused the tag to differ from the

The point of the manifest entry is to show what tag and revision was
used to build the release.
If the information happens to be missing, we are no worse off than
before, but if it is present, it can be potentially useful.

The information can also be supplied via property definitions if required.

> Cheers,
> Jörg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message