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. 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
