You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Paul King <pa...@asert.com.au> on 2018/08/01 05:07:54 UTC

Re: Licence statements

Apologies for not answering earlier. I was travelling.

We bundle GPars and its transitive dependencies (including the jsr166y.jar)
in our install for Groovy. As per normal Apache guidelines we make the
licensing of anything we use/include crystal clear.

I guess in the JDK9+ world we should consider whether we want to still
include that dependency but perhaps we should put some further thinking
into GPars 2 and can then decide.

Cheers, Paul.



On Thu, Jul 26, 2018 at 5:35 PM Russel Winder <ru...@winder.org.uk> wrote:

> I am wondering why there are all the licences for other products in the
> licenses directory of the Groovy Git repository.
>
> In particular as an example, why do we have jsr166y-BINZIP.txt and
> jsr166y-license.txt in this directory?
>
> --
> Russel.
> ===========================================
> Dr Russel Winder      t: +44 20 7585 2200
> 41 Buckmaster Road    m: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>

Re: Licence statements

Posted by Russel Winder <ru...@winder.org.uk>.
On Wed, 2018-08-01 at 20:29 +1000, Paul King wrote:
> Yes, Groovy 2.5.X has JDK7 as minimum and Groovy 3 has JDK8. From your
> description, it seems like both don't need jsr116y. I'll refresh my memory
> and run some tests and get rid of it assuming all goes to plan.

That would be the right route I think. Try removing jsr166y.jar as a
dependency run the tests, and I hope nothing breaks.

> For GPars 2, it will be interesting to see whether we can have gpars-core,
> gpars-asynch, gpars-dataflow, etc. modules or whether one fat module will
> make sense.

I am not sure about this, but that is because I haven't thought about it, not
because I think it is necessarily a bad idea. In the post JDK8 world, the data
parallel stuff in GPars is somewhat less important because of Stream. GPars
actors, active objects, daflow, and CSP are the main features and I wonder if
they should just be bundled together. Separating them means people have to do
more configuration, is that a barrier too far for what, after all seems to be
a not used library.

The total lack of interest in the published GPars being so old, and progress
on GPars 2 being so slow is a real turn off to putting in any effort on this. 

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

Re: Licence statements

Posted by Paul King <pa...@asert.com.au>.
Yes, Groovy 2.5.X has JDK7 as minimum and Groovy 3 has JDK8. From your
description, it seems like both don't need jsr116y. I'll refresh my memory
and run some tests and get rid of it assuming all goes to plan.

For GPars 2, it will be interesting to see whether we can have gpars-core,
gpars-asynch, gpars-dataflow, etc. modules or whether one fat module will
make sense.

Cheers, Paul.


On Wed, Aug 1, 2018 at 7:45 PM Russel Winder <ru...@winder.org.uk> wrote:

> On Wed, 2018-08-01 at 15:07 +1000, Paul King wrote:
> > Apologies for not answering earlier. I was travelling.
>
> No problem, travel has a higher priority. :-)
>
> > We bundle GPars and its transitive dependencies (including the
> jsr166y.jar)
> > in our install for Groovy. As per normal Apache guidelines we make the
> > licensing of anything we use/include crystal clear.
>
> OK, understood.
>
> The question is then whether jsr166y.jar should be distributed at all. As
> far
> as I remember jsr166y.jar is the bits of JDK 7 that are needed when
> running on
> JDK 6. If the minimum JDK version for Groovy is JDK7 then I believe
> jsr166y.jar is not needed.
>
> extra166y.jar is needed for GPars 1.X,but we had to make a few amendments
> and
> so took in internal fork into the GPars 1.X distribution. This means
> extra166y.jar is definitely not a dependency.
>
> > I guess in the JDK9+ world we should consider whether we want to still
> > include that dependency but perhaps we should put some further thinking
> > into GPars 2 and can then decide.
>
> I am assuming Groovy will treat JDK8 (despite it being a dead version of
> JDK
> :-) ) as it's base for now, or is there an intention to go to JDK9 (even
> though it is on it's last legs :-) )?
>
> In any event jsr166y.jar is an irrelevance and can be removed as a
> dependency.
>
> I guess if JDK9 is in play then GPars 2.0 ought to get packaged as a
> module.
>
> The extra166y fork is removed from GPars 2 because it is assumed things are
> running on at least JDK8.
>
> --
> Russel.
> ===========================================
> Dr Russel Winder      t: +44 20 7585 2200
> 41 Buckmaster Road    m: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>

Re: Licence statements

Posted by Russel Winder <ru...@winder.org.uk>.
On Wed, 2018-08-01 at 15:07 +1000, Paul King wrote:
> Apologies for not answering earlier. I was travelling.

No problem, travel has a higher priority. :-)

> We bundle GPars and its transitive dependencies (including the jsr166y.jar)
> in our install for Groovy. As per normal Apache guidelines we make the
> licensing of anything we use/include crystal clear.

OK, understood. 

The question is then whether jsr166y.jar should be distributed at all. As far
as I remember jsr166y.jar is the bits of JDK 7 that are needed when running on
JDK 6. If the minimum JDK version for Groovy is JDK7 then I believe
jsr166y.jar is not needed.

extra166y.jar is needed for GPars 1.X,but we had to make a few amendments and
so took in internal fork into the GPars 1.X distribution. This means
extra166y.jar is definitely not a dependency. 

> I guess in the JDK9+ world we should consider whether we want to still
> include that dependency but perhaps we should put some further thinking
> into GPars 2 and can then decide.

I am assuming Groovy will treat JDK8 (despite it being a dead version of JDK
:-) ) as it's base for now, or is there an intention to go to JDK9 (even
though it is on it's last legs :-) )?

In any event jsr166y.jar is an irrelevance and can be removed as a dependency.

I guess if JDK9 is in play then GPars 2.0 ought to get packaged as a module.

The extra166y fork is removed from GPars 2 because it is assumed things are
running on at least JDK8.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk