On 20 December 2011 00:05, Olivier Lamy <ol...@apache.org> wrote: > 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 !
Well, that's basically the question I originally asked in this thread. The reason I chose svnjava was that at the time it worked for everyone, not just those with svn in the path. So dropping svnjava as the default may cause problems for some. Is there a way to fix CP so that it auto-detects whether svn is on the 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 :-) ) I expect that to work. However, it does still require: - a new release of CP - some users to update settings.xml >> >>>> >>>> >>>>>> >>>>>> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
