[groovy-dev] GPars and Groovy

[Russel Winder]

With all the changes around the Groovy project, projects such as GPars
and Spock need to plan their future. Spock is SEP, hopefully the Spock
team are thinking about what to do. As for GPars:

GPars was a separate project so as to have an independent development
cycle. Also Groovy was monolithic at the time, and GPars needed to have
a separate existence so as to be usable with Java.

GPars can remain a separate project but some futures of Groovy may
impact massively wrt Groovy distributions.

Groovy is now modularized and it would be possible for GPars to be a
module in the Groovy codebase.

Given the state of Groovy, GPars, etc. I wonder if merging GPars into
Groovy as a module might be for the best of both GPars and Groovy.

[Guillaume Laforge]

Hi Russel,

Might indeed be a possibility to have GPars as a Groovy module.
I'm interested in hearing what others think.

We already bundle GPars in the distribution, so why not go the next mile,
I'm open to this.

And for reference, historically, we had thought about integrating GPars in
Groovy, but then Groovy wasn't modularized, and we didn't want to tie GPars
rapidly evolving codebase to be too tied to Groovy's.

What's the current status with the jsr-xxx extensions and with JDK versions?
The state of remoting?

Guillaume

Post by Russel Winder
With all the changes around the Groovy project, projects such as GPars
and Spock need to plan their future. Spock is SEP, hopefully the Spock
GPars was a separate project so as to have an independent development
cycle. Also Groovy was monolithic at the time, and GPars needed to have
a separate existence so as to be usable with Java.
GPars can remain a separate project but some futures of Groovy may
impact massively wrt Groovy distributions.
Groovy is now modularized and it would be possible for GPars to be a
module in the Groovy codebase.
Given the state of Groovy, GPars, etc. I wonder if merging GPars into
Groovy as a module might be for the best of both GPars and Groovy.
--
Russel.
=============================================================================
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[jim northrop]

hi guillaume
was also thinking where Caelyf should fit into this pattern. All our trial
periods have ended with our current cloud foundry providers, so if we can
decide which package name to use for Caelyf, then i can update stuff for
next week when(if) we can get a new CF provider.

Alternatively i can hold off until we resolve the naming conventions for
groovy/gpars/gradle etc. and do one big fix. thoughts ??

thx jim

Post by Guillaume Laforge
Hi Russel,
Might indeed be a possibility to have GPars as a Groovy module.
I'm interested in hearing what others think.
We already bundle GPars in the distribution, so why not go the next mile,
I'm open to this.
And for reference, historically, we had thought about integrating GPars in
Groovy, but then Groovy wasn't modularized, and we didn't want to tie GPars
rapidly evolving codebase to be too tied to Groovy's.
What's the current status with the jsr-xxx extensions and with JDK versions?
The state of remoting?
Guillaume

Post by Russel Winder
With all the changes around the Groovy project, projects such as GPars
and Spock need to plan their future. Spock is SEP, hopefully the Spock
GPars was a separate project so as to have an independent development
cycle. Also Groovy was monolithic at the time, and GPars needed to have
a separate existence so as to be usable with Java.
GPars can remain a separate project but some futures of Groovy may
impact massively wrt Groovy distributions.
Groovy is now modularized and it would be possible for GPars to be a
module in the Groovy codebase.
Given the state of Groovy, GPars, etc. I wonder if merging GPars into
Groovy as a module might be for the best of both GPars and Groovy.
--
Russel.
=============================================================================
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

--
Guillaume Laforge
Groovy Project Manager
Pivotal, Inc.
Blog: http://glaforge.appspot.com/
<https://plus.google.com/u/0/114130972232398734985/posts>

[Guillaume Laforge]

Regarding Caelyf, it seems we haven't really been able to attract a user
base behind the project, so I'm not sure it's still worth investing time in
it.

On Thu, Feb 19, 2015 at 8:41 PM, jim northrop <

