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