sebb wrote: > On 7 January 2012 18:34, Jörg Schaible <joerg.schai...@gmx.de> wrote: >> Jörg Schaible wrote: >> >>> sebb wrote: >>> >>>> On 7 January 2012 13:19, Jörg Schaible <joerg.schai...@gmx.de> 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.
The main point for the profile was to suppress the failures of the buildnumber plugin automatically when building from the source tarball. Actually the usage of the plugin means, that the release is not really repeatable (missing entries in the manifest) unless checked out directly from the tag ... :-/ Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