Post by jim northrop
hi guillaume
was also thinking where Caelyf should fit into this pattern. All our trial
periods have ended with our current cloud foundry providers, so if we can
decide which package name to use for Caelyf, then i can update stuff for
next week when(if) we can get a new CF provider.
Alternatively i can hold off until we resolve the naming conventions for
groovy/gpars/gradle etc. and do one big fix. thoughts ??
thx jim

Post by Guillaume Laforge
Hi Russel,
Might indeed be a possibility to have GPars as a Groovy module.
I'm interested in hearing what others think.
We already bundle GPars in the distribution, so why not go the next mile,
I'm open to this.
And for reference, historically, we had thought about integrating GPars
in Groovy, but then Groovy wasn't modularized, and we didn't want to tie
GPars rapidly evolving codebase to be too tied to Groovy's.
What's the current status with the jsr-xxx extensions and with JDK versions?
The state of remoting?
Guillaume

Post by Russel Winder
With all the changes around the Groovy project, projects such as GPars
and Spock need to plan their future. Spock is SEP, hopefully the Spock
GPars was a separate project so as to have an independent development
cycle. Also Groovy was monolithic at the time, and GPars needed to have
a separate existence so as to be usable with Java.
GPars can remain a separate project but some futures of Groovy may
impact massively wrt Groovy distributions.
Groovy is now modularized and it would be possible for GPars to be a
module in the Groovy codebase.
Given the state of Groovy, GPars, etc. I wonder if merging GPars into
Groovy as a module might be for the best of both GPars and Groovy.
--
Russel.
=============================================================================
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

--
Guillaume Laforge
Groovy Project Manager
Pivotal, Inc.
Blog: http://glaforge.appspot.com/
<https://plus.google.com/u/0/114130972232398734985/posts>

[Russel Winder]

[
.]
What's the current status with the jsr-xxx extensions and with JDK versions?

So as to run on JDK 1.7, GPars mainline still uses extra166y, but we
have an internal clone so there is no transitive dependency on any
JSR166 artefacts. GPars does not run on JDK 1.6 so there is no need
for jsr166y.jar.

The JDK 1.8 work is currently stalled, but really needs to get going
again. The question would be how to organize this in a "Groovy module"
context. Currently it is a feature branch in the GPars repository,
maybe this can be the same. The issue is whether to use classifiers to
distinguish the (effectively deprecated) JDK 1.7 version from the JDK
1.8+ version, or whether to encode things in the artefact name.

The state of remoting?

Remoting works and is already in Groovy since it has 1.3.0-SNAPSHOT. I
am sure there are things to be done, but that is now a maintenance
thing rather than a first development thing.

There is one more pull request to finalize, and then we can almost
certainly release 1.3.0. This JDK 1.7 version should then go into
maintenance mode only, and the JDK 1.8 version should become the
mainline with a view to making JDK 1.8 the base version of Java for
GPars. (*)

Of course if GPars were to become a Groovy module some of this
planning would have to change to fit with the Groovy Way™.


(*) Given the rejection of ParallelArray in favour of Stream in JDK 1.8 (which in my view is a good thing) continuing with ParallelArray in GPars is the wrong thing to do.

[Russel Winder]

On Fri, 2015-02-20 at 08:06 +0000, Russel Winder wrote:
[
]
The JDK 1.8 work is currently stalled, but really needs to get going
again. The question would be how to organize this in a "Groovy [
]

I should have mentioned that there is an option of removing all the
extra166y dependent stuff and not replacing it at all, i.e. remove all
the current GPars API that is now just an adaptor to Stream API and
get Groovy people using Streams directly. I am torn between:

1. it is important to preserve the GPars API and just change the way
it is presented.

2. it is important to have as little code as possible between the user
code and the infrastructure code. This reinforces that Groovy is as
close to Java as it is possible to be.

Since Groovy Closures can be used where a Stream function might expect
a lambda expression, the interworking of Groovy and Java Streams makes
it highly feasible to follow 2 at the expense of breaking everyone's
code.

This is why the current policy is to declare the JDK 1.8 version of
GPars as GPars 2, it is likely a serious breaking change of API as
well as implementation.

