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