Paul, while the custom wrapper is a completely valid concern, the same version of it has hold well since Gradle 1.8 IIRC. So, the overhead is pretty small. -- Regards, Cos
On November 14, 2017 7:29:36 AM GMT+03:00, Paul King <[email protected]> wrote: >I tweaked the build files and README so that the bootstrapping >instructions >now read: > >gradle -b wrapper.gradle wrapper > >Since that file has no plugins, it should hopefully make us much more >Gradle version resilient. > >It doesn't mean we might not want to consider Cos' proposal since (at >the >expense of having to keep updating the custom wrapper) it would >eliminate >the need to have gradle installed for bootstrapping. > >Also, it doesn't stop us from continuing to ask for permission to >include >the wrapper so that builders from source aren't second class citizens - >needing the extra download. Perhaps that should be a section in our >next >board report? > >Anyway, we should get those changes for the next prepared releases. > >Cheers, Paul. > > >On Tue, Nov 14, 2017 at 4:18 AM, Konstantin Boudnik <[email protected]> >wrote: > >> Current release includes a binary file (gradle/wrapper/*jar), which >> isn't compatible with Apache release policy (ie source-only >releases). >> In all honestly, this isn't the first release with the same issue. I >> was talking about it for too long and I am sorry I didn't address >this >> issue earlier. >> >> Here's https://issues.apache.org/jira/browse/GROOVY-8378 that has the >> patch for the issue. I don't think we should block this release, but >> let's make backport it into the next one, if there's no objections. >> >> Incidentally, I can't assign the ticket to myself for whatever >reason. >> But the patch is there ;) Thanks! >> -- >> With regards, >> Konstantin (Cos) Boudnik >> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622 >> >> Disclaimer: Opinions expressed in this email are those of the author, >> and do not necessarily represent the views of any company the author >> might be affiliated with at the moment of writing. >> >> >> On Mon, Nov 13, 2017 at 5:40 PM, Cédric Champeau >> <[email protected]> wrote: >> > This will not always be possible. The source zip will live for >years. You >> > can only do this at release time, and there's nothing that >guarantees >> that >> > all plugins will all be compatible with the latest version of >Gradle at >> the >> > moment you release for a branch that uses an old version. It's just >a >> > miracle it works. Instead, let's make our point to the foundation: >the >> > wrapper MUST be endorsed. >> > >> > 2017-11-13 15:38 GMT+01:00 Guillaume Laforge <[email protected]>: >> >> >> >> I'm voting +1 >> >> >> >> But let's get sure we can build from source the next time when >someone >> has >> >> a recent version of Gradle installed locally. >> >> At the very minimum, we should indicate in the README that we have >to >> use >> >> some range of Gradle version for generating the wrapper in the >first >> place. >> >> >> >> On Mon, Nov 13, 2017 at 2:53 PM, Daniel.Sun <[email protected]> >wrote: >> >>> >> >>> Hi Guillaume, >> >>> >> >>> I've understood what you mean :-) >> >>> >> >>> As to the version of plugin, we can not satisfy everyone >because >> >>> gradle 3+ and gradle 4+ requires different versions of plugin. So >I >> >>> sugguest >> >>> we should clarify the requirement of gradle version, which must >be >> 3.5.1 >> >>> to >> >>> generate the wrapper and build Apache Groovy from source. >> >>> >> >>> At last, I want to know, your vote is ? ;-) >> >>> >> >>> >> >>> Cheers, >> >>> Daniel.Sun >> >>> >> >>> >> >>> >> >>> -- >> >>> Sent from: >http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >> >> >> >> >> >> >> >> >> >> -- >> >> Guillaume Laforge >> >> Apache Groovy committer & PMC Vice-President >> >> Developer Advocate @ Google Cloud Platform >> >> >> >> Blog: http://glaforge.appspot.com/ >> >> Social: @glaforge / Google+ >> > >> > >>
