So now the files in the maven-wrapper have all the correct headers? So all I need to do is replace the versions in the Apache repos with that version and add something to the Notice and/or license and we're all good?
I knew that binary files can't be checked in, therefore I wrote that pr that eliminates the need of binary files. So what would be the set of steps be to be correct and nice? Would rather do that than discuss in lengthy threads how to avoid that. Chris Outlook für Android<https://aka.ms/ghei36> herunterladen ________________________________ From: Paul King <pa...@asert.com.au> Sent: Tuesday, February 19, 2019 4:38:16 AM To: general@incubator.apache.org Subject: Re: the case of the maven wrapper For anyone who is interested from the Gradle side of things, you can look at what we do for the Groovy project. We do include the (Gradle) wrapper files in our git repo but NOT in our source distribution zip. There is one extra step in our build process/line in our README that explains how to populate the correct wrapper files using an existing gradle install and after which the wrapper can then be used. I don't know if something similar is currently possible with the Maven wrapper. Great if so, but if not, it might prove to be a useful direction to head. Cheers, Paul. On Tue, Feb 19, 2019 at 10:54 AM Adrian Cole <adrian.f.c...@gmail.com> wrote: > The request to donate the wrapper was closed won't fix (they did > adjust the license headers) > > I've made a comment on a 3+ year old issue on maven itself, which had > excluded the wrapper due to perceived problems in performing change > inside the ASF > > > https://issues.apache.org/jira/browse/MNG-5937?focusedCommentId=16771456&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771456 > > On Thu, Feb 14, 2019 at 4:18 PM Adrian Cole <adrian.f.c...@gmail.com> > wrote: > > > > FYI I've asked takari to donate the wrapper to the ASF. It is > > important but tiny > > https://github.com/takari/takari-maven-plugin/issues/18 > > > > Meanwhile, we will remove the wrapper from the source distribution as > > putting it in the NOTICE file is something off-putting to a few of our > > contributors. We can build without the wrapper and it isn't worth > > making a commitment to the NOTICE file for what seems not thought > > through. > > > > If the enforcement rules loosen back to where we don't need to do > > this, or the plugin or a copy of it is donated to the ASF, we'll > > likely put it back into the source distribution. > > > > On Thu, Feb 14, 2019 at 3:29 PM Justin Mclean <jus...@classsoftware.com> > wrote: > > > > > > Hi, > > > > > > > If we all say fine.. let's just throw more paperwork at it, I would > ask you > > > > to help draft a line for the NOTICE of what we would do. suppose we > would > > > > also have to do this for gradle etc. > > > > > > You would need to do this for any 3rd party file bundled with a > release and yes sometimes this is complex and takes time. See for example > Apache Newt. [1] > > > > > > > So basically if we accept that the new norm is this level of detail > on > > > > incidental files, > > > > > > It’s a 3rd party file not an incidental file and the ASF has policy > around what to do when including 3rd party files which a (P)PMC and > releases need to comply with. [2][3] > > > > > > To comply however is a simple change that needs to be made once to > clearly inculcate the IP province and license of that file to users of the > projects. > > > > > > > would it be "this includes source generated by the takari maven > plugin"? > > > > and of course if we say this, the next cruft is explaining gradle > etc. > > > > > > If you don’t know what to do ask you mentors or the IPMC for help. If > you disagree with advice given then clarify on legal-discuss. > > > > > > Thanks, > > > Justin > > > > > > 1. https://github.com/apache/mynewt-newt/blob/master/LICENSE > > > 2. http://www.apache.org/dev/release-publishing.html#goal > > > 3. http://www.apache.org/dev/release-publishing.html#valid > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >