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

Reply via email to