groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: The long path to a new MOP
Date Tue, 09 Aug 2016 08:15:03 GMT


On 09.08.2016 04:08, Paul King wrote:
> Just a possible alternative tweak to your idea. The Gradle project has
> an Incubating annotation that can be added to classes, methods, etc.
> That let's you pick a final package name now that won't need to change
> later and we can remove the @Incubating once things settle down. I
> don't mind having groovy as the top-level package but if you need
> something different we could use org.apache.groovy and
> org.apache.groovy.internal (instead of the current codehaus package
> hierarchy). Just a thought.

moving the files in git is less a problem than it was with svn/cvs, so 
history will not be lost so easily... which is why I think 
renaming/moving the files later on is no real problem. The annotation 
has the nice option of marking only parts of an API as experimental. 
 From the interoperability pov I think this is a better option... Or I 
should say the package name is not enough by itself. I like the idea... 
especially since we could change our doc tool to ignore those methods 
for example

As for the apache name... I was just thinking that this is a good 
opertunity to move some things to org.apache.groovy, since we are 
normally obliged to do so under the apache umbrella and did not before, 
because of binary incompatibility. But if we now introduce now classes 
in a new package, then org.apache.groovy is a good choice I think. 
Though initially I was thinking we should keep the groovy package, for 
shorter impoprts. On the other hand... the only important package in 
groovy scripts here is probably the transforms package... we will see

bye Jochen

Mime
View raw message