Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 2D9A6200C44 for ; Mon, 27 Mar 2017 21:03:31 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 2C497160B85; Mon, 27 Mar 2017 19:03:31 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id EECC2160B7B for ; Mon, 27 Mar 2017 21:03:29 +0200 (CEST) Received: (qmail 55070 invoked by uid 500); 27 Mar 2017 19:03:29 -0000 Mailing-List: contact users-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@groovy.apache.org Delivered-To: mailing list users@groovy.apache.org Received: (qmail 55059 invoked by uid 99); 27 Mar 2017 19:03:28 -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; Mon, 27 Mar 2017 19:03:28 +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 7B37AC0370 for ; Mon, 27 Mar 2017 19:03:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.898 X-Spam-Level: * X-Spam-Status: No, score=1.898 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); domainkeys=pass (1024-bit key) header.from=Jason.Winnebeck@windstream.com header.d=windstream.com; dkim=pass (1024-bit key) header.d=windstream.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 bcAaVF6u8_RU for ; Mon, 27 Mar 2017 19:03:24 +0000 (UTC) Received: from vml905.windstream.com (vml905.windstream.com [173.186.244.142]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 0B2605F610 for ; Mon, 27 Mar 2017 19:03:23 +0000 (UTC) Received: from scarcnwap007.windstream.com (scarcnwap007.windstream.com [10.104.100.45]) by vml905.windstream.com (8.15.2/8.14.4) with ESMTP id v2RJ3MUl001424 for ; Mon, 27 Mar 2017 15:03:22 -0400 DomainKey-Signature: a=rsa-sha1; s=mail; d=windstream.com; c=nofws; q=dns; h=dkim-signature:from:to:subject:date:message-id:references: in-reply-to:accept-language:content-language:x-ms-has-attach: x-originating-ip:x-proofpoint-virus-version:x-proofpoint-spam-details; b=pEV6yKadtkuKbDtdamSSaHLgz+jzC6UOwhsVlxp+C6REJbo5jQSgbPiCgCchNaf6j oHztzHW/7/z74duw1oVYtX9rV47oc0ElTRDyUoL33aDwhAOextgUPNed7+DZYXi2OYJ FLyrBFFsXBJlb0fAMxSuu5fb02gKrbMHmEjWtls= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=windstream.com; s=mail; t=1490641402; bh=EoNMAXVzz40WlhPhdHbmNSSjrBr8p31R2LnFs6Qp6lo=; h=From:To:Subject:Date:Message-ID:In-Reply-To; b=Vgg4pSBYgAuNl0KY1JfJhZ4Sh0SQseztyftf1rpjH8GQRqH6y5YaWBfanq6Jt2JkV imVWDxI8b3IW2lZv33gJ6psBbwzlkp50wegK1T6svJhDVtsc8GL5Q9QxQVc0alO7eF nHV1Udkgx1D0CIsfj+c4SCIBX6HKyrmtFgvvj4ZI= Received: from pps.filterd (scarcnwap007.windstream.com [127.0.0.1]) by scarcnwap007.windstream.com (8.15.0.59/8.15.0.59) with SMTP id v2RIt7k2043926 for ; Mon, 27 Mar 2017 15:03:22 -0400 Received: from cwwapp462.windstream.com (cwwapp462.windstream.com [10.104.100.214]) by scarcnwap007.windstream.com with ESMTP id 29dmmufwxr-1 for ; Mon, 27 Mar 2017 15:03:22 -0400 Received: from CWWAPP478.windstream.com ([fe80::6d3c:7b7f:b5fc:ad94]) by CWWAPP462.windstream.com ([::1]) with mapi id 14.03.0301.000; Mon, 27 Mar 2017 15:03:22 -0400 From: "Winnebeck, Jason" To: "users@groovy.apache.org" Subject: RE: Maven coordinates going forward Thread-Topic: Maven coordinates going forward Thread-Index: AQHSpwnrAqwQEZvtXU2NV0WiyMloiKGpCjwAgAALnoCAAAoVAIAACLMAgAALfAD//8Y20IAASEMAgAAIDYD//79ccA== Date: Mon, 27 Mar 2017 19:03:21 +0000 Message-ID: <5C676E6359909E478C7B811BDB48CA3567A690@CWWAPP478.windstream.com> References: <1490629219.19826.28.camel@winder.org.uk> <1490631384130-5739409.post@n5.nabble.com> <1490635718.19826.30.camel@winder.org.uk> <5C676E6359909E478C7B811BDB48CA3567A58C@CWWAPP478.windstream.com> <58D957EA.5010302@gmx.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.140.40.211] Content-Type: multipart/alternative; boundary="_000_5C676E6359909E478C7B811BDB48CA3567A690CWWAPP478windstre_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-27_17:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703270157 archived-at: Mon, 27 Mar 2017 19:03:31 -0000 --_000_5C676E6359909E478C7B811BDB48CA3567A690CWWAPP478windstre_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't know if it was totally clear from my previous mails, but I agree on= not changing the package names, unless breaking changes are required and t= he package names need to change to preserve the ability of Groovy 1.x/2.x c= ode to co-exist, avoiding the "Python 3 Effect". If the only breaking chang= e would be the package change, then there's no sense to change the name jus= t to change the name. I think it is OK to change the Maven coordinates in any case. While it is u= sed sometimes as a starting point to look at a class and try to figure out = what library it comes from based on matching the package name to the group = ID, that's not a common operation and modern IDEs (and search.maven.org) ca= n easily answer the question if needed. The only drawback to changing Maven= coordinates is it might make it harder for people to know there is a newer= package, that is, to search for upgrades we check for more recent versions= of current dependencies. However, with a project as big as Groovy I think = it will be clear when Groovy 3 comes out that users will know. Jason From: Keith Suderman [mailto:suderman@anc.org] Sent: Monday, March 27, 2017 2:49 PM To: users@groovy.apache.org Subject: Re: Maven coordinates going forward +1 for changing Maven coordinates. -1 for changing package names. Sure, new code can use the new package name= s, but changing existing packages is just breaking changes for the sake of = breaking things with no real benefit. I hope the Groovy team tries to brea= k as little as possible to avoid the "Python3 Effect", whether real or imag= ined. Having said that, how much public facing code is in org.codehaus.groovy pac= kages? I don't think I've typed "import org.codehaus.groovy..." in my life= , but IntelliJ may have inserted a few for me. Keith On Mar 27, 2017, at 2:20 PM, Jochen Theodorou > wrote: On 27.03.2017 20:08, Winnebeck, Jason wrote: The key thing in my mind is that you can't make a change that breaks 100% of libraries at one time without fracturing the community or at least introducing a major hindrance to upgrade that will mean maintaining 2.x series for a very long time. Even if the upgrade process is as easy as a recompile, there are a lot of published libraries no longer maintained. Even for the ones that are maintained, there are people who might not want to be forced to upgrade every library. I'm not a Grails user, but my impression is that the framework relies on a lot of plugins and is one of the (if not the most) active Groovy communities and I have a hard time envisioning how that upgrade path will take. You'd have to maintain Groovy 2 and Groovy 3 versions of each plugin, and to upgrade you'd have to upgrade everything at one time to the (most likely) latest version. What is the possibility that the package names are changed, the parser, metaprogramming model, etc. that all break in Groovy 3 change, but yet still have a compatibility JAR implementing the minimal Groovy 2.x classes in a way that allows interoperability with Groovy 3 code? Theoretically at a worst case, Groovy 3 should be able to view Groovy 2 classes the same way as any other Java class. I think many concerns would be lifted if Groovy 2 and 3 could co-exist at the same time, allowing you to upgrade incrementally. If you see the new metaprogramming model as chance, then it would make sens= e to implement that in the new packages instead of transferring old and to = be deprecated classes. The goal would the to be able to run old and new sys= tem at the same time, where the Groovy 1.x/2.x classes would use Groovy 3.x= /4.x classes as implementation. The problem with this approach is simply manpower and of course some concep= tual problems still to be solved. bye Jochen ---------------------- Keith Suderman Research Associate Department of Computer Science Vassar College, Poughkeepsie NY suderman@cs.vassar.edu This email message and any attachments are for the sole use of the intended= recipient(s). Any unauthorized review, use, disclosure or distribution is = prohibited. If you are not the intended recipient, please contact the sende= r by reply email and destroy all copies of the original message and any att= achments. --_000_5C676E6359909E478C7B811BDB48CA3567A690CWWAPP478windstre_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t know if it was totally clear from my = previous mails, but I agree on not changing the package names, unless break= ing changes are required and the package names need to change to preserve the ability of Groovy 1.x/2.x code to co-exist, avoi= ding the “Python 3 Effect”. If the only breaking change would b= e the package change, then there’s no sense to change the name just t= o change the name.

 

I think it is OK to change the Maven coordinates in= any case. While it is used sometimes as a starting point to look at a clas= s and try to figure out what library it comes from based on matching the package name to the group ID, that’s not = a common operation and modern IDEs (and search.maven.org) can easily answer= the question if needed. The only drawback to changing Maven coordinates is= it might make it harder for people to know there is a newer package, that is, to search for upgrades we check fo= r more recent versions of current dependencies. However, with a project as = big as Groovy I think it will be clear when Groovy 3 comes out that users w= ill know.

 

Jason

 

From: Keith Suderman [mailto:suderma= n@anc.org]
Sent: Monday, March 27, 2017 2:49 PM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward

 

+1 for changing Maven coordinates.

 

-1 for changing package names.  Sure, new code = can use the new package names, but changing existing packages is just break= ing changes for the sake of breaking things with no real benefit.  I h= ope the Groovy team tries to break as little as possible to avoid the "Python3 Effect", whether real or imagi= ned.

 

Having said that, how much public facing code is in = org.codehaus.groovy packages?  I don't think I've typed "import o= rg.codehaus.groovy..." in my life, but IntelliJ may have inserted a fe= w for me.

 

Keith

 

 

On Mar 27, 2017, at 2:20 PM, Jochen Theodorou <blackdrag@gmx.org> wrote:

 

On 27.03.2017 20:08, Winnebeck, Jason wrote:

The key thing in my mind is that you can't make a ch= ange that breaks
100% of libraries at one time without fracturing the community or at
least introducing a major hindrance to upgrade that will mean
maintaining 2.x series for a very long time. Even if the upgrade
process is as easy as a recompile, there are a lot of published
libraries no longer maintained. Even for the ones that are
maintained, there are people who might not want to be forced to
upgrade every library. I'm not a Grails user, but my impression is
that the framework relies on a lot of plugins and is one of the (if
not the most) active Groovy communities and I have a hard time
envisioning how that upgrade path will take. You'd have to maintain
Groovy 2 and Groovy 3 versions of each plugin, and to upgrade you'd
have to upgrade everything at one time to the (most likely) latest
version.

What is the possibility that the package names are changed, the
parser, metaprogramming model, etc. that all break in Groovy 3
change, but yet still have a compatibility JAR implementing the
minimal Groovy 2.x classes in a way that allows interoperability with
Groovy 3 code? Theoretically at a worst case, Groovy 3 should be able
to view Groovy 2 classes the same way as any other Java class. I
think many concerns would be lifted if Groovy 2 and 3 could co-exist
at the same time, allowing you to upgrade incrementally.


If you see the new metaprogramming model as chance, then it would make sens= e to implement that in the new packages instead of transferring old and to = be deprecated classes. The goal would the to be able to run old and new sys= tem at the same time, where the Groovy 1.x/2.x classes would use Groovy 3.x/4.x classes as implementation.=

The problem with this approach is simply manpower and of course some concep= tual problems still to be solved.

bye Jochen

 

----------------------

Keith Suderman

Research Associate<= /p>

Department of Computer Science

Vassar College, Poughkeepsie NY<= /o:p>

 

 

 

 

This email message and any attachments are for the sole use of the intended= recipient(s). Any unauthorized review, use, disclosure or distribution is = prohibited. If you are not the intended recipient, please contact the sende= r by reply email and destroy all copies of the original message and any att= achments.
--_000_5C676E6359909E478C7B811BDB48CA3567A690CWWAPP478windstre_--