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

Reply via email to