Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
MIME-Version: 1.0
References: <3b40e79d-1ece-2aed-043d-df88dece9853@gmail.com> <5515f25e-111d-6b20-4e2c-a9b0e024fdbb@CloudsoftCorp.com>
In-Reply-To: <5515f25e-111d-6b20-4e2c-a9b0e024fdbb@CloudsoftCorp.com>
From: Geoff Macartney <geoff.macartney@cloudsoftcorp.com>
Date: Tue, 07 Mar 2017 09:10:43 +0000
Message-ID: <CAE7C0Pc9TYfWt+A76BaxcR2BfOeBhwW579=URCFLQN18+Cb7Dg@mail.gmail.com>
Subject: Re: [PROPOSAL] Remove groovy dependency/support
To: dev@brooklyn.apache.org
Content-Type: multipart/alternative; boundary=94eb2c188c0a9cd717054a206367
archived-at: Tue, 07 Mar 2017 09:16:07 -0000

--94eb2c188c0a9cd717054a206367
Content-Type: text/plain; charset=UTF-8

+1 certainly sounds like a good plan

On Tue, 7 Mar 2017 at 01:17 Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
wrote:

>
> +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
> >
> >
>
>

--94eb2c188c0a9cd717054a206367--