brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Subject Re: [PROPOSAL] Remove groovy dependency/support
Date Tue, 07 Mar 2017 01:11:39 GMT

+1

Minor comments:

 > 2. For a "MethodEffector", the effector invocation goes through
 >   `GroovyJavaMethods.invokeMethodOnMetaClass`. This calls into groovy
 >   code to find the method that matches the given arguments.

Reflections.findMethodMaybe and invokeMethodWithArgs might be drop-in 
replacements

 > one can often supply a Groovy closure instance (e.g. as a config key 
value) and
 > have it automatically converted to Predicate/Function/etc

Java 8-isms should let us overhaul this.  As a first step in 0.11 for 
good measure we should log.warn if a Closure is being supplied.

--A



On 06/03/2017 19:01, Aled Sage wrote:
> Hi all,
>
> I propose we deprecate and then remove the remaining groovy code from 
> Brooklyn: deprecate for 0.11.0, and delete a couple of releases later.
>
> I think we should treat Groovy like any other JVM-based language that 
> users might want to use: it's the user's responsibility; we present a 
> pure Java API that those languages can call.
>
> I'd estimate the first stage (deprecation in 0.11.0) as being just a 
> few hours work.
>
> _*Advantages of Deleting this Code*_
>
>  * Simplify our code base
>    (with all the usual advantages of understandability, simpler
>    refactoring, etc).
>  * Make support easier
>    (luckily no-one has asked any Groovy questions in years! Do we
>    really want to fix any bugs that Groovy users hit?!)
>  * Make it easier for (Java) developers:
>      o More understandable e.g. the black magic of how "MethodEffector"
>        works.
>      o Easier IDE setup (e.g. don't need to worry about .groovy files,
>        or risk breaking them if you ignore them)
>  * Simplify our build process
>  * Reduce our binary distribution by over 7MB
>
>
> _*Background*_
> The most early versions of Brooklyn (before it joined Apache) were 
> written in Groovy. We grew to regret that technology choice, and 
> switched to pure Java instead. We also now strongly recommend users to 
> focus on YAML-based blueprints whereever possible, which makes things 
> like Groovy support even more redundant.
>
>
> _*Current Usage*_
> Groovy is (unfortunately) still used under-the-covers in a few places:
>
> 1. Groovy's `ObservableList` is used under-the-covers by
>    `LocalEntityManager.entities`.
> 2. For a "MethodEffector", the effector invocation goes through
>    `GroovyJavaMethods.invokeMethodOnMetaClass`. This calls into groovy
>    code to find the method that matches the given arguments.
> 3. `GroovyJavaMethods` is used for some groovy'isms (Groovy Truth
>    primarily).
>
> Groovy's closures have special support in various places - e.g. some 
> methods are overloaded to accept a Closure instead of a 
> Runnable/Callable/Function/Predicate. Also, the `TypeCoercions` means 
> that one can often supply a Groovy closure instance (e.g. as a config 
> key value) and have it automatically converted to Predicate/Function/etc.
>
> I think our build does special groovy stuff (e.g. there are groovy 
> test classes, which explicitly test the Closure support).
>
>
> _*Next Steps*_
> Assuming we agree...
>
> For 0.11.0:
>
>  * Deprecate all methods that take a Groovy parameter type (e.g.
>    Closure, groovy.time.TimeDuration, etc).
>  * Deprecate `GroovyJavaMethods` and the other classes in the
>    `brooklyn-utils-groovy` module.
>  * Include in the release notes that this is deprecated, and Groovy
>    will be removed from Brooklyn in a future release.
>
> Subsequently:
>
>  * Remove internal uses of Groovy, at our leisure.
>
> In some future release:
>
>  * Delete all the deprecated methods and utilities, the groovy
>    dependency, the .groovy test classes, and any other mentions of it
>    from our poms/build.
>
> I'd estimate the first stage (for 0.11.0) as being just a few hours work.
>
> Aled
>
>


Mime
View raw message