2011/12/20 sebb <seb...@gmail.com>:
> On 19 December 2011 23:15, Olivier Lamy <ol...@apache.org> wrote:
>> 2011/12/19 sebb <seb...@gmail.com>:
>>> On 19 December 2011 22:47, Olivier Lamy <ol...@apache.org> wrote:
>>>> 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 ?
>>>>
>>>
>>> Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100
>>> Java version: 1.6.0_29
>>>
>>> But I get the same issue with 3.0.3:
>>>
>>> Apache Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+0000)
>>> Maven home: C:\apache-maven-3.0.3
>>> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
>>>
>>> The only difference is that the build does not fail, I just get a warning
>>>
>>> [WARNING]
>>> [WARNING] Some problems were encountered while building the effective
>>> settings
>>> [WARNING] Unrecognised tag: 'build' (position: START_TAG seen
>>> ...</activation>\r\n <build>... @184:13)
>>
>> did you try exactly the sample I sended ?
>>
>> try with this patch :
>> http://people.apache.org/~olamy/commons/patch-cp-23-SNAPSHOT.diff
>
> That just converts my property override into a profile override; in
> both cases, the maven command-line needs to be changed.
> It also changes the default to not use svnjava, which will help if
> most developers have SVN cli installed (which is why the thread was
> started)
>
> There are two issues here:
> 1) ensuring that CP works for most people without further
> configuration; that is the point of choosing the correct default
> provider.
>
> 2) providing a way to choose the correct svn provider automatically
> for the people who can't use the default svn provider
>
> It would be even better if the svn provider could somehow be
> overridden in settings.xml, because there would then be no immediate
> nee to fix CP.
IMHO keep classic implementation (tru cli by default as with release
plugin as the release plugin is not configured to use svnjava
provider), I cannot imagine people here not having svn in their path !
At least as long as svnkit support 17 WC.
in your settings
<settings>
...
<activeProfiles>
<activeProfile>svnjava</activeProfile>
</activeProfiles>
....
</settings>
tested locally with 2.2.1 and the patch I provided to you and it works
(but maybe the famous OMMIW :-) )
>
>>>
>>>
>>>>>
>>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