The philosphy here is that GPars should be as small as possible, but
no smaller. 1 above breaks this, whereas 2 follows it.

It is also worth noting that ParallelArray was an eager system with
allocations, Stream is a lazy system avoiding allocations. Hence why
the former was rejected for Java in favour of the latter.

[Thibault Kruse]

I don't know enough about GPars to have an opinion, so it might be
good to have GPars within Groovy.

However, just speaking generally, I believe it is good for a language
project to be minimal interms of non-essential features.

In python there are several modules that are part of the distribution,
but already suerceded (e.g. optparse, a cli library). That means this
module also needs to be tested and shipped and supported, it cannot
easily be retired, releasing developer resourcs to focus on more
important aspects. The same happens for java and swing (superceded by
FX).

Of course it is very difficult to reach consensus about what libraries
are essential and what libraries are not. In the Groovy case, it is
particularly difficult because existing java libraries can sometimes
be regarded as adequate support of a feature. I think my philosophy
there is: If a developer new to the language creating an average
project is quite likely to be looking for feature support *2 weeks
into the project*, and there is no obvious 3rdparty choice, then that
feature is essential. Else not. Else it can be an independent
dependency that the developer has to find via google and painstakingly
evaluate as to whether it fits his needs.

So I personally would, at a glance, find it acceptable if groovy-core
got rid of: groovy-ant, groovy-bsf, groovy-groovysh, groovy-jmx,
groovy-sql, groovy-swing.

I have not done many groovy projects, but I can imagine a lot of
projects being developed where the developers are not even aware of
the existence of these submodules.

Those could be individual projects on their own, which don't just have
independent development cycles, but also independent life
expectancies. I assume this list is highly controversial, and even I
might add or remove items if I learned more about the subprojects.

Post by Russel Winder
With all the changes around the Groovy project, projects such as GPars
and Spock need to plan their future. Spock is SEP, hopefully the Spock
GPars was a separate project so as to have an independent development
cycle. Also Groovy was monolithic at the time, and GPars needed to have
a separate existence so as to be usable with Java.
GPars can remain a separate project but some futures of Groovy may
impact massively wrt Groovy distributions.
Groovy is now modularized and it would be possible for GPars to be a
module in the Groovy codebase.
Given the state of Groovy, GPars, etc. I wonder if merging GPars into
Groovy as a module might be for the best of both GPars and Groovy.
--
Russel.
=============================================================================
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Guillaume Laforge]

So far we haven't removed any of our modules, but it's an interesting
question.
There are obviously things that are probably not used very much, but the
problem is that we actually don't / can't know the usage of the modules.
We might think one module is not important and barely used, and then get
tons of requests after removing it by people angry at us for doing so :-)

Of the ones you listed, I'd actually keep them all... except bsf, which is
probably the least used of them all.
But SQL, Swing, Ant, are still used, we often see requests about them.
Groovysh is part of the distrubution as the groovysh tool, so not likely to
be removed.
We don't hear much about the jmx one.

Post by Thibault Kruse
I don't know enough about GPars to have an opinion, so it might be
good to have GPars within Groovy.
However, just speaking generally, I believe it is good for a language
project to be minimal interms of non-essential features.
In python there are several modules that are part of the distribution,
but already suerceded (e.g. optparse, a cli library). That means this
module also needs to be tested and shipped and supported, it cannot
easily be retired, releasing developer resourcs to focus on more
important aspects. The same happens for java and swing (superceded by
FX).
Of course it is very difficult to reach consensus about what libraries
are essential and what libraries are not. In the Groovy case, it is
particularly difficult because existing java libraries can sometimes
be regarded as adequate support of a feature. I think my philosophy
there is: If a developer new to the language creating an average
project is quite likely to be looking for feature support *2 weeks
into the project*, and there is no obvious 3rdparty choice, then that
feature is essential. Else not. Else it can be an independent
dependency that the developer has to find via google and painstakingly
evaluate as to whether it fits his needs.
So I personally would, at a glance, find it acceptable if groovy-core
got rid of: groovy-ant, groovy-bsf, groovy-groovysh, groovy-jmx,
groovy-sql, groovy-swing.
I have not done many groovy projects, but I can imagine a lot of
projects being developed where the developers are not even aware of
the existence of these submodules.
Those could be individual projects on their own, which don't just have
independent development cycles, but also independent life
expectancies. I assume this list is highly controversial, and even I
might add or remove items if I learned more about the subprojects.

