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) >> >> 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