groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cedric.champ...@gmail.com>
Subject Re: [mentors] experimental graduation maturity assessment in view of graduating Groovy
Date Fri, 16 Oct 2015 14:52:39 GMT
Yes, Emmanuel. And that's exactly what assemble.gradle enforces.

2015-10-16 16:51 GMT+02:00 Emmanuel Lécharny <elecharny@gmail.com>:

> Le 16/10/15 16:43, Paul King a écrit :
> > On Sat, Oct 17, 2015 at 12:38 AM, Cédric Champeau
> > <cedric.champeau@gmail.com> wrote:
> >> Such a list was written for the proposal:
> >> https://wiki.apache.org/incubator/GroovyProposal
> >>
> >> Since then we have made a great effort towards generating different
> LICENSE
> >> files depending on the artifacts we produce. Everything can be found in
> the
> >> license directory:
> >> https://github.com/apache/incubator-groovy/tree/master/licenses
> >>
> >> And assembling the licenses depending on the artifacts is done here:
> >>
> https://github.com/apache/incubator-groovy/blob/master/gradle/assemble.gradle
> >>
> >> I am kind of reluctant to write the list explicitly where we have tools
> to
> >> check everything (Rat plugin, license report): the list could become
> >> obsolete very easily without us noticing.
> > Agreed. Our source dependency license/notice info is already in the
> > source release. Our runtime dependency license/notice info is already
> > in the respective jars/zips. RAT does a check on our source files. And
> > now the gradle license report plugin does a cross-check on what we
> > already know from the license files. I believe we are well and truly
> > covered.
>
> To be clear :
> - the source packages must contain the N&L files listing all the
> contained depeencies (and teh required N&L for those dependencies-
> - the binary packages that are distributed must also contain the same
> things
> - the dependencies used to build Groovy are not part of what must be
> listed (although it might be cool to do so), unless they generates some
> code or documentation (typically what antlr does)
>
> The rational being that anyone who want to download, and embed groovy in
> their own product must be aware of those dependencies. If some of them
> are optional, then it should be clearly stated somewhere (and solhere
> means N&L).
>
> Keep in mind that many companies are very picky about those things.
>
> Anyway, I think it's already correctly covered, as of today.
>
> Thanks!
>
>

Mime
View raw message