Post by Russel Winder
With all the changes around the Groovy project, projects such as GPars
and Spock need to plan their future. Spock is SEP, hopefully the Spock
GPars was a separate project so as to have an independent development
cycle. Also Groovy was monolithic at the time, and GPars needed to have
a separate existence so as to be usable with Java.
GPars can remain a separate project but some futures of Groovy may
impact massively wrt Groovy distributions.
Groovy is now modularized and it would be possible for GPars to be a
module in the Groovy codebase.
Given the state of Groovy, GPars, etc. I wonder if merging GPars into
Groovy as a module might be for the best of both GPars and Groovy.
--
Russel.

=============================================================================

Post by Russel Winder
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Thibault Kruse]

On Thu, Feb 19, 2015 at 9:32 PM, Guillaume Laforge

Post by Guillaume Laforge
So far we haven't removed any of our modules, but it's an interesting
question.
There are obviously things that are probably not used very much, but the
problem is that we actually don't / can't know the usage of the modules.
We might think one module is not important and barely used, and then get
tons of requests after removing it by people angry at us for doing so :-)

That would be something to do when incrementing the major version
number. And as long as the modules still exist, but must be added as
explicit dependencies, I do not think people would be too angry about
that.

Post by Guillaume Laforge
Of the ones you listed, I'd actually keep them all... except bsf, which is
probably the least used of them all.
But SQL, Swing, Ant, are still used, we often see requests about them.

Of course they are still used. That however could also even more mean
that those projects could well be viable on their own, maintained by
people who work with those on a daily basis, rather than by the core
groovy developers.

As another reference, I believe neither python nor ruby offer SQL
support as standard libraries.
Same for libraries to create desktop UIs (Swing-like). Java is a bit
an exception in offering swing, and somehow I do not see that as a
great benefit of Java.

Also consider Scala:
https://typesafe.com/blog/scala-211-has-arrived
"We moved a fifth (of the bytecode) of the core Scala library to
separate modules. We hope this will foster diversity in the Scala
eco-system and speed up evolution of these modules, while stabilizing
Scala's core. [...] If your project was using functionality that moved
to a module (xml, parser-combinators, swing, continuations), here's
how to update your build (sbt/maven)."

They even kicked xml out, which I consider a bold move for a
programming language, but maybe they had good reasons (such as relying
on Java).

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Guillaume Laforge]

Also, something I should have perhaps stressed: all those things are
actually modules.
It's only when you download the full distribution that you get those
modules, or if you use the groovy-all JAR.
With Groovy's 2+ modularity, you can already just pick up what's useful for
you and your projects, and even more so since the core JAR now contains its
own jarjar'ed versions of ASM and Antlr, it's easier than ever to just use
what's needed.

Guillaume

Post by Thibault Kruse
On Thu, Feb 19, 2015 at 9:32 PM, Guillaume Laforge

Post by Guillaume Laforge
So far we haven't removed any of our modules, but it's an interesting
question.
There are obviously things that are probably not used very much, but the
problem is that we actually don't / can't know the usage of the modules.
We might think one module is not important and barely used, and then get
tons of requests after removing it by people angry at us for doing so :-)

That would be something to do when incrementing the major version
number. And as long as the modules still exist, but must be added as
explicit dependencies, I do not think people would be too angry about
that.

Post by Guillaume Laforge
Of the ones you listed, I'd actually keep them all... except bsf, which

is

Post by Guillaume Laforge
probably the least used of them all.
But SQL, Swing, Ant, are still used, we often see requests about them.

