Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
MIME-Version: 1.0
In-Reply-To: <CAE7C0Pc9TYfWt+A76BaxcR2BfOeBhwW579=URCFLQN18+Cb7Dg@mail.gmail.com>
References: <3b40e79d-1ece-2aed-043d-df88dece9853@gmail.com>
 <5515f25e-111d-6b20-4e2c-a9b0e024fdbb@CloudsoftCorp.com> <CAE7C0Pc9TYfWt+A76BaxcR2BfOeBhwW579=URCFLQN18+Cb7Dg@mail.gmail.com>
From: Martin Harris <martin.harris@cloudsoftcorp.com>
Date: Tue, 7 Mar 2017 09:23:14 +0000
Message-ID: <CAEzXC-EkHDyKvh6ysPkpBdQekJcDu1BaRwhaD-wp-rePi_oehg@mail.gmail.com>
Subject: Re: [PROPOSAL] Remove groovy dependency/support
To: dev@brooklyn.apache.org
Content-Type: multipart/alternative; boundary=001a11408020c0da3c054a208f58
archived-at: Tue, 07 Mar 2017 09:30:39 -0000

--001a11408020c0da3c054a208f58
Content-Type: text/plain; charset=UTF-8

Would this include the removal of the Groovy console? I'd kinda miss that
:-(

Cheers

M

On 7 March 2017 at 09:10, Geoff Macartney <geoff.macartney@cloudsoftcorp.com
> wrote:

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


-- 
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
Mobile: +44 (0)7989 047-855

--001a11408020c0da3c054a208f58--