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

Reply via email to