Of course they are still used. That however could also even more mean
that those projects could well be viable on their own, maintained by
people who work with those on a daily basis, rather than by the core
groovy developers.
As another reference, I believe neither python nor ruby offer SQL
support as standard libraries.
Same for libraries to create desktop UIs (Swing-like). Java is a bit
an exception in offering swing, and somehow I do not see that as a
great benefit of Java.
https://typesafe.com/blog/scala-211-has-arrived
"We moved a fifth (of the bytecode) of the core Scala library to
separate modules. We hope this will foster diversity in the Scala
eco-system and speed up evolution of these modules, while stabilizing
Scala's core. [...] If your project was using functionality that moved
to a module (xml, parser-combinators, swing, continuations), here's
how to update your build (sbt/maven)."
They even kicked xml out, which I consider a bold move for a
programming language, but maybe they had good reasons (such as relying
on Java).
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Dinko Srkoč]

Post by Thibault Kruse
On Thu, Feb 19, 2015 at 9:32 PM, Guillaume Laforge
[...]
As another reference, I believe neither python nor ruby offer SQL
support as standard libraries.
Same for libraries to create desktop UIs (Swing-like). Java is a bit
an exception in offering swing, and somehow I do not see that as a
great benefit of Java.

I would guess that .NET offers both SQL and UI libraries as part of
their standard offering.
(I don't really use .NET so somebody correct me if I'm wrong)

Post by Thibault Kruse
https://typesafe.com/blog/scala-211-has-arrived
"We moved a fifth (of the bytecode) of the core Scala library to
separate modules. We hope this will foster diversity in the Scala
eco-system and speed up evolution of these modules, while stabilizing
Scala's core. [...] If your project was using functionality that moved
to a module (xml, parser-combinators, swing, continuations), here's
how to update your build (sbt/maven)."
They even kicked xml out, which I consider a bold move for a
programming language, but maybe they had good reasons (such as relying
on Java).

I believe nobody in the community really liked xml as it was
implemented, and being part of the language is, in hindsight,
considered a mistake. There are now several Scala xml libraries out
there.

I also think that one of the reasons that some of those (sub)projects
were pulled out into modules was that they suffered from the lack of
maintainers, and the move was an attempt to give the community the
chance to take over (or participate more in) the maintenance.

Lastly, as Guillaume said, it is quite easy to pick only the needed
modules into one's own Groovy project. I would say that the only
difference between Scala and Groovy from the user's point is that
Scala doesn't have scala-all.

Cheers,
Dinko

Post by Thibault Kruse
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Russel Winder]

On Fri, 2015-02-20 at 13:58 +0100, Thibault Kruse wrote:
[
]

Post by Thibault Kruse
As another reference, I believe neither python nor ruby offer SQL
support as standard libraries.

SQLite support comes as standard in Python distributions. SQLAlchemy,
the de facto standard Python SQL framework is easily installed from
PyPI. I tried to get people interested in a Groovy equivalent of
SQLAlchemy but no-one seemed interested and I don't use SQL.
[
]

[Cédric Champeau]

It is an interesting problem and I would tend to follow the opinion of
Thibaut for GPars (not necessarily the same for SQL or Swing which are
widely used).
For me there are two problems:

- is the release cycle of GPars tied to the release cycle of
Groovy? So far it hasn't been the case. If it becomes a module, then new
releases of GPars would have to wait new releases of Groovy, and new
releases of Groovy would imply new releases of GPars. I am not even
speaking of version numbers here...
- backwards compatibility and JDK compatibility: Since 2.3 Groovy
is compatible with JDK6+, but some modules require JDK 7+. We also
though of a module for JDK 8 for example. For GPars it seems that the
project itself supports multiple versions of the JDK, but in different
branches. It seems fine to me if GPars is an independent project but it
will become more complicated if it is merged in the Groovy repo (more
complicated but not impossible, basically feature branches).

So I would lean towards keeping GPars separate. IMHO there's no hurry in
migrating GPars/Spock/Geb/... to a foundation. If we were building the
Groovy Foundation with the idea of supporting Groovy related projects,
it would make sense, but here it's more about securing the future of a
language. I don't see why this would imply merging well known third
party modules into the repo just to benefit from a foundation.

