Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 319EF78F7 for ; Tue, 20 Dec 2011 00:23:51 +0000 (UTC) Received: (qmail 2615 invoked by uid 500); 20 Dec 2011 00:23:50 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 2541 invoked by uid 500); 20 Dec 2011 00:23:50 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 2533 invoked by uid 99); 20 Dec 2011 00:23:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Dec 2011 00:23:50 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates 209.85.212.43 as permitted sender) Received: from [209.85.212.43] (HELO mail-vw0-f43.google.com) (209.85.212.43) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Dec 2011 00:23:46 +0000 Received: by vbbfq11 with SMTP id fq11so22958880vbb.30 for ; Mon, 19 Dec 2011 16:23:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=dzvrdnWtyOIA5+35DKYlYCQdCjpp0WAgoetWcFwkb20=; b=wZ3e67zS2+BRchRvEoOmhlmG4+w5RyrVEUAPc03KIUB/MAPHyxkWw4dApWW3nDySFA aepuXGYgvaoyz2w/hmtLGaszKJnDj3aQDv5F7wdScC9blAMrRqyE/DjTvEEzjVml3/tA 1FV+qJxW4DIJEbQQdbGlEVGiBvrKhcbbFdzwY= MIME-Version: 1.0 Received: by 10.52.35.134 with SMTP id h6mr3090733vdj.30.1324340605265; Mon, 19 Dec 2011 16:23:25 -0800 (PST) Received: by 10.220.0.129 with HTTP; Mon, 19 Dec 2011 16:23:25 -0800 (PST) In-Reply-To: References: Date: Tue, 20 Dec 2011 00:23:25 +0000 Message-ID: Subject: Re: [ALL] CP22 buildNumber plugin - svnjava does not work with SVN 1.6 WC format currently From: sebb To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20 December 2011 00:05, Olivier Lamy wrote: > 2011/12/20 sebb : >> On 19 December 2011 23:15, Olivier Lamy wrote: >>> 2011/12/19 sebb : >>>> On 19 December 2011 22:47, Olivier Lamy wrote: >>>>> 2011/12/19 sebb : >>>>>> On 19 December 2011 20:55, Olivier Lamy wrote: >>>>>>> 2011/12/19 sebb : >>>>>>>> On 19 December 2011 15:43, Olivier Lamy 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 doe= s >>>>>>> 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 : >>>>>>>>>> When I added the buildNumber plugin to CP22, it seemed that it w= ould >>>>>>>>>> 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, an= d the >>>>>>>>>> svnjava provider relies on SVNkit which does not yet support the= new >>>>>>>>>> WC format. >>>>>>>>>> >>>>>>>>>> Unfortunately, the buildnumber plugin does not support overridin= g 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) : >>>>>>> >>>>>>> >>>>>>> =A0 =A0 =A0svn-buildnumber >>>>>>> =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0.svn >>>>>>> =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0org.codehaus.mojo >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0buildnumber-maven-plugin >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0generate-resources >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0create >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0false >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0false >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 >>>>>>> =A0 =A0 >>>>>>> =A0 =A0 >>>>>>> =A0 =A0 =A0javasvn >>>>>>> =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0org.codehaus.mojo >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0buildnumber-maven-plugin >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0generate-resources >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0create >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0false >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0false >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0javasvn >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 =A0 >>>>>>> =A0 =A0 =A0 >>>>>>> =A0 =A0 >>>>>> >>>>>> 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 t= o CP >>>>>>>> trunk). >>>>>>>> >>>>>>>> Since the availability of the SVN client - and the format of SVN W= Cs - >>>>>>>> is host-dependent, the setting ought to be settable via settings.x= ml, >>>>>>>> but AFAICT it's not possible. >>>>>>> >>>>>>> with previous sample, if you want to use javasvn profile in your >>>>>>> settings add or use -Pjavasvn : >>>>>>> =A0 >>>>>>> =A0 =A0javasvn >>>>>>> =A0 >>>>>> >>>>>> 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 warn= ing >>>> >>>> [WARNING] >>>> [WARNING] Some problems were encountered while building the effective = settings >>>> [WARNING] Unrecognised tag: 'build' (position: START_TAG seen >>>> ...\r\n =A0 =A0 ... @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 > > ... > =A0 > =A0 =A0svnjava > =A0 > .... > > > 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.x= ml. >>>>>> >>>>>>>> >>>>>>>> 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-lin= e. >>>>>>>>>> >>>>>>>>>> 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 s= till >>>>>>>>>> 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 >> > > > > -- > 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