Longer term solution would be to split the project into multiple modules (that make logical sense) and the benchmarks (along with JMH) would be a module of its own (and not be packaged into the final artifacts distribution).
I do think that as and when we add Storm, Flink, Spark and other backend Responders, it would make more sense to create separate jar artifacts for each of them to be individually published to maven. Does it make sense to split Responder and Querier into separate modules and publish them to maven as individual jars ? Would there be a Use Case wherein I just need to plugin pirk-responder-spark as a dependency in my project (and not having to deal with rest of Pirk artifacts). The project distribution tar ball would have all of the core Pirk, responder (with diff backends), querier etc... (but not benchmarks). We don't have to do all of this for this release, but something we should prioritize for the next one. On Mon, Aug 15, 2016 at 9:48 AM, Ellison Anne Williams < [email protected]> wrote: > Tim - thanks for going down into the jars and checking the licenses and > notices - I assumed that they would be the same as what our source code > contained - clearly, I was wrong. > > I would like to go ahead and address the issue so that our next release is > smooth and all of the steps for a successful release are established and > documented. > > Looks like we have issues in apache-pirk-0.1.0-incubating-exe.jar and > apache-pirk-0.1.0-incubating-sources.jar > > 1.) apache-pirk-0.1.0-incubating-exe.jar > > No matter what I did on my machine, I was not able to extract > > /META-INF/license/* > licenses for a variety of dependencies, including > LICENSE.jboss-logging.txt -> LGPLv2 > > from apache-pirk-0.1.0-incubating-exe.jar. Thus, I can't look at the > specific problem. > > I can't see where jboss-logging is being pulled into the codebase (can't > find the dependency). I am assuming that it must be pulling it in somewhere > in order to add the corresponding license file. Any thoughts on this one? > Not sure myself either, this could be coming from a dependency -> dependency -> .... > > 2.) apache-pirk-0.1.0-incubating-sources.jar > > Not sure why the org.openjdk.jmh.infra.generated.* files are appearing. > They are under the openjdk license, GPL v2, which is not allowed by Apache. > The org.openjdk.jmh is marked as a 'provided' dependency in the pom (recall > that there was a thread on what to do with this and the conclusion was to > leave it in as provided as do other projects). Not sure why it would be > showing up here. Should we mark it as 'runtime' instead of 'provided'? > (asking before I take the time to try it out bc folks may already know how > best to handle it). > Let's set this to 'runtime' > > 3.) LICENSE and NOTICE files - It seems that you are suggesting that we > manually append all of the dependency notices to our NOTICE file. Correct? > It also appears that we also need to do the same with the LICENSE file: > http://www.apache.org/dev/release.html#distributing-code-und > er-several-licenses We will have to fix this. > > > So, not done yet... I will rollback once we figure out what's going on (so > that folks can still access the artifacts). > > > > On Mon, Aug 15, 2016 at 8:28 AM, Suneel Marthi <[email protected]> wrote: > > > Thanks for the feedback. Tim. > > > > See my comments inline below. > > > > @Ellison lets rollback the release. > > > > > > > > On Mon, Aug 15, 2016 at 7:35 AM, Tim Ellison <[email protected]> > > wrote: > > > > > On 14/08/16 04:19, Ellison Anne Williams wrote: > > > > Hi, > > > > > > > > This is the vote for release 0.1.0 of Apache Pirk (incubating). > > > > > > > > The vote will be going for at least 72 hours and will be closed on > > > Wednesday > > > > , > > > > August 16, 2016. > > > > > > > > The artifacts can be downloaded here: https://repository.apache. > > > > org/content/repositories/orgapachepirk-1001/org/apache/ > > > > pirk/apache-pirk/0.1.0-incubating/ > > > > > > > > All JIRAs completed for this release are tagged with 'FixVersion = > > > 0.1.0'. > > > > You can view them here: https://issues.apache.org/jira > > > /browse/PIRK-47?jql= > > > > project%20%3D%20PIRK%20AND%20fixVersion%20%3D0.1.0 > > > > > > > > The artifacts have been signed with Key : 1FD8849B > > > > > > > > Please vote accordingly: > > > > > > > > [ ] +1, accept RC as the official 0.1.0 release > > > > [ ] +0, I don't care either way, > > > > [ ] -1, do not accept RC as the official 0.1.0 release because... > > > > > > > > Thanks! > > > > > > > > Ellison Anne > > > > > > > > > > Wow, you guys have had a busy weekend. > > > > > > Looking at the files in that directory... > > > > > > (1) Principal release artefact: > > > apache-pirk-0.1.0-incubating-source-release.zip > > > - sig & sums check ok. > > > - EAW's pub key is in LDAP, KEYS file, etc. > > > - build and test ok on Oracle Java 8b91, RHEL6. > > > - Notice, License files ok. > > > - RAT checks pass. > > > > > > (2) JavaDocs: > > > apache-pirk-0.1.0-incubating-javadoc.jar > > > - sig and sums check ok. > > > - Notice and Licence files ok (in META-INF/). > > > - JavaDocs render ok. > > > > > > (3) Maven pom file: > > > - sig and sums check ok. > > > - references to license and notices ok. > > > - not checked building with it, but oking > > > as minimal diff with project pom. > > > > > > (4) Dependency combined binary convenience: > > > apache-pirk-0.1.0-incubating-exe.jar > > > - sig and sums check ok. > > > - not tested > > > ** notices and license files confusion. > > > ** not passing on notices for included dependencies. > > > > > > jar contains > > > /LICENSE-junit.txt > > > JUnit license > > > /LICENSE.txt > > > BSD license (from Hamcrest) > > > /license/* > > > contains ALv2, and other license and NOTICE file for XML APIs. > > > /META-INF/LICENSE > > > ALv2 > > > /META-INF/LICENSE.txt > > > ALv2 (with reference to org.apache.commons.math3.ml.neuralnet) > > > /META-INF/license/* > > > licenses for a variety of dependencies, including > > > LICENSE.jboss-logging.txt -> LGPLv2 > > > /META-INF/NOTICE > > > Pirk (only) notice file. > > > /META-INF/NOTICE.txt > > > Commons Math notice file. > > > > > > (5) Pirk-only Source JAR > > > apache-pirk-0.1.0-incubating-sources.jar > > > - sig and sums check ok. > > > - Notice and Licence files ok (in META-INF/). > > > - Contains JMH generated source code > > > org.apache.pirk.benchmark.generated.* > > > org.openjdk.jmh.infra.generated.* > > > ** Are we clear on the license for these files? > > > ** Fails RAT checks due to unspecified licenses on these files. > > > - Not tried compiling / further testing. > > > > > > (6) Pirk-only Binary JAR > > > apache-pirk-0.1.0-incubating.jar > > > - sig and sums check ok. > > > - Notice and Licence files ok (in META-INF/). > > > - FYI contains an empty directory (/org/openjdk/). > > > - FYI contains a subset of test material. > > > - No further testing. > > > > > > > > > I have to vote -1 (binding) on these artefacts due to the issues > > > identified in (4) and possibly (5). > > > > > > Notably: > > > (i) we indicate there is LGPLv2.1 material in this release. If true > > > this is contrary to ASF's policy [1], if not then the license text > > > should be removed. > > > > > > (ii) we are not passing through the required NOTICES for Pirk's > > > dependencies as required by their terms. > > > > > > > Definitely needs to be fixed. > > > > > > > > > > Pirk's transitive JAR has deep dependencies, so if we are > redistributing > > > them we must include their notice files too. Our JAR has a number of > > > NOTICE files, but they are not comprehensive. Better to have a single > > > complete NOTICE file, e.g. [2]. > > > > > > (iii) we should clarify the licence of generated JMH files, and > exclude > > > them for the RAT check or remove them from the artefacts as required. > > > > > > > These are being excluded from generated binary jar, guess they need to be > > excluded from the sources jar too. > > > > > > > > [1] http://www.apache.org/legal/resolved.html#category-x > > > [2] https://github.com/apache/spark/blob/master/NOTICE > > > > > > > > > p.s. I appreciate that (4) is potentially a significant effort to > > > resolve, but the convenience JAR is not essential to a release, so we > > > may consider dropping that from the release artefacts this time round. > > > > > > > Agree, I guess the reason we are even creating that uber artifact could > be > > for Hadoop jobs. > > Let's drop it from this release and definitely fix it for the next. > > > > Just a thought. > > > > > > Regards, > > > Tim > > > > > >
