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