I would have appreciated that feedback earlier when we asked for it, and that was precisely why I was reluctant on starting a release before we addressed all of those issues. Our build always produces those artifacts so it was easy to check. The fact of having to do a time consuming release to check for it is already too late and wasting our time, I must say I'm a bit frustrated. Should I cancel the vote?
2015-06-08 9:28 GMT+02:00 Emmanuel Lécharny <[email protected]>: > Le 08/06/15 08:51, Roman Shaposhnik a écrit : > > Let me answer one thing that is currently preventing > > me from +1ing this release. I'll address the rest > > in the morning. > > > > On Sun, Jun 7, 2015 at 11:26 PM, Cédric Champeau > > <[email protected]> wrote: > >>> 3. The wording around licensing on > >>> buildSrc/src/main/java/JavadocFixTool.java > >>> makes me worried. Has the licensing implications of this > >>> file every been discussed. > >> > >> I don't think so. A fix like this has to be applied on *all* > documentation > >> that is generated on older JVM releases (Jdk 6 and first releases of > JDK 7). > >> We systematically apply it because we build on multple JDKs, so we > cannot > >> guarantee that the generated Javadoc is not vulnerable. Any project that > >> doesn't do this has a serious problem. This is funny because I was > actually > >> the first one to turn this into a plugin for Gradle, before Ant or > Maven did > >> it, but our build doesn't use it. That said, if we use a plugin, we just > >> hide the fact we're using such a tool :) > > We need to raise this on general@ ASAP then. The problem is not that > > we're using it during the build, but that we're distributing it in the > release > > tarball that needs to be ALv2 compatible. My understanding that it > > currently isn't. > > LEGAL-171 already discussed this issue. I would suggest that Groovy use > one of the existing workaround. > >
