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 5EC0D200C46 for ; Wed, 29 Mar 2017 21:42:56 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 5D03F160B8A; Wed, 29 Mar 2017 19:42:56 +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 51A31160B5D for ; Wed, 29 Mar 2017 21:42:55 +0200 (CEST) Received: (qmail 16468 invoked by uid 500); 29 Mar 2017 19:42:54 -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 16458 invoked by uid 99); 29 Mar 2017 19:42:54 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Mar 2017 19:42:54 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 0DA07C0DAE for ; Wed, 29 Mar 2017 19:42:54 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.204 X-Spam-Level: X-Spam-Status: No, score=0.204 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id kyYOQZJoigJy for ; Wed, 29 Mar 2017 19:42:50 +0000 (UTC) Received: from homiemail-a81.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 0845A5FC4A for ; Wed, 29 Mar 2017 19:42:49 +0000 (UTC) Received: from homiemail-a81.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a81.g.dreamhost.com (Postfix) with ESMTP id 31FB24F31 for ; Wed, 29 Mar 2017 12:42:43 -0700 (PDT) Received: from new-host-2.home (pool-173-62-64-171.pghkny.fios.verizon.net [173.62.64.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: keith@suderman.com) by homiemail-a81.g.dreamhost.com (Postfix) with ESMTPSA id 90A434F30 for ; Wed, 29 Mar 2017 12:42:42 -0700 (PDT) From: Keith Suderman Content-Type: multipart/alternative; boundary="Apple-Mail=_6D32F164-375F-4BFC-9ADD-BD333219394D" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Maven coordinates going forward Date: Wed, 29 Mar 2017 15:42:40 -0400 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> <5C676E6359909E478C7B811BDB48CA3567A690@CWWAPP478.windstream.com> <6dcc9fdd-4de9-acec-acc7-897b9214987f@gmx.org> To: users@groovy.apache.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) archived-at: Wed, 29 Mar 2017 19:42:56 -0000 --Apple-Mail=_6D32F164-375F-4BFC-9ADD-BD333219394D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Given C=C3=A9dric's email and recent comments I think I have been = convinced to change my vote to a -1 for changing Maven coordinates or = package names. Is there a compelling technical argument for either change? Going by = the old adage, "if it ain't broke don't fix it", what exactly is being = "fixed"? It seems most arguments in favour are political/aesthetic and = not technical in nature. Besides, think of using org.codehaus.groovy as paying homage to Groovy's = long and storied history. ;-) Keith > On Mar 29, 2017, at 5:08 AM, Miro Bezjak = wrote: >=20 > -1 for both maven coordinates and package change. Please don't break = backwards compatibility. Maybe I'm missing something but I see no good = reason for either change. >=20 > As others have mentioned, there is a lot of unmaintained code that = would stop working as a result of a package change. So in my opinion, = pros would need to be greater than the fact that the whole groovy = ecosystem can suddenly do less than before the change. >=20 > As for maven coordinates, please see C=C3=A9dric's mail. Again, pros = do not outweigh the cons in my opinion. Dependecy resolution conflict = problem that doesn't exist if maven coordinates stay the same. >=20 > Just my 2 cents. >=20 > On Mar 28, 2017 7:42 PM, "C=C3=A9dric Champeau" = > wrote: > One thing one has to consider when changing Maven coordinates, is... = Maven. Despite being a build tool, it does a fairly poor job when = coordinates change. In particular, think of conflict resolution. What = should it decide if A depends on org.codehaus.groovy:2.4.10 and B = depends on org.apache.groovy:groovy-all:3.0? Maven is pretty bad at = this. We have strategies to deal with this in Gradle (dependency = substitution), but it will imply that projects could find different = artifacts on classpath in the future, for a dependency on Groovy. >=20 > That said, I'm open to changing the coordinates. I would do this for = the "breaking" version of Groovy, whatever it is, but not before. Which = means, the same version as the one we change package names. >=20 > 2017-03-28 19:03 GMT+02:00 Keegan Witt >: > I'm +1 on Maven coordinate change. That should be fairly low impact. >=20 > I agree package renames should be taken on a case-by-case basis. = Offhand, the two biggest things that come to mind are custom ASTs, and = the compilation bits. For the former, I'd think it shouldn't be any = worse than the groovy.transforms move. For the latter, it might make = sense to wait to rename that package until the compilation is decoupled = from the core. >=20 > On Tue, Mar 28, 2017 at 9:36 AM, Jochen Theodorou > wrote: >=20 > On 27.03.2017 22 :14, Wilson MacGyver wrote: > as I recall, there are also rules about jigsaw not allowing same = package > path from multiple modules. It's not till java 9, but that maybe a = concern. >=20 > That is right, yes... it is only a problem for Groovy as named or = automatic module though. As long as Groovy stays in the = classpath/annonymous module variant, there is no such problem with = multiple jars, as long as the overlapping package names are all from the = classpath/annonymous module >=20 >=20 > bye Jochen >=20 >=20 >=20 ---------------------- Keith Suderman Research Associate Department of Computer Science Vassar College, Poughkeepsie NY suderman@cs.vassar.edu --Apple-Mail=_6D32F164-375F-4BFC-9ADD-BD333219394D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Given C=C3=A9dric's email and recent comments I think I have = been convinced to change my vote to a -1 for changing Maven coordinates = or package names.