Post by Russel Winder
With all the changes around the Groovy project, projects such as GPars
and Spock need to plan their future. Spock is SEP, hopefully the Spock
GPars was a separate project so as to have an independent development
cycle. Also Groovy was monolithic at the time, and GPars needed to have
a separate existence so as to be usable with Java.
GPars can remain a separate project but some futures of Groovy may
impact massively wrt Groovy distributions.
Groovy is now modularized and it would be possible for GPars to be a
module in the Groovy codebase.
Given the state of Groovy, GPars, etc. I wonder if merging GPars into
Groovy as a module might be for the best of both GPars and Groovy.

--
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Post by Cédric Champeau
It is an interesting problem and I would tend to follow the opinion of
Thibaut for GPars (not necessarily the same for SQL or Swing which are
widely used).
- is the release cycle of GPars tied to the release cycle of
Groovy? So far it hasn't been the case. If it becomes a module, then new
releases of GPars would have to wait new releases of Groovy, and new
releases of Groovy would imply new releases of GPars. I am not even
speaking of version numbers here...
- backwards compatibility and JDK compatibility: Since 2.3 Groovy
is compatible with JDK6+, but some modules require JDK 7+. We also
though of a module for JDK 8 for example. For GPars it seems that the
project itself supports multiple versions of the JDK, but in different
branches. It seems fine to me if GPars is an independent project but it
will become more complicated if it is merged in the Groovy repo (more
complicated but not impossible, basically feature branches).

hmm... assuming we go to apache or eclipse, wouldn't it make sense to
have those as sub projects? Then they have their own repo, their own
release cycle and all that, but we could still easily help each other

bye Jochen
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[jim northrop]

do you have any opinions on what to do with gaelyk ?

Post by Cédric Champeau
It is an interesting problem and I would tend to follow the opinion of
Thibaut for GPars (not necessarily the same for SQL or Swing which are
widely used).
- is the release cycle of GPars tied to the release cycle of Groovy?
So far it hasn't been the case. If it becomes a module, then new releases
of GPars would have to wait new releases of Groovy, and new releases of
Groovy would imply new releases of GPars. I am not even speaking of version
numbers here...
- backwards compatibility and JDK compatibility: Since 2.3 Groovy is
compatible with JDK6+, but some modules require JDK 7+. We also though of a
module for JDK 8 for example. For GPars it seems that the project itself
supports multiple versions of the JDK, but in different branches. It seems
fine to me if GPars is an independent project but it will become more
complicated if it is merged in the Groovy repo (more complicated but not
impossible, basically feature branches).
So I would lean towards keeping GPars separate. IMHO there's no hurry in
migrating GPars/Spock/Geb/... to a foundation. If we were building the
Groovy Foundation with the idea of supporting Groovy related projects, it
would make sense, but here it's more about securing the future of a
language. I don't see why this would imply merging well known third party
modules into the repo just to benefit from a foundation.

Post by Russel Winder
With all the changes around the Groovy project, projects such as GPars
and Spock need to plan their future. Spock is SEP, hopefully the Spock
GPars was a separate project so as to have an independent development
cycle. Also Groovy was monolithic at the time, and GPars needed to have
a separate existence so as to be usable with Java.
GPars can remain a separate project but some futures of Groovy may
impact massively wrt Groovy distributions.
Groovy is now modularized and it would be possible for GPars to be a
module in the Groovy codebase.
Given the state of Groovy, GPars, etc. I wonder if merging GPars into
Groovy as a module might be for the best of both GPars and Groovy.

--
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Guillaume Laforge]

Gaelyk continues to live on its own.

On Fri, Feb 20, 2015 at 7:06 PM, jim northrop <

Post by jim northrop
do you have any opinions on what to do with gaelyk ?

