2011/12/20 sebb <seb...@gmail.com>: > 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?
AFAIK, there is no activation mechanism based on executable available in the path (maybe could be a nice addition). > >> 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 > -- 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