Is = there a compelling technical argument for either change?  Going by = the old adage, "if it ain't broke don't fix it", what exactly is being = "fixed"?  It seems most arguments in favour are political/aesthetic = and not technical in nature.

Besides, think of using = org.codehaus.groovy as paying homage to Groovy's long and storied = history. ;-)

Keith

On Mar 29, 2017, at 5:08 AM, = Miro Bezjak <bezjak.miro@gmail.com> wrote:

-1 for both = maven coordinates and package change. Please don't break backwards = compatibility. Maybe I'm missing something but I see no good reason for = either change.

As others have mentioned, there is a lot of = unmaintained code that would stop working as a result of a package = change. So in my opinion, pros would need to be greater than the fact = that the whole groovy ecosystem can suddenly do less than before the = change.

As for maven coordinates, please see C=C3=A9dric's mail. Again, = pros do not outweigh the cons in my opinion. Dependecy resolution = conflict problem that doesn't exist if maven coordinates stay the = same.

Just = my 2 cents.

On Mar 28, 2017 7:42 PM, "C=C3=A9dric Champeau" = <cedric.champeau@gmail.com> wrote:
One thing one has to = consider when changing Maven coordinates, is... Maven. Despite being a = build tool, it does a fairly poor job when coordinates change. In = particular, think of conflict resolution. What should it decide if A = depends on org.codehaus.groovy:2.4.10 and B depends on = org.apache.groovy:groovy-all:3.0? Maven is pretty bad at = this. We have strategies to deal with this in Gradle (dependency = substitution), but it will imply that projects could find different = artifacts on classpath in the future, for a dependency on Groovy.

That said, I'm open to = changing the coordinates. I would do this for the "breaking" version of = Groovy, whatever it is, but not before. Which means, the same version as = the one we change package names.

2017-03-28 19:03 GMT+02:00 Keegan Witt <keeganwitt@gmail.com>:
I'm +1 on Maven coordinate change.  That = should be fairly low impact.

I agree = package renames should be taken on a case-by-case basis.  Offhand, = the two biggest things that come to mind are custom ASTs, and the = compilation bits.  For the former, I'd think it shouldn't be any = worse than the groovy.transforms move.  For the latter, it might = make sense to wait to rename that package until the compilation is = decoupled from the core.

On Tue, Mar 28, 2017 at 9:36 AM, = Jochen Theodorou <blackdrag@gmx.org> wrote:

On 27.03.2017 22:14, Wilson MacGyver = wrote:
as I recall, there are also rules about jigsaw not allowing same = package
path from multiple modules. It's not till java 9, but that maybe a = concern.

 That is right, yes... it is only a problem for Groovy as named or = automatic module though. As long as Groovy stays in the = classpath/annonymous module variant, there is no such problem with = multiple jars, as long as the overlapping package names are all from the = classpath/annonymous module


bye Jochen




----------------------
Keith = Suderman
Research Associate
Department of Computer = Science
Vassar = College, Poughkeepsie NY




= --Apple-Mail=_6D32F164-375F-4BFC-9ADD-BD333219394D--