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. > > > > >> > > > > > > > > > > > > > > >
