I'm also +1 for cutting a new RC2 release for a new round of votes. David
On Fri, Oct 23, 2015 at 10:33 AM, Vlad Rozov <[email protected]> wrote: > +1 to cut new RC2 and submit it for voting. > > Thank you, > > Vlad > > > On 10/23/15 10:24, Thomas Weise wrote: > >> We have -0 votes. I would propose rolling RC2 and starting a new vote. How >> do others feel about it? >> >> The changes to address issues raised are committed and we are ready to do >> so. >> >> https://github.com/apache/incubator-apex-core/commits/release-3.2 >> >> Thanks, >> Thomas >> >> On Thu, Oct 22, 2015 at 11:08 PM, Thomas Weise <[email protected]> >> wrote: >> >> Hi Justin, >>> >>> I also found a way to avoid DEPENDENCIES being added to the source >>> archive. >>> >>> Should we roll another RC and call a new vote? >>> >>> Thanks, >>> Thomas >>> >>> >>> On Thu, Oct 22, 2015 at 10:44 PM, Vlad Rozov <[email protected]> >>> wrote: >>> >>> Hi Justin, >>>> >>>> NOTICE files are automatically generated by Apache Maven remote resource >>>> plugin included and configured in the Apache parent pom. The >>>> configuration >>>> of the plugin points to org.apache:apache-jar-resource-bundle:1.4 that >>>> has >>>> a known enhancement request (please see >>>> https://issues.apache.org/jira/browse/MASFRES-5). The same enhancement >>>> request suggest a workaround that we implemented to bring NOTICE files >>>> in >>>> sync. >>>> >>>> Thank you, >>>> >>>> Vlad >>>> >>>> >>>> On 10/22/15 21:45, Justin Mclean wrote: >>>> >>>> Hi, >>>>> >>>>> The NOTICE files are added to the .jar files by a plugin that is setup >>>>> in >>>>> >>>>>> the Apache POM. >>>>>> >>>>>> It should be possible to get it to use our NOTICE file. Sorry I don’t >>>>> know enough about how that all works to be able to suggest how to do >>>>> that. >>>>> Perhaps another mentor does? >>>>> >>>>> I see examples of not matching the top level NOTICE elsewhere where >>>>> this >>>>> >>>>>> POM is used. >>>>>> >>>>>> In projects that produce multiple jars the notice in each jar may be >>>>> different, as it depends on the jars contents, so it could be that you >>>>> are >>>>> seeing. Read the guiding priniciple [1] and note that it applies to >>>>> binaries as well [2]. At some point I assume you may want to ship a >>>>> convenience binary to users? >>>>> >>>>> I also see other releases with .jar artifacts that have no NOTICE file >>>>> >>>>>> in it. >>>>>> >>>>>> That’s not in line with current Apache policy. See [3]. >>>>> "Again, these artifacts may be distributed only if they contain LICENSE >>>>> and NOTICE files. For example, the Java artifact format is based on a >>>>> compressed directory structure and those projects wishing to distribute >>>>> jars must place LICENSE and NOTICE files in the META-INF directory >>>>> within >>>>> the jar." >>>>> >>>>> You might want to look at similar JIRA issues here [4] and in >>>>> particular >>>>> this one: >>>>> https://issues.apache.org/jira/browse/LEGAL-178 >>>>> >>>>> BTW as long as you raise a JIRA about this I don't think this need to >>>>> be >>>>> fixed right away and can wait for a future incubating release. I >>>>> wouldn’t >>>>> expect any IPMC member to consider this a blocking issue for a first >>>>> release. (And if they do point them to the JIRA). >>>>> >>>>> What is your recommendation, same NOTICE file in all .jar artifacts or >>>>> >>>>>> generated NOTICE file with (changed) name of module? >>>>>> >>>>>> It depends on the contents of each jar, again see 1 and 2. In Apex >>>>> case >>>>> it may be that they are all the same, I’d need to take a close look at >>>>> the >>>>> jar’s contents to determine. >>>>> >>>>> Thanks, >>>>> Justin >>>>> >>>>> 1. http://www.apache.org/dev/licensing-howto.html#guiding-principle >>>>> 2. http://www.apache.org/dev/licensing-howto.html#binary >>>>> 3. http://www.apache.org/dev/release.html#distribute-other-artifacts >>>>> 4. >>>>> >>>>> https://issues.apache.org/jira/browse/TAVERNA-864?jql=text%20~%20%22META-INF%20NOTICE%22 >>>>> >>>>> >>>> >
