Licence statements

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Licence statements

Russel Winder-3
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Licence statements

paulk_asert
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Licence statements

Russel Winder-3
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Licence statements

paulk_asert

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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Licence statements

Russel Winder-3
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

signature.asc (849 bytes) Download Attachment