2011/12/19 sebb <seb...@gmail.com>: > On 19 December 2011 20:55, Olivier Lamy <ol...@apache.org> wrote: >> 2011/12/19 sebb <seb...@gmail.com>: >>> On 19 December 2011 15:43, Olivier Lamy <ol...@apache.org> wrote: >>>> Hello, >>>> You mean 1.6 or 1.7 WC ? >>> >>> 1.7 WC is different, and not currently supported by SVNkit. >> I know but the mail subject says " buildNumber plugin - svnjava does >> not work with SVN 1.6 WC format currently". > > Sorry, the subject line is wrong. > >> So that was my question as I'm pretty sure svnjava works with svn 1.6 >> WC as I use it daily > > Yes, 1.6 is fine. > >>> >>>> 2011/12/19 sebb <seb...@gmail.com>: >>>>> When I added the buildNumber plugin to CP22, it seemed that it would >>>>> be best to use the "svnjava" provider, as that works even if the user >>>>> does not have a command-line svn client installed. >>>>> >>>>> However, since then, the SVN working copy format has changed, and the >>>>> svnjava provider relies on SVNkit which does not yet support the new >>>>> WC format. >>>>> >>>>> Unfortunately, the buildnumber plugin does not support overriding the >>>>> provider via a property >>>> >>>> you can probably use a profile for that. >>> >>> Not that I know of. >> >> Sample to cleanup (and move some part in pluginManagement) : >> >> <profile> >> <id>svn-buildnumber</id> >> <activation> >> <file> >> <exists>.svn</exists> >> </file> >> </activation> >> <build> >> <plugins> >> <plugin> >> <groupId>org.codehaus.mojo</groupId> >> <artifactId>buildnumber-maven-plugin</artifactId> >> <executions> >> <execution> >> <phase>generate-resources</phase> >> <goals> >> <goal>create</goal> >> </goals> >> </execution> >> </executions> >> <configuration> >> <doCheck>false</doCheck> >> <doUpdate>false</doUpdate> >> </configuration> >> </plugin> >> </plugins> >> </build> >> </profile> >> <profile> >> <id>javasvn</id> >> <build> >> <plugins> >> <plugin> >> <groupId>org.codehaus.mojo</groupId> >> <artifactId>buildnumber-maven-plugin</artifactId> >> <executions> >> <execution> >> <phase>generate-resources</phase> >> <goals> >> <goal>create</goal> >> </goals> >> </execution> >> </executions> >> <configuration> >> <doCheck>false</doCheck> >> <doUpdate>false</doUpdate> >> <providerImplementations> >> <svn>javasvn</svn> >> </providerImplementations> >> </configuration> >> </plugin> >> </plugins> >> </build> >> </profile> > > As already stated, that does not work in settings.xml, and is > unnecessary in pom.xml, because one can just use a property instead. > >> >>> >>> One can use a profile in a pom to override configs, but there's no >>> need as one can use properties instead (which is what I've added to CP >>> trunk). >>> >>> Since the availability of the SVN client - and the format of SVN WCs - >>> is host-dependent, the setting ought to be settable via settings.xml, >>> but AFAICT it's not possible. >> >> with previous sample, if you want to use javasvn profile in your >> settings add or use -Pjavasvn : >> <activeProfiles> >> <activeProfile>javasvn</activeProfile> >> </activeProfiles> > > Try it in your settings.xml. > > It does not work when I try it.
which mvn version are you using ? > > The whole point is to be able to override the config from settings.xml. > >>> >>> I've raised a JIRA for this: MBUILDNUM-80 >>> >>>>>, only via POM configuration. I've updated CP >>>>> in SVN to allow the provider to be overridden on the command-line. >>>>> >>>>> The question is: what should the default setting be? >>>>> >>>>> Is it safe to assume that most Commons Developers (particularly RMs) >>>>> have an SVN command-line client installed? >>>>> >>>>> If so, then perhaps a better default would be to use that, but still >>>>> allow override via a property. >>>>> >>>>> Or maybe a Maven guru can describe how to detect if the svn >>>>> command-line client is present (this must be reliable, and work across >>>>> all OSes). >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> >>>> >>>> -- >>>> Olivier Lamy >>>> Talend: http://coders.talend.com >>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
