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