From dev-return-4787-archive-asf-public=cust-asf.ponee.io@groovy.apache.org Fri May 18 15:15:21 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id C6B1D180648 for ; Fri, 18 May 2018 15:15:19 +0200 (CEST) Received: (qmail 28231 invoked by uid 500); 18 May 2018 13:15:18 -0000 Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@groovy.apache.org Delivered-To: mailing list dev@groovy.apache.org Received: (qmail 28217 invoked by uid 99); 18 May 2018 13:15:18 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 May 2018 13:15:18 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id AC2C81A1841 for ; Fri, 18 May 2018 13:15:17 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 7M0C0Y7n1MqS for ; Fri, 18 May 2018 13:15:13 +0000 (UTC) Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 326BF5F41B for ; Fri, 18 May 2018 13:15:13 +0000 (UTC) Received: by mail-vk0-f45.google.com with SMTP id i190-v6so4769657vkd.13 for ; Fri, 18 May 2018 06:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=++vak7VA9llMGek3plE4SlzcugahYQPDF0QWPNLsMy0=; b=hyJ56XfqOXwiSJjbqiszqdYTgTkyU7+O05ur/BYPCSXdygnTRsFKTmcPV9/S/rCxsP L+mmK99SNRo+LGRf4JmUuaKnJvpnRXV1kguM+s+Z0a+U2VaOHLVAFKaQEFe1OF9ss5W8 DEvvHXHzM49nqyF3eN9VHt9zzgInCUiO6uobQIf5CFl2NDYn/HQtfgu4rftDUsqVPOYx jMzdmHCwPwgJ3w2djtArEPIF2Y+E2BlfpAX+I0dkfpKw2ctbYbmGN1I1VdCwAjPKwWIy 8qaviLyq4b8ak71Lcpj4oxV+PG+Vh0sD3EkjMjbfQ/E2aXZebmsBMOOU1EhO+s9F4fat 01WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=++vak7VA9llMGek3plE4SlzcugahYQPDF0QWPNLsMy0=; b=FxgWmZEPKkvzNnhzKmerKCGd8ZGc3VHk3Nul/enls7hcxTWL/n35KvlB2+Ky34qPsp ogV6Daj7CxsfRGCFpIuk8YWjW/O9qWe6GhDPkgB1ZNSIgPSOpAJJ4o3ctTGLwR+D7hzf mDc8ZeKob6DTSK5tRJoPPzODAYFaOS879SLwuv9tdgHiCS3sVlY82cF9a0mlt1MVDAxi OYxVvWxXTQoTstaJ39E55VpctDMpXVEGB+lYKjToICspAhR3NwpkuCP/Hc3O7bhucRwu S70/Aw/iI8XPIoVG2i1Xusqtp3IxZStgqwhGAwni9TpP1kSDl/G0BDeP+Ixs1X0hX92W X9Dw== X-Gm-Message-State: ALKqPweWPrNzkC7EUkR5T00KyXtIupatr0xChKRAGnukke3a7oBZ5UwT GxVtZYU1LCYlbNG+PVDiyKqgQLbXaTe6uiMdKZc= X-Google-Smtp-Source: AB8JxZpd/bdQKr55Vz2NooUoQLPjGtX9xmQpBpRebqft9mD95YjHA8b4JRqKR73zAUPKUoVUk5BuAazkyhgW2LrPT8Y= X-Received: by 2002:a1f:2cc6:: with SMTP id s189-v6mr6778244vks.106.1526649311858; Fri, 18 May 2018 06:15:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.150 with HTTP; Fri, 18 May 2018 06:14:51 -0700 (PDT) In-Reply-To: References: From: Keegan Witt Date: Fri, 18 May 2018 09:14:51 -0400 Message-ID: Subject: Re: Groovy 2.5.0-rc-2 breaks Gant To: Remko Popma Cc: dev@groovy.apache.org, Paul King , Russel Winder Content-Type: multipart/alternative; boundary="000000000000ee181d056c7abd5c" --000000000000ee181d056c7abd5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So do you want to change this back for RC3? I know it's late to change this, but arguably it was late to change it in RC2 too. -Keegan On Thu, May 10, 2018, 11:08 AM Remko Popma wrote: > I updated the PR to make the signature of `setPosix` accept Boolean > instead of boolean and added tests to ensure that nulls are handled > correctly. Thanks for pointing that out! > > The picocli version of CliBuilder has tests to verify that Java-like > properties such as -Dkey=3Dvalue are processed correctly in the new versi= on > just like in the commons-cli version. (For multiple properties the option > can be specified multiple times: -Da=3Db -Dx=3Dz ) > > I have not created a dummy setter for `setOptions` for the reason you > mentioned: > if users use this to configure the options it is probably better to fail > with a compiler error than silently ignoring such options. > > It's hard to tell how many people would be impacted by this, but if we > want 2.5 to be compatible with 2.4 we cannot make picocli the default in > 2.5. > > > > On Thu, May 10, 2018 at 8:42 AM, Keegan Witt wrote= : > >> Here's all the differences between 2.4 and 2.5 >> >> - setFormatter(org.apache.commons.cli.HelpFormatter) (in the PR) >> - setParser(org.apache.commons.cli.CommandLineParser) (in the PR) >> - setOptions(org.apache.commons.cli.Options) >> - setPosix(java.lang.Boolean) (changed from boolean to Boolean, also >> it's deprecated) >> >> I'd guess setFormatter() wouldn't be a very common thing to do (I think >> it'd only really come up if HelpFormatter were subclassed for some >> reason), so that one's probably not a big risk. But I'm not sure >> setOptions() is safe to dummy up -- folks might be relying on this to >> configure the options to parse. This might be a reason not to default t= o >> picocli yet. What do you think? >> >> I also looked at how current arguments passed on the commandline could >> break with the move, and the only thing I noticed was Commons CLI says i= t >> can do Java-like properties such as -Djava.awt.headless=3Dtrue (although= I >> didn't see how you'd actually configure these options unless you jammed = all >> of them into 1 giant option). >> >> -Keegan >> >> >> On Tue, May 8, 2018 at 1:06 AM, Paul King wrote: >> >>> Short answer is we can have as many RCs as needed to get it right but w= e >>> don't really want to be chopping and changing too much. Big changes are >>> supposed to be settling down by now - fate just brought this change lat= e in >>> the game compared to what we'd like. I'd really like to get +ve feedbac= k >>> from a SNAPSHOT with that change before doing another release including= it. >>> I can merge in a couple of days time after conference commitments. >>> >>> Cheers, Paul. >>> >>> On Tue, May 8, 2018 at 2:27 PM, Remko Popma >>> wrote: >>> >>>> >>>> I realize now that simply removing the `parser` and `formatter` >>>> properties was a mistake. While the picocli version of CliBuilder cann= ot >>>> use commons-cli classes I should have anticipated that some applicatio= ns >>>> are setting these properties. >>>> >>>> I believe that I have a solution that provides a smoother migration >>>> path. PR >>>> https://github.com/apache/groovy/pull/696 adds dummy setters for the >>>> legacy properties. >>>> >>>> This should significantly reduce the disruption for applications like >>>> Gant that depend on the ability to modify these commons-cli properties= in >>>> CliBuilder. >>>> >>>> Would it be possible to have another 2.5-rc release with the above >>>> change and see what the community feedback is before we decide to reve= rt >>>> the CliBuilder delegation to point to the commons-cli implementation? >>>> >>>> Marking the delegation version class as deprecated is probably a good >>>> idea regardless of where it points to. >>>> >>>> Remko >>>> >>>> >>>> On Tue, May 8, 2018 at 3:19 Paul King wrote: >>>> >>>>> >>>>> Both CliBuilder implementations are there via their full package >>>>> names, so encouraging people to use the non-delegated implementation = of >>>>> their choice is a good option. They will need to get used to such cha= nges >>>>> in Groovy 3 anyway. >>>>> >>>>> For Groovy 3, we might have a way for the compiler to translate from >>>>> the existing package names to the new ones brought about by JDK9 modu= les, >>>>> in which case we'd do that for CliBuilder and we'd want to point it t= o the >>>>> picocli package name by then (though if we do the change below we per= haps >>>>> wouldn't include CliBuilder in the translations list). >>>>> >>>>> For 2.5, we don't have the package translation in place and don't >>>>> intend to. Because of that, the point of the delegation version is to= aid >>>>> in migration. >>>>> Maybe it was too big a jump to try to delegate to the Picocli >>>>> delegation in 2.5. If we find too many problems I think I should reve= rt >>>>> that change and delegate to the commons cli implementation instead bu= t mark >>>>> the whole delegation version class as deprecated. >>>>> >>>>> Let me know what people think. >>>>> >>>>> Cheers, Paul. >>>>> >>>>> >>>>> On Mon, May 7, 2018 at 3:45 PM, Keegan Witt >>>>> wrote: >>>>> >>>>>> I'll take a look. I'll also see if there are other places that can >>>>>> break. >>>>>> >>>>>> If there are several ways it can break, then maybe we should not use >>>>>> a delegate to picocli and instead have folks switch the CliBuilder i= nstance >>>>>> they instantiate. >>>>>> >>>>>> -Keegan >>>>>> >>>>>> On Sun, May 6, 2018, 7:56 PM Remko Popma >>>>>> wrote: >>>>>> >>>>>>> I think I found a way to fix this. >>>>>>> See https://github.com/apache/groovy/pull/696 >>>>>>> This PR adds CliBuilder.setParser and CliBuilder.setFormatter >>>>>>> methods that ignore the specified value and print a warning to stde= rr. >>>>>>> >>>>>>> On Sun, May 6, 2018 at 9:14 PM, Remko Popma >>>>>>> wrote: >>>>>>> >>>>>>>> In 2.5.0-rc-2, groovy.util.CliBuilder delegates to >>>>>>>> groovy.cli.picocli.CliBuilder. The error is that the `parser` prop= erty of >>>>>>>> this class is no longer writable. >>>>>>>> >>>>>>>> You can resolve this with 2.5.0-rc-2 by either not setting the >>>>>>>> `parser` property in the CliBuilder constructor or using the >>>>>>>> groovy.cli.commons.CliBuilder instead. >>>>>>>> >>>>>>>> On the Groovy side I=E2=80=99m not sure what the best way is to ma= ke the >>>>>>>> transition easier. The picocli version of CliBuilder can not make= use of >>>>>>>> the Commons-CLI parser class. We could modify CliBuilder to silen= tly >>>>>>>> ignore the specified parser. (We=E2=80=99d have to rename the pic= ocli ParserSpec >>>>>>>> `parser` property in CliBuilder to something else.) >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> >>>>>>>> On Sun, May 6, 2018 at 20:35 Keegan Witt >>>>>>>> wrote: >>>>>>>> >>>>>>>>> FYI 2.5.0-rc-2 breaks Gant. Specifically, it's caused by changin= g >>>>>>>>> groovy.util.CliBuilder to use Picocli >>>>>>>>> >>>>>>>>> java.lang.reflect.InvocationTargetException >>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>>> Method) >>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke( >>>>>>>>> NativeMethodAccessorImpl.java:62) >>>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke( >>>>>>>>> DelegatingMethodAccessorImpl.java:43) >>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>>>>>> at org.codehaus.groovy.tools.GroovyStarter.rootLoader( >>>>>>>>> GroovyStarter.java:114) >>>>>>>>> at org.codehaus.groovy.tools.GroovyStarter.main( >>>>>>>>> GroovyStarter.java:136) >>>>>>>>> Caused by: groovy.lang.ReadOnlyPropertyException: Cannot set >>>>>>>>> readonly property: parser for class: groovy.util.CliBuilder >>>>>>>>> at groovy.lang.MetaClassImpl.setProperty(MetaClassImpl. >>>>>>>>> java:2746) >>>>>>>>> at groovy.lang.MetaClassImpl.setProperty(MetaClassImpl. >>>>>>>>> java:3782) >>>>>>>>> at groovy.lang.MetaClassImpl.setProperties(MetaClassImpl. >>>>>>>>> java:1759) >>>>>>>>> at org.codehaus.groovy.runtime.callsite.ConstructorSite$ >>>>>>>>> NoParamSite.callConstructor(ConstructorSite.java:125) >>>>>>>>> at org.codehaus.groovy.runtime.callsite.CallSiteArray. >>>>>>>>> defaultCallConstructor(CallSiteArray.java:59) >>>>>>>>> at org.codehaus.groovy.runtime.callsite.AbstractCallSite. >>>>>>>>> callConstructor(AbstractCallSite.java:238) >>>>>>>>> at org.codehaus.groovy.runtime.callsite.AbstractCallSite. >>>>>>>>> callConstructor(AbstractCallSite.java:250) >>>>>>>>> at gant.Gant.processArgs(Gant.groovy:463) >>>>>>>>> at gant.Gant$processArgs.call(Unknown Source) >>>>>>>>> at org.codehaus.groovy.runtime.callsite.CallSiteArray. >>>>>>>>> defaultCall(CallSiteArray.java:47) >>>>>>>>> at org.codehaus.groovy.runtime.ca >>>>>>>>> llsite.AbstractCallSite.call(AbstractCallSite.java:116) >>>>>>>>> at org.codehaus.groovy.runtime.ca >>>>>>>>> llsite.AbstractCallSite.call(AbstractCallSite.java:128) >>>>>>>>> at gant.Gant.main(Gant.groovy:668) >>>>>>>>> ... 6 more >>>>>>>>> >>>>>>>>> The line in Gant is >>>>>>>>> def cli =3D new CliBuilder(usage: 'gant [option]* [target]*', par= ser: >>>>>>>>> new GnuParser()) >>>>>>>>> >>>>>>>>> Was this breakage intentional? I think a lot of stuff will break >>>>>>>>> with parser not being able to be set anymore. >>>>>>>>> >>>>>>>>> -Keegan >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >> > --000000000000ee181d056c7abd5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So do you want to change this back for R= C3?=C2=A0 I know it's late to change this, but arguably it was late to = change it in RC2 too.

-Keega= n


On Thu, May 10, 2018, 11:08 AM Remko Po= pma <remko.po= pma@gmail.com> wrote:
I updated the PR to make the signature of `setPosix` accept Boolean instead of boolean and added= tests to ensure that nulls are handled correctly. Thanks for pointing that= out!=C2=A0

The picocli version of CliBuilder has tests = to verify that Java-like properties such as -Dkey=3Dvalue are processed correctly in the new version just l= ike in the commons-cli version. (For multiple properties the option can be = specified multiple times: -Da=3Db -Dx= =3Dz )

I have not created a dummy setter fo= r `setOptions` for the reason yo= u mentioned:
if users use this to configure the options it is pro= bably better to fail with a compiler error than silently ignoring such opti= ons.

It's hard to tell how many people would b= e impacted by this, but if we want=20 2.5=C2=A0to be compatible with 2.4 we cann= ot make picocli the default in 2.5.



On Thu, May 10,= 2018 at 8:42 AM, Keegan Witt <keeganwitt@gmail.com<= /a>> wrote:
Here's all the differences between 2.4 and 2.5
  • setForm= atter(org.apache.commons.cli.HelpFormatter)=C2=A0 (in the PR)
    • =
  • setParser(org.apache.commons.cli.CommandLineParser)=C2=A0 =C2=A0(i= n the PR)
  • setOptions(org.apache.commons.cli.Options)
    • <= li>setPosix(java.lang.Boolean)=C2=A0 (changed from boolean to Boolean, also= =20 it's deprecated)
I= 'd guess setFormatter() wouldn't = be a very common thing to do (I think it'd only really come up if HelpFormatter were subclassed for some reason)= , so that one's probably not a big risk.=C2=A0 But I'm not sure=C2= =A0setOptions() is safe to dummy up -- fo= lks might be relying on this to configure the options to parse.=C2=A0 This = might be a reason not to default to picocli yet.=C2=A0 What do you think?
=
I also looked at how current arguments passed on the commandline coul= d break with the move, and the only thing I noticed was Commons CLI says it= can do Java-like properties such as=C2=A0-Djava.awt.headless=3Dtrue (alth= ough I didn't see how you'd actually configure these options unless= you jammed all of them into 1 giant option).

-Keegan


On Tue, May 8, 2018 at 1:06 AM, Paul King <paulk@asert.com.au> wrote:
Short answer is we can ha= ve as many RCs as needed to get it right but we don't really want to be= chopping and changing too much. Big changes are supposed to be settling do= wn by now - fate just brought this change late in the game compared to what= we'd like. I'd really like to get +ve feedback from a SNAPSHOT wit= h that change before doing another release including it. I can merge in a c= ouple of days time after conference commitments.

Cheers,= Paul.

On Tue, May 8, 2018 at 2:27 PM,= Remko Popma <remko.popma@gmail.com> = wrote:
=
I realize now that simply remov= ing the `parser` and `formatter` properties was a mistake. While the picocl= i version of CliBuilder cannot use commons-cli classes I should have antici= pated that some applications are setting these properties.

I believe that I have a solution that pr= ovides a smoother migration path.=C2=A0 PR=C2=A0
https://github.com/apache/groovy/pull/6= 96 adds dummy setters for the legacy properties.=C2=A0

This should significantly reduce the dis= ruption for applications like Gant that depend on the ability to modify the= se commons-cli properties in CliBuilder.=C2=A0

<= /div>
Would it be possible to have another 2.5-rc release = with the above change and see what the community feedback is before we deci= de to revert the CliBuilder delegation to point to the commons-cli implemen= tation?

Marking the dele= gation version class as deprecated is probably a good idea regardless of wh= ere it points to.=C2=A0

Remko


On Tu= e, May 8, 2018 at 3:19 Paul King <paulk@asert.com.au> wrote:
<= /div>

=
Both CliBuilder implementations are there via their full package names= , so encouraging people to use the non-delegated implementation of their ch= oice is a good option. They will need to get used to such changes in Groovy= 3 anyway.

For Groovy 3, we might have a way for t= he compiler to translate from the existing package names to the new ones br= ought about by JDK9 modules, in which case we'd do that for CliBuilder = and we'd want to point it to the picocli package name by then (though i= f we do the change below we perhaps wouldn't include CliBuilder in the = translations list).

For 2.5, we don't have the= package translation in place and don't intend to. Because of that, the= point of the delegation version is to aid in migration.
Maybe it was = too big a jump to try to delegate to the Picocli delegation in 2.5. If we f= ind too many problems I think I should revert that change and delegate to t= he commons cli implementation instead but mark the whole delegation version= class as deprecated.

Let me know what people think.
=

Cheers, Paul.


On Mon, May 7, 2018 at 3:4= 5 PM, Keegan Witt <keeganwitt@gmail.com> wrote:
I'll take a look.=C2=A0 I'll also see if there are othe= r places that can break.

If there are several ways it can break, then maybe we should not use a del= egate to picocli and instead have folks switch the CliBuilder instance they= instantiate.

-Keegan

<= div class=3D"gmail_quote">
On Sun, May 6, 2018, 7:56 PM Remko Popma <= ;remko.popma@gmail.com> wrote:
I think I found a way to fix this.
This PR adds CliBuilder.setParser and CliBuilder.setFormatt= er methods that ignore the specified value and print a warning to stderr.

On Sun,= May 6, 2018 at 9:14 PM, Remko Popma <remko.popma@gm= ail.com> wrote:
In 2.5.0-rc-2, groovy.util.CliBuilder delega= tes to groovy.cli.picocli.CliBuilder. The error is that the `parser` proper= ty of this class is no longer writable.=C2=A0

You can resolve this with 2.5.0-rc-2 by either not se= tting the `parser` property in the CliBuilder constructor or using the groo= vy.cli.commons.CliBuilder instead.=C2=A0

<= div dir=3D"auto">On the Groovy side I=E2=80=99m not sure what the best way = is to make the transition easier.=C2=A0 The picocli version of CliBuilder c= an not make use of the Commons-CLI parser class.=C2=A0 We could modify CliB= uilder to silently ignore the specified parser. =C2=A0(We=E2=80=99d have to= rename the picocli ParserSpec `parser` property in CliBuilder to something= else.)=C2=A0

Thoughts?<= /div>

<= br>
On Sun, May 6, 2018 at 20:35 Keegan Witt= <keeganwitt@gmail.com> wrote:
FYI 2.5.0-rc-2 breaks Gant.= =C2=A0 Specifically, it's caused by changing groovy.util.CliBuilder to = use Picocli

java.lang.reflect.InvocationTargetException
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at sun.reflect.NativeMethodAccessorImpl= .invoke0(Native Method)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodA= ccessorImpl.java:62)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at = sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe= thodAccessorImpl.java:43)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 at java.lang.reflect.Method.invoke(Method.java:498)
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.codehaus.groovy.tools.GroovyS= tarter.rootLoader(GroovyStarter.java:114)
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:136)
Caused by: groovy.lang.ReadOnlyPropertyEx= ception: Cannot set readonly property: parser for class: groovy.util.CliBui= lder
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at groovy.lang.MetaClass= Impl.setProperty(MetaClassImpl.java:2746)
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 at groovy.lang.MetaClassImpl.setProperty(Meta= ClassImpl.java:3782)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at = groovy.lang.MetaClassImpl.setProperties(MetaClassImpl.java:1759)<= br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.codehaus.g= roovy.runtime.callsite.ConstructorSite$NoParamSite.callConstr= uctor(ConstructorSite.java:125)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 at org.codehaus.groovy.runtime.callsite.Call= SiteArray.defaultCallConstructor(CallSiteArray.java:59)
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.codehaus.groovy.run= time.callsite.AbstractCallSite.callConstructor(AbstractC= allSite.java:238)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at org.codehaus.groovy.runtime.callsite.AbstractCallSite.ca= llConstructor(AbstractCallSite.java:250)
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 at gant.Gant.processArgs(Gant.groovy:463)
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at gant.Gant$processArgs.call(Unk= nown Source)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at o= rg.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall= (CallSiteArray.java:47)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = at org.codehaus.groovy.runtime.callsite.AbstractCallSi= te.call(AbstractCallSite.java:116)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 at org.codehaus.groovy.runtime.callsite.A= bstractCallSite.call(AbstractCallSite.java:128)
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 at gant.Gant.main(Gant.groovy:668)
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ... 6 more

=
The line in Gant is
=
def cli <= span class=3D"m_2911809978027779446m_4535751520463878257m_-2467067137765668= 590m_-3806124421038987042gmail-m_-6231764969808406851m_7074418651198899159m= _-2182455291778554980m_4622348434950625675m_8474525986025357084m_-140666053= 7501849648m_-8506474854683483705m_-7347739940866588638m_-570386063535828302= 4gmail-pl-k" style=3D"box-sizing:border-box;color:rgb(205,168,105)">=3D ne= w CliBuilder(usage: 'gant [option]* [target]*', parser: = new GnuParser())

Was this breakage intentional?=C2=A0 I think a lot o= f stuff will break with parser not being able to be set anymore.

-Keegan
<= /div>





--000000000000ee181d056c7abd5c--