commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [ALL] CP22 buildNumber plugin - svnjava does not work with SVN 1.6 WC format currently
Date Mon, 19 Dec 2011 23:45:43 GMT
On 19 December 2011 23:15, Olivier Lamy <olamy@apache.org> wrote:
> 2011/12/19 sebb <sebbaz@gmail.com>:
>> On 19 December 2011 22:47, Olivier Lamy <olamy@apache.org> wrote:
>>> 2011/12/19 sebb <sebbaz@gmail.com>:
>>>> On 19 December 2011 20:55, Olivier Lamy <olamy@apache.org> wrote:
>>>>> 2011/12/19 sebb <sebbaz@gmail.com>:
>>>>>> On 19 December 2011 15:43, Olivier Lamy <olamy@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 <sebbaz@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.

>>
>>
>>>>
>>>> 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-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Olivier Lamy
>>>>>>> Talend: http://coders.talend.com
>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Olivier Lamy
>>>>> Talend: http://coders.talend.com
>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message