Mentors - 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?
Thanks! Ellison Anne On Thu, Aug 18, 2016 at 9:54 AM, Ellison Anne Williams < [email protected]> wrote: > So, here is what I ended up doing: > > 1.) Changing the root LICENSE and NOTICE files to be the source-only Pirk > L&N files > > 2.) Creating a src/main/resource/META-INF/bin-license-notice directory > containing the L&N files corresponding to the binary distribution of Pirk > -- LICENSE-bin and NOTICE-bin > > 3.) Moving the 'licenses' directory to > src/main/resource/META-INF/bin-license-notice/licenses > so that the full licenses are available in the binary artifacts > > Thus, all of the L&N files are available under META-INF for both the > source and binary distributions and are labeled accordingly. You can check > by running: > > mvn clean release:clean > > mvn -Psigned_release release:prepare -Darguments="-DskipTests" > > and then checking the jar files. > > Mentors - correct me if I'm wrong, but the rules just state the the > correct L&N files should be included in the appropriate distributions, not > that we can't have the binary L&N files in the source dist as long as we > label them as such (they are in their own directory labeled as > 'bin-license-notice'). > > I will be the first to say that this is not the most elegant solution -- I > will put in a JIRA issue to make this more elegant and to have the binary > L&N files appear at the root of the binary artifacts. Hopefully, in the > interim, it satisfies our L&N compliance. > > > > On Thu, Aug 18, 2016 at 4:06 AM, Tim Ellison <[email protected]> > wrote: > >> On 17/08/16 19:59, Ellison Anne Williams wrote: >> > Thanks guys. >> > >> > I will make another set of L&N files (other than what's in the root of >> PR >> > 53) for the source-only release artifacts and figure out where to place >> > them based on the previous comments. I will add them to PR 53, so let's >> not >> > merge yet (I will change the status to WIP)... >> >> Please see my other note, and let's put the source L&N at root, and the >> binaries into a subdirectory for use during building. >> >> > I want to make sure that we follow the correct ASF procedures for L&N >> files >> > (whatever time that it takes) and get it as 'right as possible' with the >> > first release. >> >> You're doing a fantastic job! I know this is real pain to do, >> especially as it doesn't have a technical impact, but it is important. >> As you can see even many top level projects are not doing it right >> (yet). Consumers of Pirk need a clear picture of what they are >> receiving and their obligations, so thank you for stepping up to sort it >> out! >> >> Regards, >> Tim >> >> >> > On Wed, Aug 17, 2016 at 2:41 PM, Billie Rinaldi <[email protected]> >> wrote: >> > >> >> Every artifact needs L&N files, so the source release zip and jars all >> need >> >> their own L&N. Perhaps the L&N would be the same for the zip and >> >> source-only jars (depending on the exact contents), while the exe jar >> would >> >> need a different L&N. >> >> >> >> I believe the assembly plugin only creates the zip, and some other >> plugin >> >> creates the jars. Possibly the jar plugin, or the remote resources >> plugin >> >> might be involved (based on the comment in the parent pom: >> >> http://svn.apache.org/repos/asf/maven/pom/trunk/asf/pom.xml). Either >> way, >> >> it seems like changing the plugin configuration might not be necessary >> to >> >> modify L&N in jars; we may just be able to drop in the L&N in a >> META-INF >> >> directory in src/main/resources or src/main/appended-resources (as in >> the >> >> examples linked in Joe's and my previous emails). As for the source >> release >> >> zip, the L&N from the main project directory will be used. >> >> >> >> On Wed, Aug 17, 2016 at 11:04 AM, Ellison Anne Williams < >> >> [email protected]> wrote: >> >> >> >>> From the discussion, although this seems to be somewhat murky ASF >> ground, >> >>> it seems that we need two sets of L&N files: >> >>> >> >>> 1.) L&N files to accompany executable jars, which include the >> transitive >> >>> L&N requirements dictated by the build (this is what our L&N files >> >> reflect >> >>> in PR 53) >> >>> >> >>> 2.) L&N files to accompany source-only jars, which, in our case, would >> >>> really include only 'our' ASL L&N as we aren't distributing anything >> else >> >>> but our source >> >>> >> >>> Is this correct? >> >>> >> >>> If so, from Billie's comments, it seems that we can accomplish this >> via >> >>> configuring our maven assembly plugin. We can make a 'assembly' >> >> directory, >> >>> include the source-only L&N files there, and configure accordingly. Is >> >> this >> >>> an acceptable practice? >> >>> >> >>> >> >>> >> >>> P.S. -- When I downloaded the NiFI source release here >> >>> https://www.apache.org/dyn/closer.lua?path=/nifi/1.0.0- >> >>> BETA/nifi-1.0.0-BETA-source-release.zip >> >>> and checked the LICENSE and NOTICE files, I see the same files as in >> the >> >>> master branch on github -- am I completely missing something here? >> >>> >> >>> On Wed, Aug 17, 2016 at 11:53 AM, Billie Rinaldi <[email protected]> >> >>> wrote: >> >>> >> >>>> It looks like it is also possible to have >> >>>> src/main/appended-resources/META-INF/LICENSE and >> >>>> src/main/appended-resources/META-INF/NOTICE that will be appended to >> >> the >> >>>> default. See https://issues.apache.org/jira/browse/ACCUMULO-3990 and >> >>> these >> >>>> examples: >> >>>> >> >>>> https://github.com/apache/accumulo/tree/master/server/ >> >>>> monitor/src/main/appended-resources/META-INF >> >>>> https://github.com/apache/hbase/tree/master/hbase- >> >>>> thrift/src/main/appended-resources/META-INF >> >>>> >> >>>> This is for jars; it's also easy to adjust L&N for assemblies (tars >> and >> >>>> zips) because you're explicitly listing files to include in the >> >> assembly >> >>>> spec. >> >>>> >> >>>> On Wed, Aug 17, 2016 at 8:48 AM, Tim Ellison <[email protected]> >> >>>> wrote: >> >>>> >> >>>>> On 17/08/16 16:08, Ellison Anne Williams wrote: >> >>>>>> I'm seeing the same LICENSE and NOTICE files used throughout NiFi - >> >>>> even >> >>>>> in >> >>>>>> the nifi-assembly directory which is referenced here >> >>>>>> https://nifi.apache.org/licensing-guide.html >> >>>>> >> >>>>> FWIW the LICENSE I see in "nifi-1.0.0-BETA-source-release.zip" is >> >>> quite >> >>>>> different to that in "nifi-1.0.0-BETA-bin.tar.gz". So they have >> >>> figured >> >>>>> it out. >> >>>>> >> >>>>> Regards, >> >>>>> Tim >> >>>>> >> >>>>>> Joe - Am I missing something here? >> >>>>>> >> >>>>>> I would echo Suneel and ask if (1) it is really a strict >> >> requirement >> >>>> for >> >>>>>> our sources jar and/or (2) if we are interpreting it correctly. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Wed, Aug 17, 2016 at 10:55 AM, Suneel Marthi < >> >>>> [email protected] >> >>>>>> >> >>>>>> wrote: >> >>>>>> >> >>>>>>> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison < >> >>> [email protected]> >> >>>>>>> wrote: >> >>>>>>> >> >>>>>>>> On 17/08/16 11:40, ellisonanne wrote: >> >>>>>>>>> Github user ellisonanne commented on a diff in the pull request: >> >>>>>>>>> >> >>>>>>>>> https://github.com/apache/incubator-pirk/pull/65# >> >>>>>>>> discussion_r75099656 >> >>>>>>>>> >> >>>>>>>>> --- Diff: LICENSE --- >> >>>>>>>>> @@ -199,4 +199,64 @@ >> >>>>>>>>> distributed under the License is distributed on an "AS >> >> IS" >> >>>>>>> BASIS, >> >>>>>>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either >> >>> express >> >>>>> or >> >>>>>>>> implied. >> >>>>>>>>> See the License for the specific language governing >> >>>>> permissions >> >>>>>>>> and >> >>>>>>>>> - limitations under the License. >> >>>>>>>>> \ No newline at end of file >> >>>>>>>>> + limitations under the License. >> >>>>>>>>> + >> >>>>>>>>> + >> >>>>>>>>> +============================= >> >> ============================== >> >>>>>>>> ============ >> >>>>>>>>> +Apache Pirk (incubating) Subcomponents: >> >>>>>>>>> + >> >>>>>>>>> +The Apache Pirk project contains subcomponents with >> >> separate >> >>>>>>>> copyright >> >>>>>>>>> +notices and license terms. Your use of the source code for >> >>> the >> >>>>>>> these >> >>>>>>>>> +subcomponents is subject to the terms and conditions of the >> >>>>>>>> following >> >>>>>>>>> +licenses. >> >>>>>>>>> + >> >>>>>>>>> --- End diff -- >> >>>>>>>>> >> >>>>>>>>> I'm confused - how do we create different LICENSE and NOTICE >> >> files >> >>>>>>>>> for the different jars when they are built via the release >> >> plugin? >> >>>>>>>> >> >>>>>>>> I'm guessing it requires some pom foo beyond my feeble >> >> capabilities >> >>>> :-( >> >>>>>>>> >> >>>>>>> >> >>>>>>> I am not sure how u can package/not package license files in >> >>> different >> >>>>>>> artifacts. >> >>>>>>> If this is a strict requirement, a good chunk of TLPs today are in >> >>>>>>> violation of this. >> >>>>>>> >> >>>>>>> Should we have Justin McLean or John D. Ament from IPMC review our >> >>>>>>> artifacts now? >> >>>>>>> >> >>>>>>>> >> >>>>>>>> Besides stating the obvious that : >> >>>>>>>> >> >>>>>>>> (1) we'd store the source LICENSE and NOTICE file in the project >> >>>>>>>> repository root, and place in there only the required information >> >>> for >> >>>>>>>> code we are hosting in our repo and including in the source.jar. >> >>> For >> >>>>>>>> Pirk as it is today, that will be a plain ALv2 text and simple >> >>>> notice. >> >>>>>>>> >> >>>>>>>> (2) we'd then have alternative LICENSE and NOTICE files for the >> >>>>>>>> convenience "exe" JAR in a subdirectory that are used to replace >> >>> the >> >>>>>>>> top-level files when building the binaries. This would refer to >> >>> the >> >>>>>>>> license/ directory containing the full text of the 3rd-party >> >>>> licenses. >> >>>>>>>> >> >>>>>>>> Maybe our friends from Apache NiFi can explain what they do, as >> >>> they >> >>>>>>>> have the correct information in their release guide [1], and they >> >>> are >> >>>>>>>> Maven-based too. >> >>>>>>>> >> >>>>>>>> A number of other projects I peeked into don't seem to be doing >> >> the >> >>>>>>>> right thing IMHO. >> >>>>>>>> >> >>>>>>>> [1] https://nifi.apache.org/licensing-guide.html >> >>>>>>>> >> >>>>>>>> Regards, >> >>>>>>>> Tim >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>> >> >> >> > >> > >
