After spending a bit of time taking a look at the submodule breakout, I would rather wait and break the project out into submodules in a more deliberate manner (not as a first pass just for the binary artifacts).
As submodules seem to be required to get the L&N files for binary distributions up to par, I propose that we proceed with a source only release now. We will slate the submodules for our next release (or so). We've certainly learned tons about the release process over the last week and I think that it would be good to go ahead and exercise the full process to completion. Unless anyone objects, I will try to get the source release artifacts up for voting over the weekend. Thanks! On Fri, Aug 19, 2016 at 3:58 PM, Ellison Anne Williams < [email protected]> wrote: > I may give breaking the project into basic submodules a quick shot over > the weekend -- not full submodules, just an assembly and core to get past > the release and then we can design from there. If it proves too time > consuming, I think that (unfortunately) we should go with a source-only > release until we tackle submodules. > > On Fri, Aug 19, 2016 at 12:41 PM, Suneel Marthi <[email protected]> > wrote: > >> I was trying to exclude the logs/ from being packaged into the sources jar >> - and seems like the clean way to do it is via assembly. >> I don't think its very productive to throw in a hacky fix now and having >> to >> revert it again to do it the right way. >> >> I suggest that we go ahead with this release and pun the highlighted >> issues >> in the next sprint following this release. >> Suneel >> >> On Fri, Aug 19, 2016 at 11:57 AM, Ellison Anne Williams < >> [email protected]> wrote: >> >> > Exactly - which requires a submodule refactor, hence holding off... >> > >> > Any other way to satisfies the requirements that Tim mentioned in his >> last >> > email? >> > >> > On Fri, Aug 19, 2016 at 11:55 AM, Suneel Marthi < >> [email protected]> >> > wrote: >> > >> > > I have been looking at this, seems like most of this is best handled >> by >> > > maven-assembly-plugin - packaging licenses into bin.jar and src.jar in >> > the >> > > appropriate way; excluding logs/ from source jar etc.. >> > > >> > > I guess we need to mark these as JIRA issues and pun them for the >> next >> > > release. >> > > >> > > >> > > >> > > On Fri, Aug 19, 2016 at 11:48 AM, Ellison Anne Williams < >> > > [email protected]> wrote: >> > > >> > > > Understood. >> > > > >> > > > Does anyone know how to exclude / stop maven from generating the >> > license >> > > > files and placing them in META-INF? I don't know off of the top of >> my >> > > head >> > > > and would appreciate not having to spend lots of time digging if >> > someone >> > > > already knows how to do it. Thanks! >> > > > >> > > > On Fri, Aug 19, 2016 at 11:26 AM, Tim Ellison < >> [email protected]> >> > > > wrote: >> > > > >> > > > > The fact that "apache-pirk-0.1.0-exe.jar" contains >> > > > > /LICENSE.txt >> > > > > >> > > > > which is a BSD license text, and the actual license for this JAR >> is >> > > > > /META-INF/bin-license-notice/LICENSE-bin >> > > > > >> > > > > is a blocker for me. >> > > > > >> > > > > It is not acceptable to say that the JAR does contain the correct >> > > > > license somewhere, with some name. >> > > > > >> > > > > >> > > > > How about excluding all the other licenses and notices in the exe >> jar >> > > > > *except* /META-INF/bin-license-notice/** >> > > > > >> > > > > Regards, >> > > > > Tim >> > > > > >> > > > > On 19/08/16 16:07, Ellison Anne Williams wrote: >> > > > > > Comments inline below. >> > > > > > >> > > > > > Additionally, as stated before, this is not the most elegant >> > solution >> > > > but >> > > > > > is seems to satisfy all of the L&N ASF requirements (that I can >> > > find). >> > > > It >> > > > > > seems that a full re-factor with submodules (a la NiFi) will be >> > > > necessary >> > > > > > to make it cleaner. I would prefer that we make cleaning up the >> L&N >> > > > > > situation a JIRA issue to go hand in hand with the submodule >> > refactor >> > > > and >> > > > > > proceed with the release. If you have any suggestions on >> cleaning >> > > that >> > > > > > doesn't involve a submodule refactor, I happy to implement them. >> > > > > > >> > > > > > >> > > > > > On Fri, Aug 19, 2016 at 10:53 AM, Suneel Marthi < >> > [email protected]> >> > > > > wrote: >> > > > > > >> > > > > >> On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison < >> > > [email protected]> >> > > > > >> wrote: >> > > > > >> >> > > > > >>> On 19/08/16 14:52, Ellison Anne Williams wrote: >> > > > > >>>> Can you please take a look at PR 65 (PIRK-53) and let me >> know if >> > > we >> > > > > are >> > > > > >>>> ready to go with L&N for our first release? >> > > > > >>> >> > > > > >>> I feel like I'm being the bad cop :-( >> > > > > >>> >> > > > > >>> I'm trying to put myself into the shoes of somebody picking up >> > one >> > > of >> > > > > >>> these artefacts, and figuring out what the terms are under >> which >> > it >> > > > was >> > > > > >>> received. Having L&N files in there that are correct but >> mixed >> > in >> > > > > >>> amongst other incorrect L&N files is just too confusing. How >> > can a >> > > > > user >> > > > > >>> know which ones apply? So we have to filter out the rotten >> ones, >> > > and >> > > > > >>> place the correct ones where they would expect to be found. >> > > > > >>> >> > > > > >>> Looking into each of the ZIP/JAR files produced from >> > > > > ellisonanne/pirk-53 >> > > > > >>> branch, I see the following: >> > > > > >>> >> > > > > >>> apache-pirk-0.0.2-source-release.zip (Main source release) >> > > > > >>> correct >> > > > > >>> /LICENSE >> > > > > >>> /NOTICE >> > > > > >>> /DISCLAIMER >> > > > > >>> confusing (but off topic) >> > > > > >>> /logs - contains old log files >> > > > > >> >> > > > > >> These need to be excluded when building the artifact. >> > > > > >> >> > > > > >>> >> > > > > >> >> > > > > > >> > > > > > The logs is probably my fault on a sloppy commit - I will clean >> it. >> > > > > Thanks >> > > > > > for pointing it out. >> > > > > > >> > > > > > >> > > > > >> >> > > > > >> >> > > > > >>> apache-pirk-0.1.0.jar (Binary project JAR), and >> > > > > >>> apache-pirk-0.1.0-sources.jar (Corresponding source for >> binary >> > > > project >> > > > > >>> JAR) >> > > > > >>> correct >> > > > > >>> /META-INF/LICENSE >> > > > > >>> /META-INF/NOTICE >> > > > > >>> incorrect >> > > > > >>> /META-INF/bin-license-notice/licenses/* - >> does >> > not >> > > > > >> relate >> > > > > >>> to the >> > > > > >>> content of this JAR. >> > > > > >>> /META-INF/bin-license-notice/LICENSE-bin - >> does >> > > not >> > > > > >>> relate to the >> > > > > >>> content of this JAR. >> > > > > >>> /META-INF/bin-license-notice/NOTICE-bin - >> does >> > not >> > > > > >> relate >> > > > > >>> to the >> > > > > >>> content of this JAR. >> > > > > >>> confusing >> > > > > >>> /META-INF/DISCLAIMER - missing, but probably >> ok. >> > > > > Ideally >> > > > > >>> would >> > > > > >>> appear in this JAR too. >> > > > > >>> >> > > > > >> >> > > > > > >> > > > > > Yes, the bin-license-notice directory contain the L&N files that >> > > > > correspond >> > > > > > to the binary distribution not the source release; however, they >> > are >> > > > > > clearly labeled, so there shouldn't be any user confusion. This >> > > doesn't >> > > > > > appear to be contradictory to what I see in NiFi - the binary >> L&N >> > > files >> > > > > are >> > > > > > in the nifi-assembly directory which gets packaged into the >> source >> > > > > release. >> > > > > > >> > > > > > >> > > > > > >> > > > > >>> apache-pirk-0.1.0-exe.jar (Combined JAR with all dependencies >> > > > > included) >> > > > > >>> incorrect >> > > > > >>> /LICENSE.txt - this is a BSD license. >> > > > > >>> /META-INF/LICENSE - does not refer to >> > subcomponents >> > > > > >>> license/ directory. >> > > > > >>> /META-INF/NOTICE - does not contain required >> > > notices >> > > > > from >> > > > > >>> subcomponents. >> > > > > >>> /META-INF/LICENSE.txt - contains additional >> > license >> > > > > >>> statements beyond >> > > > > >>> ALv2. >> > > > > >>> /META-INF/NOTICE.txt - does not reference Pirk >> > > > > >> incubating, >> > > > > >>> contains >> > > > > >>> ref to LICENSE.txt >> > > > > >>> /META-INF/license/* - appears not the be the >> set >> > of >> > > > > >>> subcomponent >> > > > > >>> licenses (count=10) >> > > > > >>> /META-INF/bin-license-notice/LICENSE-bin - >> not >> > > > called >> > > > > >>> LICENSE. >> > > > > >>> /META-INF/bin-license-notice/NOTICE-bin - not >> > > called >> > > > > >>> NOTICE. >> > > > > >>> confusing >> > > > > >>> /LICENSE-junit.txt - should be in license/ >> > > directory. >> > > > > >>> /META-INF/bin-license-notice/licenses/* - >> should >> > > be >> > > > in >> > > > > >>> /META-INF/license/* >> > > > > >>> /META-INF/bin-license-notice/LICENSE-bin - >> > should >> > > be >> > > > > in >> > > > > >>> /META-INF/LICENSE >> > > > > >>> /META-INF/bin-license-notice/NOTICE-bin - >> should >> > > be >> > > > in >> > > > > >>> /META-INF/NOTICE >> > > > > >>> >> > > > > >> >> > > > > > >> > > > > > All of the L&N files that you referenced as incorrect are >> > > automatically >> > > > > > added into the exe jar -- I'm not sure how to prevent this from >> > > > happening >> > > > > > off of the top of my head (I'm sure it's possible...), but my >> > > > > understanding >> > > > > > is that it's not a violation of the policy, it's just not the >> > > cleanest >> > > > > > approach. I didn't see a hard requirement that the binary L&N >> files >> > > had >> > > > > to >> > > > > > be called 'LICENSE' or 'NOTICE' - just that they had to be >> present >> > > and >> > > > > > clearly labeled. Happy to change them to be 'LICENSE' and >> 'NOTICE' >> > in >> > > > the >> > > > > > bin-license-notice dir, but I would be more confused as a user. >> > > > > > >> > > > > > I also didn't see a hard requirement that the 'licenses' >> directory >> > > > needed >> > > > > > to be directly under META-INF, in fact, I think that it's more >> > > > confusing >> > > > > > that way as it would show up in the source release. >> > > > > > >> > > > > > >> > > > > >>> >> > > > > >>> I'd appreciate other mentors' close review of these built >> > artefacts >> > > > > too. >> > > > > >>> >> > > > > >>> Seems that the main project source release looks good, but the >> > > > > >>> convenience JARs still needs some filtering/moving work. >> > > > > >>> >> > > > > >>> Anything else you can think of. Not sure how much of this can >> be >> > > > > >> addressed >> > > > > >> in this release. Its best to acknowledge the remaining license >> > > issues >> > > > > that >> > > > > >> need to be addressed and move forward with cutting a release. >> > > > > >> >> > > > > >> There just doesn't seem a clean way to get all of this >> > straightened >> > > > out >> > > > > for >> > > > > >> the very first release, its possible that the way we are >> packaging >> > > the >> > > > > >> artifacts now may not be the right way and we need to do it >> > > > differently, >> > > > > >> something that we had not considered or talked about so far. >> > > > > >> >> > > > > >> Regards, >> > > > > >>> Tim >> > > > > >>> >> > > > > >> >> > > > > >> @Ellison how are we packaging the licenses ? I agree that the >> > logs/, >> > > > > >> bin-license-notice/ shuldn't be showing up. >> > > > > >> >> > > > > > >> > > > > >> > > > >> > > >> > >> > >
