From dev-return-4481-archive-asf-public=cust-asf.ponee.io@groovy.apache.org Sun Mar 25 15:00:07 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 31CA618063B for ; Sun, 25 Mar 2018 15:00:07 +0200 (CEST) Received: (qmail 92248 invoked by uid 500); 25 Mar 2018 13:00:06 -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 92232 invoked by uid 99); 25 Mar 2018 13:00:05 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Mar 2018 13:00:05 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 1358FC0249 for ; Sun, 25 Mar 2018 13:00:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.88 X-Spam-Level: * X-Spam-Status: No, score=1.88 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, MIME_QP_LONG_LINE=0.001, 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: spamd4-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 (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id gdJgZj1EZDr5 for ; Sun, 25 Mar 2018 13:00:03 +0000 (UTC) Received: from mail-pl0-f54.google.com (mail-pl0-f54.google.com [209.85.160.54]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 15F2A5F3FF for ; Sun, 25 Mar 2018 13:00:02 +0000 (UTC) Received: by mail-pl0-f54.google.com with SMTP id m22-v6so10263247pls.5 for ; Sun, 25 Mar 2018 06:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=Z8km1943s54wf13c8kekSqljSKK9DlZLr1aQohEr/9Y=; b=itV+QW58JzQJYIS/oZYaIlgMFAq3IEVcMP7wVR/AlcgY/Ycn3jIt1ubyF7msCiWUFN a+ptiW74qpIntHhpdB3OcAigJdoUdxBZB3KFCZiOv9SOqdEO7lH9cJUI2PVpAGaZnsvV SOB5QTZM8BBV+AnqPiOkl/p1TfQ9p/EUES2eblh24H5yqOGkBS/cPQDszC5AHJWytb7d VSSI4eqeDI9USo2OxAMbbCTUenHM3G1mi8av98UWk50xSoQik6WJYuCCvckVKN77X3Be PCmP9Z04fw4DiNXJu2XLLNcdMxQETyneGqye34iMi3ecR3WZEFokA9LQlt8ezm/g5O2V yuUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=Z8km1943s54wf13c8kekSqljSKK9DlZLr1aQohEr/9Y=; b=GITpYeHL+Qz9yvSg0W1SCG3Uo3rqMnRVHsnLNY3K8mK+yGAPJi6j5zvtVnTQ2qM6xo FSkYBT5f6mViM5PbGY+ugImL4GMsdUNm5gUUUVYLgVkHDVcOdwdmOXDarcu5iCEkDHpA HcEfEhw3kHdQzyEHtDzbOUK7TDEkw57fN3WoL5OxU9LkLltHA5ot3IP9RbT0LOkbEwVg iaDRFYTBHdNbwcP6YDetOmMbDHL3HII0LFB2fRyHTGmctRwSji51DO9AjDkiEAsR2zAA hal6M0SA2eghMZY4C/9G9xc+z9XYxbJFZhD74sdE+835uite5M4owRuz2LSNp7Gotztl 0ZWA== X-Gm-Message-State: AElRT7EE1l8fmF5cHrdxlHRmcYpGEnFbkh39wlFD5YA0bqO0Gcobt7oN 4tyWDrXfKdg+eT1X8C/y86YrjRkL X-Google-Smtp-Source: AG47ELsVaFxnR+CQIylO7CD2ePKaNTIsN/uD7opU1exQmb678gcId3mQPZxWjk3L4LVGrHfk37TENA== X-Received: by 2002:a17:902:7401:: with SMTP id g1-v6mr37155604pll.4.1521982800331; Sun, 25 Mar 2018 06:00:00 -0700 (PDT) Received: from ?IPv6:2400:2200:80:8110:8dad:ffd9:e91f:dd77? ([2400:2200:80:8110:8dad:ffd9:e91f:dd77]) by smtp.gmail.com with ESMTPSA id y18sm25010933pfe.67.2018.03.25.05.59.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Mar 2018 05:59:59 -0700 (PDT) From: Remko Popma Content-Type: multipart/alternative; boundary=Apple-Mail-87539B34-4FB5-4AA8-8601-65075E8930FF Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Sun, 25 Mar 2018 21:59:58 +0900 Subject: Re: picocli-based CliBuilder backwards compatibility Message-Id: References: In-Reply-To: To: dev@groovy.apache.org X-Mailer: iPhone Mail (15D100) --Apple-Mail-87539B34-4FB5-4AA8-8601-65075E8930FF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Makes sense, will do.=20 > On Mar 25, 2018, at 21:55, Paul King wrote: >=20 > All of those classes are in modules referenced by the groovy-all pom. Swap= ping those over will be a separate activity but will be relatively straight f= orward. It should be transparent to users of the language bar some slightly d= ifferent formatting in command-line help messages. We could do that in a 2.5= .1 if needed. >=20 > Let's just progress the CliBuilder replacement first and make sure we are h= appy with that. >=20 > Feel free to create some additional Jiras if you want. >=20 > Paul. >=20 >=20 >> On Sun, Mar 25, 2018 at 8:55 PM, Remko Popma wrot= e: >> Thanks, it makes things easier if these properties can be changed. >>=20 >> FYI, the following classes also use commons-cli directly, not sure which a= re in the groovy-all jar: >>=20 >> org.codehaus.groovy.tools.shell.util.HelpFormatter=20 >> org.codehaus.groovy.tools.FileSystemCompiler >> org.codehaus.groovy.tools.GrapeMain >> groovy.ui.GroovyMain >> org.codehaus.groovy.ant.Groovyc >> org.codehaus.groovy.antlr.java.Java2GroovyMain =20 >>=20 >> If the goal is the remove the commons-cli dependency from groovy-all, sho= uld the above classes also be migrated to picocli? >>=20 >> I'll create a JIRA for migrating CliBuilder from commons-cli to picocli).= If you want I can also create a separate JIRA to create a separate module (= groovy-cli-commons or similar) with the existing CliBuilder implementation (= in a separate package). Let me know what you want to do with the classes abo= ve. >>=20 >> Remko >>=20 >>=20 >>=20 >>> On Sun, Mar 25, 2018 at 4:16 PM, Paul King wrote: >>> I think they are much less widely used than other features so feel free t= o change them. If similar functionality is available via picocli, please use= the same property name if it makes sense to expose that functionality for g= reater control. >>>=20 >>> We will likely create a separate module (groovy-cli-commons or similar) w= ith the existing CliBuilder implementation (but with probably a package name= change) that won't be referenced in the groovy-all pom. If folks are relyin= g on those bits of the functionality, they can use the legacy version. The g= oal should be to have commons-cli being a dependency of only that module. >>>=20 >>> Cheers, Paul. >>>=20 >>>> On Sun, Mar 25, 2018 at 1:58 PM, Remko Popma wr= ote: >>>> CliBuilder exposed some commons-cli classes (see below). >>>>=20 >>>> Is it okay to remove these, or should these be left as deprecated prope= rties in the CliBuilder class to retain binary compatibility with pre-2.5 ve= rsions?=20 >>>>=20 >>>> Note that if these properties remain the new picocli-based implementati= on will ignore them, so the behaviour will change. >>>>=20 >>>> /** >>>> * Normally set internally but allows you full customisation of the und= erlying processing engine. >>>> */ >>>> CommandLineParser parser =3D null >>>> /** >>>> * Normally set internally but can be overridden if you want to customi= se how the usage message is displayed. >>>> */ >>>> HelpFormatter formatter =3D new HelpFormatter() >>>> /** >>>> * Not normally accessed directly but full access to underlying options= if needed. >>>> */ >>>> Options options =3D new Options() >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail-87539B34-4FB5-4AA8-8601-65075E8930FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Makes sense, will do. 


On Mar 25, 2018, at 21:55, Paul King <paulk@asert.com.au> wrote:

All of those classes are in modules re= ferenced by the groovy-all pom. Swapping those over will be a separate activ= ity but will be relatively straight forward. It should be transparent to use= rs of the language bar some slightly different formatting in command-line he= lp messages. We could do that in a 2.5.1 if needed.

Let's= just progress the CliBuilder replacement first and make sure we are happy w= ith that.

Feel free to create some additional Jiras if yo= u want.

Paul.


On Sun, Mar 25, 2018 at 8= :55 PM, Remko Popma <remko.popma@gmail.com> wrote:
Thanks, it makes things easier if= these properties can be changed.

FYI, the following clas= ses also use commons-cli directly, not sure which are in the groovy-all jar:=

  • org.codehaus.groovy.tools.shell.util.HelpFormatter<= /span>
  • org.codehaus.groovy.tools.FileSystemCompiler
  • o= rg.codehaus.groovy.tools.GrapeMain
  • groovy.ui.GroovyMain
    • org.codehaus.groovy.ant.Groovyc
  • org.codehaus.groovy.antlr.java.Java2GroovyMain 

If the goal is the remove the commons-cl= i dependency from groovy-all, should the above classes also be migrated to p= icocli?

I'll create a JIRA for migrating CliBuilder from= commons-cli to picocli). If you want I can also create a separate JIRA to c= reate a separate module (groovy-cli-commons or similar) with the existing CliBuilder implementation (in a separate package). Let me= know what you want to do with the classes above.

Remko
<= br>


On Sun, Mar 25, 2018 at 4:16 PM, Paul King <paulk@asert.com.au>= ; wrote:
I think they are much less widely used than other features so f= eel free to change them. If similar functionality is available via picocli, p= lease use the same property name if it makes sense to expose that functional= ity for greater control.

We will likely create a separat= e module (groovy-cli-commons or similar) with the existing CliBuilder implem= entation (but with probably a package name change) that won't be referenced i= n the groovy-all pom. If folks are relying on those bits of the functionalit= y, they can use the legacy version. The goal should be to have commons-cli b= eing a dependency of only that module.

Cheers, Paul.

On Sun, Mar 25, 2018 at 1= :58 PM, Remko Popma <remko.popma@gmail.com> wrote:
CliBuilder exp= osed some commons-cli classes (see below).

Is it okay to remove= these, or should these be left as deprecated properties in the CliBuilder c= lass to retain binary compatibility with pre-2.5 versions? 
<= br>
Note that if=20 these properties remain the new picocli-based implementation will ignore them, so the behavio= ur will change.

/**
 * Normally set internally but allows y=
ou full customisation of the underlying processing engine.
 */
CommandLineP=
arser parser =3D=
 null
/**
 *= Normally set internally but can be overridden if you want to customise how t= he usage message is displayed.
 */
HelpFormatter formatter =3D new HelpFormatter()
/**
 * Not normall=
y accessed directly but full access to underlying options if needed.
 */
Op=
tions options =
=3D new Options()<=
br>




= --Apple-Mail-87539B34-4FB5-4AA8-8601-65075E8930FF--