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