+1 to go ahead with a source release Sent from my iPhone
> On Aug 19, 2016, at 11:52 PM, Ellison Anne Williams > <[email protected]> wrote: > > 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. >> >>