Post by Cédric Champeau
It is an interesting problem and I would tend to follow the opinion of
Thibaut for GPars (not necessarily the same for SQL or Swing which are
widely used).
- is the release cycle of GPars tied to the release cycle of Groovy?
So far it hasn't been the case. If it becomes a module, then new releases
of GPars would have to wait new releases of Groovy, and new releases of
Groovy would imply new releases of GPars. I am not even speaking of version
numbers here...
- backwards compatibility and JDK compatibility: Since 2.3 Groovy is
compatible with JDK6+, but some modules require JDK 7+. We also though of a
module for JDK 8 for example. For GPars it seems that the project itself
supports multiple versions of the JDK, but in different branches. It seems
fine to me if GPars is an independent project but it will become more
complicated if it is merged in the Groovy repo (more complicated but not
impossible, basically feature branches).
So I would lean towards keeping GPars separate. IMHO there's no hurry in
migrating GPars/Spock/Geb/... to a foundation. If we were building the
Groovy Foundation with the idea of supporting Groovy related projects, it
would make sense, but here it's more about securing the future of a
language. I don't see why this would imply merging well known third party
modules into the repo just to benefit from a foundation.

Post by Russel Winder
With all the changes around the Groovy project, projects such as GPars
and Spock need to plan their future. Spock is SEP, hopefully the Spock
GPars was a separate project so as to have an independent development
cycle. Also Groovy was monolithic at the time, and GPars needed to have
a separate existence so as to be usable with Java.
GPars can remain a separate project but some futures of Groovy may
impact massively wrt Groovy distributions.
Groovy is now modularized and it would be possible for GPars to be a
module in the Groovy codebase.
Given the state of Groovy, GPars, etc. I wonder if merging GPars into
Groovy as a module might be for the best of both GPars and Groovy.

--
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[jim northrop]

high guys -
you may/maynot be interested in this meetup in paris, but FYI :
https://www.weezevent.com/1st-meeting-stackato-cloudfoundry-introduction-usage

thx
jim

Post by Guillaume Laforge
Gaelyk continues to live on its own.
On Fri, Feb 20, 2015 at 7:06 PM, jim northrop <

Post by jim northrop
do you have any opinions on what to do with gaelyk ?

Post by Cédric Champeau
It is an interesting problem and I would tend to follow the opinion of
Thibaut for GPars (not necessarily the same for SQL or Swing which are
widely used).
- is the release cycle of GPars tied to the release cycle of Groovy?
So far it hasn't been the case. If it becomes a module, then new releases
of GPars would have to wait new releases of Groovy, and new releases of
Groovy would imply new releases of GPars. I am not even speaking of version
numbers here...
- backwards compatibility and JDK compatibility: Since 2.3 Groovy is
compatible with JDK6+, but some modules require JDK 7+. We also though of a
module for JDK 8 for example. For GPars it seems that the project itself
supports multiple versions of the JDK, but in different branches. It seems
fine to me if GPars is an independent project but it will become more
complicated if it is merged in the Groovy repo (more complicated but not
impossible, basically feature branches).
So I would lean towards keeping GPars separate. IMHO there's no hurry in
migrating GPars/Spock/Geb/... to a foundation. If we were building the
Groovy Foundation with the idea of supporting Groovy related projects, it
would make sense, but here it's more about securing the future of a
language. I don't see why this would imply merging well known third party
modules into the repo just to benefit from a foundation.

Post by Russel Winder
With all the changes around the Groovy project, projects such as GPars
and Spock need to plan their future. Spock is SEP, hopefully the Spock
GPars was a separate project so as to have an independent development
cycle. Also Groovy was monolithic at the time, and GPars needed to have
a separate existence so as to be usable with Java.
GPars can remain a separate project but some futures of Groovy may
impact massively wrt Groovy distributions.
Groovy is now modularized and it would be possible for GPars to be a
module in the Groovy codebase.
Given the state of Groovy, GPars, etc. I wonder if merging GPars into
Groovy as a module might be for the best of both GPars and Groovy.

--
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
Guillaume Laforge
Groovy Project Manager
Pivotal, Inc.
Blog: http://glaforge.appspot.com/
<https://plus.google.com/u/0/114130972232398734985/posts>