You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pirk.apache.org by ellisonanne <gi...@git.apache.org> on 2016/08/16 16:59:02 UTC
[GitHub] incubator-pirk pull request #65: [PIRK-53] - Fix LICENSE and NOTICE Files fo...
GitHub user ellisonanne opened a pull request:
https://github.com/apache/incubator-pirk/pull/65
[PIRK-53] - Fix LICENSE and NOTICE Files for Release Compliance
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ellisonanne/incubator-pirk pirk-53
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-pirk/pull/65.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #65
----
commit 74a6f11a1af491cc3b722af3fbb25b9342025b64
Author: ellisonanne <ea...@apache.org>
Date: 2016-07-29T19:45:21Z
Merge pull request #5 from apache/master
up
commit 42f3e8400f810377a4bae06638fc13c0e37707f3
Author: ellisonanne <ea...@apache.org>
Date: 2016-07-31T17:47:15Z
Merge pull request #6 from apache/master
updating fork
commit 887358883d26940845a3486b0dc87cd0cc6c3807
Author: ellisonanne <ea...@apache.org>
Date: 2016-08-01T13:06:35Z
Merge pull request #7 from apache/master
up
commit 2ad5c619084af2517cd135374f93be20410cc45c
Author: ellisonanne <ea...@apache.org>
Date: 2016-08-02T16:22:53Z
Merge pull request #8 from apache/master
updating fork
commit d3c6eeb37a0300ea882c0bb2bcd2939132e7e5cb
Author: Ellison Anne Williams <ea...@apache.org>
Date: 2016-08-06T14:23:24Z
Merge pull request #9 from apache/master
updating fork
commit 381f3529f97fa38b7b06be015c7b82471c8b95d5
Author: Ellison Anne Williams <ea...@apache.org>
Date: 2016-08-11T13:22:15Z
Merge pull request #10 from apache/master
updating fork
commit 6ab035dd32fc4e3464cfb377ccb3493ecf9a313d
Author: Ellison Anne Williams <ea...@apache.org>
Date: 2016-08-12T21:19:23Z
Merge pull request #11 from apache/master
up
commit 47a933f9c1d6c6c80f7b61ba5856a84af8162dca
Author: Ellison Anne Williams <ea...@apache.org>
Date: 2016-08-13T12:31:25Z
Merge pull request #12 from apache/master
up
commit 6ba5ed4b3ce4983f1e1aa958b6f55180613fa1a1
Author: Ellison Anne Williams <ea...@apache.org>
Date: 2016-08-16T13:30:13Z
Merge pull request #13 from apache/master
updating fork
commit 003eb3a60a929ccba02e29cae8cd6e48850e6627
Author: eawilliams <ea...@apache.org>
Date: 2016-08-16T16:56:59Z
added information to the LICENSE and NOTICE files for release compliance
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk issue #65: [PIRK-53] - Fix LICENSE and NOTICE Files for Relea...
Posted by smarthi <gi...@git.apache.org>.
Github user smarthi commented on the issue:
https://github.com/apache/incubator-pirk/pull/65
+1 Lgtm
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk pull request #65: [PIRK-53] [WIP] - Fix LICENSE and NOTICE Fi...
Posted by smarthi <gi...@git.apache.org>.
Github user smarthi commented on a diff in the pull request:
https://github.com/apache/incubator-pirk/pull/65#discussion_r75311521
--- Diff: src/main/resources/META-INF/bin-license-notice/NOTICE-bin ---
@@ -0,0 +1,278 @@
+Apache Pirk (incubating)
+Copyright 2016 The Apache Software Foundation
+
+This product includes software developed at
+The Apache Software Foundation (http://www.apache.org/).
+
+========================================================================
+Common Development and Distribution License 1.0
+========================================================================
+
+The following components are provided under the Common Development and Distribution License 1.0. See project link for details.
+
+ (Common Development and Distribution License (CDDL) v1.0) JavaBeans Activation Framework (JAF) (javax.activation:activation:1.1 - http://java.sun.com/products/javabeans/jaf/index.jsp)
+ (COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0) (GNU General Public Library) Streaming API for XML (javax.xml.stream:stax-api:1.0-2 - no url defined)
+ (CDDL 1.0) Glassfish Jasper (org.mortbay.jetty:jsp-2.1:6.1.14 - http://jetty.mortbay.org/project/modules/jsp-2.1)
+ (CDDL 1.0) Servlet Specification 2.5 API (org.mortbay.jetty:servlet-api-2.5:6.1.14 - http://jetty.mortbay.org/project/modules/servlet-api-2.5)
+
+
+========================================================================
+Common Development and Distribution License 1.1
+========================================================================
+
+The following components are provided under the Common Development and Distribution License 1.1. See project link for details.
+
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-client (com.sun.jersey:jersey-client:1.9 - https://jersey.java.net/jersey-client/)
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-core (com.sun.jersey:jersey-core:1.9 - https://jersey.java.net/jersey-core/)
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-json (com.sun.jersey:jersey-json:1.9 - https://jersey.java.net/jersey-json/)
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-server (com.sun.jersey:jersey-server:1.9 - https://jersey.java.net/jersey-server/)
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-guice (com.sun.jersey.contribs:jersey-guice:1.9 - https://jersey.java.net/jersey-contribs/jersey-guice/)
+ (CDDL 1.1) (GPL2 w/ CPE) JAXB RI (com.sun.xml.bind:jaxb-impl:2.2.3-1 - http://jaxb.java.net/)
+ (CDDL 1.1) (GPL2 w/ CPE) JAXB API bundle for GlassFish V3 (javax.xml.bind:jaxb-api:2.2.2 - https://jaxb.dev.java.net/)
+
+
+========================================================================
+Eclipse Public License 1.0
+========================================================================
+
+The following components are provided under the Eclipse Public License 1.0. See project link for details.
+
+ (Eclipse Public License 1.0) JUnit (junit:junit:4.12 - http://junit.org)
+ (Eclipse Public License v1.0) Eclipse JDT Core (org.eclipse.jdt:core:3.1.1 - http://www.eclipse.org/jdt/)
+
+
+========================================================================
+NOTICE files
+========================================================================
+
+The following NOTICEs are pertain to software distributed with this project.
+
+-------------------------------------------------------------------------------
+ NOTICE file for direct Apache licensed software dependencies corresponding to
+ the section 4d of The Apache License, Version 2.0
+-------------------------------------------------------------------------------
+
+Apache Commons Math (http://commons.apache.org/proper/commons-math/)
+Copyright 2001-2016 The Apache Software Foundation
+
+json-simple (https://github.com/fangyidong/json-simple)
+The Apache Software Foundation
+
+Apache Hadoop (http://hadoop.apache.org/)
+The Apache Software Foundation
+
+Apache Spark (http://spark.apache.org/)
+Copyright 2014 and onwards The Apache Software Foundation
+
+Elasticsearch for Apache Hadoop (https://github.com/elastic/elasticsearch-hadoop)
+Copyright 2009-2016 The Apache Software Foundation
+
+jna-gmp (https://github.com/square/jna-gmp)
+The Apache Software Foundation
+
+Apache log4j (http://logging.apache.org/log4j/2.x/)
+The Apache Software Foundation
+
+
--- End diff --
Should we add an entry for Storm, Flink, Beam, Cascading too here?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk pull request #65: [PIRK-53] - Fix LICENSE and NOTICE Files fo...
Posted by tellison <gi...@git.apache.org>.
Github user tellison commented on a diff in the pull request:
https://github.com/apache/incubator-pirk/pull/65#discussion_r75086470
--- 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.
+
+
+========================================================================
+BSD-style licenses
+========================================================================
+
+The following components are provided under a BSD-style license. See project link for details.
+The text of each license is also included at licenses/LICENSE-[project].txt.
+
+ (BSD License) AntLR Parser Generator (antlr:antlr:2.7.7 - http://www.antlr.org/)
+ (New BSD License) Kryo (com.esotericsoftware.kryo:kryo:2.21 - http://code.google.com/p/kryo/)
+ (New BSD License) MinLog (com.esotericsoftware.minlog:minlog:1.2 - http://code.google.com/p/minlog/)
+ (New BSD License) ReflectASM (com.esotericsoftware.reflectasm:reflectasm:1.07 - http://code.google.com/p/reflectasm/)
+ (New BSD license) Protocol Buffer Java API (com.google.protobuf:protobuf-java:2.5.0 - http://code.google.com/p/protobuf)
+ (BSD) JSch (com.jcraft:jsch:0.1.42 - http://www.jcraft.com/jsch/)
+ (BSD) ParaNamer Core (com.thoughtworks.paranamer:paranamer:2.3 - http://paranamer.codehaus.org/paranamer)
+ (BSD) Automaton (dk.brics.automaton:automaton:1.11-8 - http://www.brics.dk/automaton/)
+ (BSD) JLine (jline:jline:1.0 - http://jline.sourceforge.net)
+ (The New BSD License) Py4J (net.sf.py4j:py4j:0.9 - http://www.py4j.org/)
+ (BSD licence) ANTLR ST4 4.0.4 (org.antlr:ST4:4.0.4 - http://www.stringtemplate.org)
+ (BSD licence) ANTLR StringTemplate (org.antlr:stringtemplate:3.2.1 - http://www.stringtemplate.org)
+ (New BSD License) Commons Compiler (org.codehaus.janino:commons-compiler:2.7.8 - http://docs.codehaus.org/display/JANINO/Home/commons-compiler)
+ (New BSD License) Janino (org.codehaus.janino:janino:2.7.8 - http://docs.codehaus.org/display/JANINO/Home/janino)
+ (The BSD 3-Clause License) leveldbjni-all (org.fusesource.leveldbjni:leveldbjni-all:1.8 - http://leveldbjni.fusesource.org/leveldbjni-all)
+ (New BSD License) Hamcrest Core (org.hamcrest:hamcrest-core:1.3 - https://github.com/hamcrest/JavaHamcrest/hamcrest-core)
+ (BSD 3-Clause) Scala Compiler (org.scala-lang:scala-compiler:2.11.0 - http://www.scala-lang.org/)
+ (BSD 3-Clause) Scala Library (org.scala-lang:scala-library:2.11.7 - http://www.scala-lang.org/)
+ (BSD 3-Clause) Scala Compiler (org.scala-lang:scala-reflect:2.11.2 - http://www.scala-lang.org/)
+ (BSD 3-Clause) Scalap (org.scala-lang:scalap:2.11.0 - http://www.scala-lang.org/)
+ (BSD 3-clause) scala-parser-combinators (org.scala-lang.modules:scala-parser-combinators_2.11:1.0.1 - http://www.scala-lang.org/)
+ (BSD 3-clause) scala-xml (org.scala-lang.modules:scala-xml_2.11:1.0.1 - http://www.scala-lang.org/)
+ (The BSD License) xmlenc Library (xmlenc:xmlenc:0.52 - http://xmlenc.sourceforge.net)
+ (BSD) Antlr 3.4 Runtime (org.antlr:antlr-runtime:3.4 - http://www.antlr.org)
+ (BSD) ASM Core (asm:asm:3.1 - http://asm.objectweb.org/asm/)
+ (BSD) HSQLDB (hsqldb:hsqldb:1.8.0.10 - http://hsqldb.org/)
+
+========================================================================
+MIT licenses
+========================================================================
+
+The following components are provided under the MIT License. See project link for details.
+The text of each license is also included at licenses/LICENSE-[project].txt.
+
+ (MIT License) pyrolite (net.razorvine:pyrolite:4.9 - https://github.com/irmen/Pyrolite)
+ (The MIT License) JOpt Simple (net.sf.jopt-simple:jopt-simple:4.6 - http://pholser.github.com/jopt-simple)
+ (MIT License) JCL 1.1.1 implemented over SLF4J (org.slf4j:jcl-over-slf4j:1.7.10 - http://www.slf4j.org)
+ (MIT License) JUL to SLF4J bridge (org.slf4j:jul-to-slf4j:1.7.10 - http://www.slf4j.org)
+ (MIT License) SLF4J API Module (org.slf4j:slf4j-api:1.7.21 - http://www.slf4j.org)
+
--- End diff --
I've not checked each of these by hand :-) , but trust that they are the set that came from Maven's transitive walk of Pirk's dependencies (```mvn license:add-third-party```).
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk pull request #65: [PIRK-53] [WIP] - Fix LICENSE and NOTICE Fi...
Posted by smarthi <gi...@git.apache.org>.
Github user smarthi commented on a diff in the pull request:
https://github.com/apache/incubator-pirk/pull/65#discussion_r75311256
--- Diff: pom.xml ---
@@ -350,6 +350,9 @@
<exclude>docs/*</exclude> <!-- Exclude docs -->
<exclude>logs/*</exclude> <!-- Exclude logs -->
<exclude>**/m2.conf</exclude> <!-- Exclude Maven conf which gets installed on travis and fails RAT check -->
+ <exclude>src/main/resources/META-INF/bin-license-notice/licenses/*</exclude> <!-- Exclude licenses files -->
+ <exclude>src/main/resources/META-INF/bin-license-notice/*</exclude>
+ <exclude>src/main/resources/META-INF/*</exclude>
--- End diff --
Replace these 3 lines by a single line
`<exclude>src/main/resources/META-INF/**</exclude>`
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
Re: Source JAR vs. Convenience binary JAR license files
Posted by Suneel Marthi <su...@gmail.com>.
+1 to go ahead with a source release
Sent from my iPhone
> On Aug 19, 2016, at 11:52 PM, Ellison Anne Williams <ea...@gmail.com> 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 <
> eawilliamspirk@gmail.com> 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 <su...@gmail.com>
>> 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 <
>>> eawilliamspirk@gmail.com> 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 <
>>> suneel.marthi@gmail.com>
>>>> 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 <
>>>>> eawilliamspirk@gmail.com> 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 <
>>> t.p.ellison@gmail.com>
>>>>>> 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 <
>>>> smarthi@apache.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <
>>>>> t.p.ellison@gmail.com>
>>>>>>>>> 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.
>>
>>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Suneel Marthi <su...@gmail.com>.
+1 to have a source only release
On Sun, Aug 21, 2016 at 12:23 PM, Ellison Anne Williams <
eawilliamspirk@gmail.com> wrote:
> There were some issues in extracting the incorrect L&N files from the
> executable jar and re-jarring so as to be fully functioning in a cluster
> setting (extracting and fixing the L&N files was easy, getting it to fully
> function on the cluster after re-jarring was not). Thus, I've decided to
> stick with the source only release for now as releasing the binary
> artifacts is not necessary. I will publish the URL and send the voting
> email in a second. If folks object to the source only release, please let
> me know.
>
> On Sat, Aug 20, 2016 at 1:38 PM, Ellison Anne Williams <
> eawilliamspirk@gmail.com> wrote:
>
> > Agreed - let's get through the release and then start a separate thread
> to
> > discuss the submodule breakout
> >
> > On Sat, Aug 20, 2016 at 1:13 PM, Suneel Marthi <su...@gmail.com>
> > wrote:
> >
> >> For this release, lets add the README as has been suggested.
> >>
> >>
> >> ---------------
> >>
> >> Breaking out the project into submodules would be a much more involved
> >> discussion that should also include as to how we want to break the
> project
> >> into individual artifacts - like for Responder, Querier, Spark
> Responder,
> >> Storm Responder, Benchmarks, etc...
> >>
> >> For reference, projects like Mahout, Flink etc that have several
> >> submodules
> >> produce different jar files for each of them and there's one tar or zip
> >> that would package all of the jars.
> >>
> >> See http://www.apache.org/dist/mahout/0.12.2/
> >>
> >> That would be something we need to discuss following this release. On
> >> projects like Flink, Kafka major refactoring or new feature design are
> >> usually discussed via shared google documents wherein others could
> comment
> >> or propose changes. Kafka calls these feature changes as 'KLIP' and
> Flink
> >> calls them 'FLIP'.
> >>
> >> We may want to start something similar for Pirk.
> >>
> >> On Sat, Aug 20, 2016 at 12:49 PM, Ellison Anne Williams <
> >> eawilliamspirk@gmail.com> wrote:
> >>
> >> > Will do thanks.
> >> >
> >> > Just to be clear -- the META-INF dir with the binary L&N files will be
> >> > removed and the binary-related L&N files will be moved to as assembly
> >> > directory (or something similar) when we break out the submodules. In
> >> the
> >> > meantime the META-INF (with binary L&N files) as in the PR will be
> >> merged
> >> > after adding the README as suggested. Folks will be responsible for
> >> > updating the binary L&N files as they add dependencies.
> >> >
> >> > On Sat, Aug 20, 2016 at 12:41 PM, Suneel Marthi <
> >> suneel.marthi@gmail.com>
> >> > wrote:
> >> >
> >> > > +1
> >> > >
> >> > > On Sat, Aug 20, 2016 at 12:40 PM, Tim Ellison <
> t.p.ellison@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > On 20 August 2016 at 17:04, Ellison Anne Williams <
> >> > > > eawilliamspirk@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > Yes, if that's acceptable, then I can go that route.
> >> > > > >
> >> > > > > I can allow the artifacts to be generated and pushed to Nexus, I
> >> can
> >> > > > remove
> >> > > > > the binary artifacts, fix the L&N files, rehash/sign, and
> upload.
> >> > > Then, I
> >> > > > > can close the repo (which will run through all signing
> >> verifications)
> >> > > and
> >> > > > > provide the URL for voting. Once we get the submodules in
> place,
> >> the
> >> > > L&N
> >> > > > > file placement will be taken care of automatically for binary
> >> > artifacts
> >> > > > and
> >> > > > > the manual intervention won't be necessary.
> >> > > > >
> >> > > > > Would it be OK to go ahead and merge the PR with the binary L&N
> >> files
> >> > > in
> >> > > > > the bin-license-notice dir in META-INF? That way, folks can be
> >> > > > responsible
> >> > > > > for keeping them updated as they add any new dependencies.
> >> > > > >
> >> > > >
> >> > > > That works for me. Unless other mentors object, I say we go with
> >> this
> >> > > > plan.
> >> > > >
> >> > > > To avoid any confusion you may want to consider creating a brief
> >> readme
> >> > > > file in the META-INF to explain that the L&N files in there only
> >> relate
> >> > > to
> >> > > > the exe-jar.
> >> > > >
> >> > > > Regards,
> >> > > > Tim
> >> > > >
> >> > > >
> >> > > >
> >> > > > > On Sat, Aug 20, 2016 at 11:51 AM, Tim Ellison <
> >> t.p.ellison@gmail.com
> >> > >
> >> > > > > wrote:
> >> > > > >
> >> > > > > > On 20 August 2016 at 16:23, Ellison Anne Williams <
> >> > > > > > eawilliamspirk@gmail.com>
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > Thanks Tim - yes, I've been following that thread with
> >> interest.
> >> > To
> >> > > > > speak
> >> > > > > > > to the documentation for Pirk releases, I have been working
> >> on a
> >> > > page
> >> > > > > for
> >> > > > > > > the website documenting our release process (and the
> gotchas)
> >> > > > > > step-by-step.
> >> > > > > > > Once we complete a successful release vote internally, I
> will
> >> put
> >> > > > forth
> >> > > > > > the
> >> > > > > > > page for comment. I agree with the discussion on the
> >> > > > general@incubator
> >> > > > > > > thread that the release process for a project needs to be
> >> > > documented
> >> > > > > such
> >> > > > > > > that anyone can walk into the project and complete a release
> >> - it
> >> > > > > > shouldn't
> >> > > > > > > be a mystical endeavor.
> >> > > > > >
> >> > > > > >
> >> > > > > > I don't know precisely what steps you are following at the
> >> moment,
> >> > > but
> >> > > > if
> >> > > > > > there is an opportunity to manually intervene and fix-up the
> >> binary
> >> > > JAR
> >> > > > > > licenses before the artefacts are hashed / signed / uploaded
> >> then
> >> > > that
> >> > > > > > could simply be a "documented step" until the scripts handle
> it
> >> > all.
> >> > > > > >
> >> > > > > > ... or even produce the JAR, then
> >> > > > > > - delete the exe-jar's sig/hash
> >> > > > > > - rearrange the L&N files
> >> > > > > > - re-sign/hash
> >> > > > > >
> >> > > > > > Provided it is a repeatable process for the binaries, I think
> >> that
> >> > > > would
> >> > > > > be
> >> > > > > > ok.
> >> > > > > >
> >> > > > > > WDYT?
> >> > > > > >
> >> > > > > > Regards,
> >> > > > > > Tim
> >> > > > > >
> >> > > > > >
> >> > > > > > > On Sat, Aug 20, 2016 at 10:58 AM, Tim Ellison <
> >> > > t.p.ellison@gmail.com
> >> > > > >
> >> > > > > > > wrote:
> >> > > > > > >
> >> > > > > > > > On 20 August 2016 at 04:52, Ellison Anne Williams <
> >> > > > > > > > eawilliamspirk@gmail.com>
> >> > > > > > > > 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!
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > > > Sure. Thanks for your continued focus on this Ellison
> Anne.
> >> > > > > > > >
> >> > > > > > > > FYI there is a discussion underway on
> general@incubator.a.o
> >> > that
> >> > > > is
> >> > > > > > > > relevant to this thread...
> >> > > > > > > >
> >> > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-
> >> > > > > > general/201608.mbox/%
> >> > > > > > > > 3C5113b38e-e52b-0c16-eced-903e00fc4477%40apache.org%3E
> >> > > > > > > >
> >> > > > > > > > I mention it as I expect the Incubator PMC are likely to
> >> assess
> >> > > > > Pirk's
> >> > > > > > > > release by this criteria, given it will be fresh in
> people's
> >> > mind
> >> > > > > when
> >> > > > > > > our
> >> > > > > > > > vote is proposed.
> >> > > > > > > >
> >> > > > > > > > Regards,
> >> > > > > > > > Tim
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
There were some issues in extracting the incorrect L&N files from the
executable jar and re-jarring so as to be fully functioning in a cluster
setting (extracting and fixing the L&N files was easy, getting it to fully
function on the cluster after re-jarring was not). Thus, I've decided to
stick with the source only release for now as releasing the binary
artifacts is not necessary. I will publish the URL and send the voting
email in a second. If folks object to the source only release, please let
me know.
On Sat, Aug 20, 2016 at 1:38 PM, Ellison Anne Williams <
eawilliamspirk@gmail.com> wrote:
> Agreed - let's get through the release and then start a separate thread to
> discuss the submodule breakout
>
> On Sat, Aug 20, 2016 at 1:13 PM, Suneel Marthi <su...@gmail.com>
> wrote:
>
>> For this release, lets add the README as has been suggested.
>>
>>
>> ---------------
>>
>> Breaking out the project into submodules would be a much more involved
>> discussion that should also include as to how we want to break the project
>> into individual artifacts - like for Responder, Querier, Spark Responder,
>> Storm Responder, Benchmarks, etc...
>>
>> For reference, projects like Mahout, Flink etc that have several
>> submodules
>> produce different jar files for each of them and there's one tar or zip
>> that would package all of the jars.
>>
>> See http://www.apache.org/dist/mahout/0.12.2/
>>
>> That would be something we need to discuss following this release. On
>> projects like Flink, Kafka major refactoring or new feature design are
>> usually discussed via shared google documents wherein others could comment
>> or propose changes. Kafka calls these feature changes as 'KLIP' and Flink
>> calls them 'FLIP'.
>>
>> We may want to start something similar for Pirk.
>>
>> On Sat, Aug 20, 2016 at 12:49 PM, Ellison Anne Williams <
>> eawilliamspirk@gmail.com> wrote:
>>
>> > Will do thanks.
>> >
>> > Just to be clear -- the META-INF dir with the binary L&N files will be
>> > removed and the binary-related L&N files will be moved to as assembly
>> > directory (or something similar) when we break out the submodules. In
>> the
>> > meantime the META-INF (with binary L&N files) as in the PR will be
>> merged
>> > after adding the README as suggested. Folks will be responsible for
>> > updating the binary L&N files as they add dependencies.
>> >
>> > On Sat, Aug 20, 2016 at 12:41 PM, Suneel Marthi <
>> suneel.marthi@gmail.com>
>> > wrote:
>> >
>> > > +1
>> > >
>> > > On Sat, Aug 20, 2016 at 12:40 PM, Tim Ellison <t....@gmail.com>
>> > > wrote:
>> > >
>> > > > On 20 August 2016 at 17:04, Ellison Anne Williams <
>> > > > eawilliamspirk@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > Yes, if that's acceptable, then I can go that route.
>> > > > >
>> > > > > I can allow the artifacts to be generated and pushed to Nexus, I
>> can
>> > > > remove
>> > > > > the binary artifacts, fix the L&N files, rehash/sign, and upload.
>> > > Then, I
>> > > > > can close the repo (which will run through all signing
>> verifications)
>> > > and
>> > > > > provide the URL for voting. Once we get the submodules in place,
>> the
>> > > L&N
>> > > > > file placement will be taken care of automatically for binary
>> > artifacts
>> > > > and
>> > > > > the manual intervention won't be necessary.
>> > > > >
>> > > > > Would it be OK to go ahead and merge the PR with the binary L&N
>> files
>> > > in
>> > > > > the bin-license-notice dir in META-INF? That way, folks can be
>> > > > responsible
>> > > > > for keeping them updated as they add any new dependencies.
>> > > > >
>> > > >
>> > > > That works for me. Unless other mentors object, I say we go with
>> this
>> > > > plan.
>> > > >
>> > > > To avoid any confusion you may want to consider creating a brief
>> readme
>> > > > file in the META-INF to explain that the L&N files in there only
>> relate
>> > > to
>> > > > the exe-jar.
>> > > >
>> > > > Regards,
>> > > > Tim
>> > > >
>> > > >
>> > > >
>> > > > > On Sat, Aug 20, 2016 at 11:51 AM, Tim Ellison <
>> t.p.ellison@gmail.com
>> > >
>> > > > > wrote:
>> > > > >
>> > > > > > On 20 August 2016 at 16:23, Ellison Anne Williams <
>> > > > > > eawilliamspirk@gmail.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Thanks Tim - yes, I've been following that thread with
>> interest.
>> > To
>> > > > > speak
>> > > > > > > to the documentation for Pirk releases, I have been working
>> on a
>> > > page
>> > > > > for
>> > > > > > > the website documenting our release process (and the gotchas)
>> > > > > > step-by-step.
>> > > > > > > Once we complete a successful release vote internally, I will
>> put
>> > > > forth
>> > > > > > the
>> > > > > > > page for comment. I agree with the discussion on the
>> > > > general@incubator
>> > > > > > > thread that the release process for a project needs to be
>> > > documented
>> > > > > such
>> > > > > > > that anyone can walk into the project and complete a release
>> - it
>> > > > > > shouldn't
>> > > > > > > be a mystical endeavor.
>> > > > > >
>> > > > > >
>> > > > > > I don't know precisely what steps you are following at the
>> moment,
>> > > but
>> > > > if
>> > > > > > there is an opportunity to manually intervene and fix-up the
>> binary
>> > > JAR
>> > > > > > licenses before the artefacts are hashed / signed / uploaded
>> then
>> > > that
>> > > > > > could simply be a "documented step" until the scripts handle it
>> > all.
>> > > > > >
>> > > > > > ... or even produce the JAR, then
>> > > > > > - delete the exe-jar's sig/hash
>> > > > > > - rearrange the L&N files
>> > > > > > - re-sign/hash
>> > > > > >
>> > > > > > Provided it is a repeatable process for the binaries, I think
>> that
>> > > > would
>> > > > > be
>> > > > > > ok.
>> > > > > >
>> > > > > > WDYT?
>> > > > > >
>> > > > > > Regards,
>> > > > > > Tim
>> > > > > >
>> > > > > >
>> > > > > > > On Sat, Aug 20, 2016 at 10:58 AM, Tim Ellison <
>> > > t.p.ellison@gmail.com
>> > > > >
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > On 20 August 2016 at 04:52, Ellison Anne Williams <
>> > > > > > > > eawilliamspirk@gmail.com>
>> > > > > > > > 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!
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > > Sure. Thanks for your continued focus on this Ellison Anne.
>> > > > > > > >
>> > > > > > > > FYI there is a discussion underway on general@incubator.a.o
>> > that
>> > > > is
>> > > > > > > > relevant to this thread...
>> > > > > > > >
>> > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-
>> > > > > > general/201608.mbox/%
>> > > > > > > > 3C5113b38e-e52b-0c16-eced-903e00fc4477%40apache.org%3E
>> > > > > > > >
>> > > > > > > > I mention it as I expect the Incubator PMC are likely to
>> assess
>> > > > > Pirk's
>> > > > > > > > release by this criteria, given it will be fresh in people's
>> > mind
>> > > > > when
>> > > > > > > our
>> > > > > > > > vote is proposed.
>> > > > > > > >
>> > > > > > > > Regards,
>> > > > > > > > Tim
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
Agreed - let's get through the release and then start a separate thread to
discuss the submodule breakout
On Sat, Aug 20, 2016 at 1:13 PM, Suneel Marthi <su...@gmail.com>
wrote:
> For this release, lets add the README as has been suggested.
>
>
> ---------------
>
> Breaking out the project into submodules would be a much more involved
> discussion that should also include as to how we want to break the project
> into individual artifacts - like for Responder, Querier, Spark Responder,
> Storm Responder, Benchmarks, etc...
>
> For reference, projects like Mahout, Flink etc that have several submodules
> produce different jar files for each of them and there's one tar or zip
> that would package all of the jars.
>
> See http://www.apache.org/dist/mahout/0.12.2/
>
> That would be something we need to discuss following this release. On
> projects like Flink, Kafka major refactoring or new feature design are
> usually discussed via shared google documents wherein others could comment
> or propose changes. Kafka calls these feature changes as 'KLIP' and Flink
> calls them 'FLIP'.
>
> We may want to start something similar for Pirk.
>
> On Sat, Aug 20, 2016 at 12:49 PM, Ellison Anne Williams <
> eawilliamspirk@gmail.com> wrote:
>
> > Will do thanks.
> >
> > Just to be clear -- the META-INF dir with the binary L&N files will be
> > removed and the binary-related L&N files will be moved to as assembly
> > directory (or something similar) when we break out the submodules. In the
> > meantime the META-INF (with binary L&N files) as in the PR will be merged
> > after adding the README as suggested. Folks will be responsible for
> > updating the binary L&N files as they add dependencies.
> >
> > On Sat, Aug 20, 2016 at 12:41 PM, Suneel Marthi <suneel.marthi@gmail.com
> >
> > wrote:
> >
> > > +1
> > >
> > > On Sat, Aug 20, 2016 at 12:40 PM, Tim Ellison <t....@gmail.com>
> > > wrote:
> > >
> > > > On 20 August 2016 at 17:04, Ellison Anne Williams <
> > > > eawilliamspirk@gmail.com>
> > > > wrote:
> > > >
> > > > > Yes, if that's acceptable, then I can go that route.
> > > > >
> > > > > I can allow the artifacts to be generated and pushed to Nexus, I
> can
> > > > remove
> > > > > the binary artifacts, fix the L&N files, rehash/sign, and upload.
> > > Then, I
> > > > > can close the repo (which will run through all signing
> verifications)
> > > and
> > > > > provide the URL for voting. Once we get the submodules in place,
> the
> > > L&N
> > > > > file placement will be taken care of automatically for binary
> > artifacts
> > > > and
> > > > > the manual intervention won't be necessary.
> > > > >
> > > > > Would it be OK to go ahead and merge the PR with the binary L&N
> files
> > > in
> > > > > the bin-license-notice dir in META-INF? That way, folks can be
> > > > responsible
> > > > > for keeping them updated as they add any new dependencies.
> > > > >
> > > >
> > > > That works for me. Unless other mentors object, I say we go with
> this
> > > > plan.
> > > >
> > > > To avoid any confusion you may want to consider creating a brief
> readme
> > > > file in the META-INF to explain that the L&N files in there only
> relate
> > > to
> > > > the exe-jar.
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > > >
> > > >
> > > > > On Sat, Aug 20, 2016 at 11:51 AM, Tim Ellison <
> t.p.ellison@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > On 20 August 2016 at 16:23, Ellison Anne Williams <
> > > > > > eawilliamspirk@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Thanks Tim - yes, I've been following that thread with
> interest.
> > To
> > > > > speak
> > > > > > > to the documentation for Pirk releases, I have been working on
> a
> > > page
> > > > > for
> > > > > > > the website documenting our release process (and the gotchas)
> > > > > > step-by-step.
> > > > > > > Once we complete a successful release vote internally, I will
> put
> > > > forth
> > > > > > the
> > > > > > > page for comment. I agree with the discussion on the
> > > > general@incubator
> > > > > > > thread that the release process for a project needs to be
> > > documented
> > > > > such
> > > > > > > that anyone can walk into the project and complete a release -
> it
> > > > > > shouldn't
> > > > > > > be a mystical endeavor.
> > > > > >
> > > > > >
> > > > > > I don't know precisely what steps you are following at the
> moment,
> > > but
> > > > if
> > > > > > there is an opportunity to manually intervene and fix-up the
> binary
> > > JAR
> > > > > > licenses before the artefacts are hashed / signed / uploaded then
> > > that
> > > > > > could simply be a "documented step" until the scripts handle it
> > all.
> > > > > >
> > > > > > ... or even produce the JAR, then
> > > > > > - delete the exe-jar's sig/hash
> > > > > > - rearrange the L&N files
> > > > > > - re-sign/hash
> > > > > >
> > > > > > Provided it is a repeatable process for the binaries, I think
> that
> > > > would
> > > > > be
> > > > > > ok.
> > > > > >
> > > > > > WDYT?
> > > > > >
> > > > > > Regards,
> > > > > > Tim
> > > > > >
> > > > > >
> > > > > > > On Sat, Aug 20, 2016 at 10:58 AM, Tim Ellison <
> > > t.p.ellison@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On 20 August 2016 at 04:52, Ellison Anne Williams <
> > > > > > > > eawilliamspirk@gmail.com>
> > > > > > > > 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!
> > > > > > > > >
> > > > > > > >
> > > > > > > > Sure. Thanks for your continued focus on this Ellison Anne.
> > > > > > > >
> > > > > > > > FYI there is a discussion underway on general@incubator.a.o
> > that
> > > > is
> > > > > > > > relevant to this thread...
> > > > > > > >
> > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-
> > > > > > general/201608.mbox/%
> > > > > > > > 3C5113b38e-e52b-0c16-eced-903e00fc4477%40apache.org%3E
> > > > > > > >
> > > > > > > > I mention it as I expect the Incubator PMC are likely to
> assess
> > > > > Pirk's
> > > > > > > > release by this criteria, given it will be fresh in people's
> > mind
> > > > > when
> > > > > > > our
> > > > > > > > vote is proposed.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Tim
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Suneel Marthi <su...@gmail.com>.
For this release, lets add the README as has been suggested.
---------------
Breaking out the project into submodules would be a much more involved
discussion that should also include as to how we want to break the project
into individual artifacts - like for Responder, Querier, Spark Responder,
Storm Responder, Benchmarks, etc...
For reference, projects like Mahout, Flink etc that have several submodules
produce different jar files for each of them and there's one tar or zip
that would package all of the jars.
See http://www.apache.org/dist/mahout/0.12.2/
That would be something we need to discuss following this release. On
projects like Flink, Kafka major refactoring or new feature design are
usually discussed via shared google documents wherein others could comment
or propose changes. Kafka calls these feature changes as 'KLIP' and Flink
calls them 'FLIP'.
We may want to start something similar for Pirk.
On Sat, Aug 20, 2016 at 12:49 PM, Ellison Anne Williams <
eawilliamspirk@gmail.com> wrote:
> Will do thanks.
>
> Just to be clear -- the META-INF dir with the binary L&N files will be
> removed and the binary-related L&N files will be moved to as assembly
> directory (or something similar) when we break out the submodules. In the
> meantime the META-INF (with binary L&N files) as in the PR will be merged
> after adding the README as suggested. Folks will be responsible for
> updating the binary L&N files as they add dependencies.
>
> On Sat, Aug 20, 2016 at 12:41 PM, Suneel Marthi <su...@gmail.com>
> wrote:
>
> > +1
> >
> > On Sat, Aug 20, 2016 at 12:40 PM, Tim Ellison <t....@gmail.com>
> > wrote:
> >
> > > On 20 August 2016 at 17:04, Ellison Anne Williams <
> > > eawilliamspirk@gmail.com>
> > > wrote:
> > >
> > > > Yes, if that's acceptable, then I can go that route.
> > > >
> > > > I can allow the artifacts to be generated and pushed to Nexus, I can
> > > remove
> > > > the binary artifacts, fix the L&N files, rehash/sign, and upload.
> > Then, I
> > > > can close the repo (which will run through all signing verifications)
> > and
> > > > provide the URL for voting. Once we get the submodules in place, the
> > L&N
> > > > file placement will be taken care of automatically for binary
> artifacts
> > > and
> > > > the manual intervention won't be necessary.
> > > >
> > > > Would it be OK to go ahead and merge the PR with the binary L&N files
> > in
> > > > the bin-license-notice dir in META-INF? That way, folks can be
> > > responsible
> > > > for keeping them updated as they add any new dependencies.
> > > >
> > >
> > > That works for me. Unless other mentors object, I say we go with this
> > > plan.
> > >
> > > To avoid any confusion you may want to consider creating a brief readme
> > > file in the META-INF to explain that the L&N files in there only relate
> > to
> > > the exe-jar.
> > >
> > > Regards,
> > > Tim
> > >
> > >
> > >
> > > > On Sat, Aug 20, 2016 at 11:51 AM, Tim Ellison <t.p.ellison@gmail.com
> >
> > > > wrote:
> > > >
> > > > > On 20 August 2016 at 16:23, Ellison Anne Williams <
> > > > > eawilliamspirk@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Thanks Tim - yes, I've been following that thread with interest.
> To
> > > > speak
> > > > > > to the documentation for Pirk releases, I have been working on a
> > page
> > > > for
> > > > > > the website documenting our release process (and the gotchas)
> > > > > step-by-step.
> > > > > > Once we complete a successful release vote internally, I will put
> > > forth
> > > > > the
> > > > > > page for comment. I agree with the discussion on the
> > > general@incubator
> > > > > > thread that the release process for a project needs to be
> > documented
> > > > such
> > > > > > that anyone can walk into the project and complete a release - it
> > > > > shouldn't
> > > > > > be a mystical endeavor.
> > > > >
> > > > >
> > > > > I don't know precisely what steps you are following at the moment,
> > but
> > > if
> > > > > there is an opportunity to manually intervene and fix-up the binary
> > JAR
> > > > > licenses before the artefacts are hashed / signed / uploaded then
> > that
> > > > > could simply be a "documented step" until the scripts handle it
> all.
> > > > >
> > > > > ... or even produce the JAR, then
> > > > > - delete the exe-jar's sig/hash
> > > > > - rearrange the L&N files
> > > > > - re-sign/hash
> > > > >
> > > > > Provided it is a repeatable process for the binaries, I think that
> > > would
> > > > be
> > > > > ok.
> > > > >
> > > > > WDYT?
> > > > >
> > > > > Regards,
> > > > > Tim
> > > > >
> > > > >
> > > > > > On Sat, Aug 20, 2016 at 10:58 AM, Tim Ellison <
> > t.p.ellison@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On 20 August 2016 at 04:52, Ellison Anne Williams <
> > > > > > > eawilliamspirk@gmail.com>
> > > > > > > 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!
> > > > > > > >
> > > > > > >
> > > > > > > Sure. Thanks for your continued focus on this Ellison Anne.
> > > > > > >
> > > > > > > FYI there is a discussion underway on general@incubator.a.o
> that
> > > is
> > > > > > > relevant to this thread...
> > > > > > >
> > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-
> > > > > general/201608.mbox/%
> > > > > > > 3C5113b38e-e52b-0c16-eced-903e00fc4477%40apache.org%3E
> > > > > > >
> > > > > > > I mention it as I expect the Incubator PMC are likely to assess
> > > > Pirk's
> > > > > > > release by this criteria, given it will be fresh in people's
> mind
> > > > when
> > > > > > our
> > > > > > > vote is proposed.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Tim
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
Will do thanks.
Just to be clear -- the META-INF dir with the binary L&N files will be
removed and the binary-related L&N files will be moved to as assembly
directory (or something similar) when we break out the submodules. In the
meantime the META-INF (with binary L&N files) as in the PR will be merged
after adding the README as suggested. Folks will be responsible for
updating the binary L&N files as they add dependencies.
On Sat, Aug 20, 2016 at 12:41 PM, Suneel Marthi <su...@gmail.com>
wrote:
> +1
>
> On Sat, Aug 20, 2016 at 12:40 PM, Tim Ellison <t....@gmail.com>
> wrote:
>
> > On 20 August 2016 at 17:04, Ellison Anne Williams <
> > eawilliamspirk@gmail.com>
> > wrote:
> >
> > > Yes, if that's acceptable, then I can go that route.
> > >
> > > I can allow the artifacts to be generated and pushed to Nexus, I can
> > remove
> > > the binary artifacts, fix the L&N files, rehash/sign, and upload.
> Then, I
> > > can close the repo (which will run through all signing verifications)
> and
> > > provide the URL for voting. Once we get the submodules in place, the
> L&N
> > > file placement will be taken care of automatically for binary artifacts
> > and
> > > the manual intervention won't be necessary.
> > >
> > > Would it be OK to go ahead and merge the PR with the binary L&N files
> in
> > > the bin-license-notice dir in META-INF? That way, folks can be
> > responsible
> > > for keeping them updated as they add any new dependencies.
> > >
> >
> > That works for me. Unless other mentors object, I say we go with this
> > plan.
> >
> > To avoid any confusion you may want to consider creating a brief readme
> > file in the META-INF to explain that the L&N files in there only relate
> to
> > the exe-jar.
> >
> > Regards,
> > Tim
> >
> >
> >
> > > On Sat, Aug 20, 2016 at 11:51 AM, Tim Ellison <t....@gmail.com>
> > > wrote:
> > >
> > > > On 20 August 2016 at 16:23, Ellison Anne Williams <
> > > > eawilliamspirk@gmail.com>
> > > > wrote:
> > > >
> > > > > Thanks Tim - yes, I've been following that thread with interest. To
> > > speak
> > > > > to the documentation for Pirk releases, I have been working on a
> page
> > > for
> > > > > the website documenting our release process (and the gotchas)
> > > > step-by-step.
> > > > > Once we complete a successful release vote internally, I will put
> > forth
> > > > the
> > > > > page for comment. I agree with the discussion on the
> > general@incubator
> > > > > thread that the release process for a project needs to be
> documented
> > > such
> > > > > that anyone can walk into the project and complete a release - it
> > > > shouldn't
> > > > > be a mystical endeavor.
> > > >
> > > >
> > > > I don't know precisely what steps you are following at the moment,
> but
> > if
> > > > there is an opportunity to manually intervene and fix-up the binary
> JAR
> > > > licenses before the artefacts are hashed / signed / uploaded then
> that
> > > > could simply be a "documented step" until the scripts handle it all.
> > > >
> > > > ... or even produce the JAR, then
> > > > - delete the exe-jar's sig/hash
> > > > - rearrange the L&N files
> > > > - re-sign/hash
> > > >
> > > > Provided it is a repeatable process for the binaries, I think that
> > would
> > > be
> > > > ok.
> > > >
> > > > WDYT?
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > > >
> > > > > On Sat, Aug 20, 2016 at 10:58 AM, Tim Ellison <
> t.p.ellison@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > On 20 August 2016 at 04:52, Ellison Anne Williams <
> > > > > > eawilliamspirk@gmail.com>
> > > > > > 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!
> > > > > > >
> > > > > >
> > > > > > Sure. Thanks for your continued focus on this Ellison Anne.
> > > > > >
> > > > > > FYI there is a discussion underway on general@incubator.a.o that
> > is
> > > > > > relevant to this thread...
> > > > > >
> > > > > > http://mail-archives.apache.org/mod_mbox/incubator-
> > > > general/201608.mbox/%
> > > > > > 3C5113b38e-e52b-0c16-eced-903e00fc4477%40apache.org%3E
> > > > > >
> > > > > > I mention it as I expect the Incubator PMC are likely to assess
> > > Pirk's
> > > > > > release by this criteria, given it will be fresh in people's mind
> > > when
> > > > > our
> > > > > > vote is proposed.
> > > > > >
> > > > > > Regards,
> > > > > > Tim
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Suneel Marthi <su...@gmail.com>.
+1
On Sat, Aug 20, 2016 at 12:40 PM, Tim Ellison <t....@gmail.com> wrote:
> On 20 August 2016 at 17:04, Ellison Anne Williams <
> eawilliamspirk@gmail.com>
> wrote:
>
> > Yes, if that's acceptable, then I can go that route.
> >
> > I can allow the artifacts to be generated and pushed to Nexus, I can
> remove
> > the binary artifacts, fix the L&N files, rehash/sign, and upload. Then, I
> > can close the repo (which will run through all signing verifications) and
> > provide the URL for voting. Once we get the submodules in place, the L&N
> > file placement will be taken care of automatically for binary artifacts
> and
> > the manual intervention won't be necessary.
> >
> > Would it be OK to go ahead and merge the PR with the binary L&N files in
> > the bin-license-notice dir in META-INF? That way, folks can be
> responsible
> > for keeping them updated as they add any new dependencies.
> >
>
> That works for me. Unless other mentors object, I say we go with this
> plan.
>
> To avoid any confusion you may want to consider creating a brief readme
> file in the META-INF to explain that the L&N files in there only relate to
> the exe-jar.
>
> Regards,
> Tim
>
>
>
> > On Sat, Aug 20, 2016 at 11:51 AM, Tim Ellison <t....@gmail.com>
> > wrote:
> >
> > > On 20 August 2016 at 16:23, Ellison Anne Williams <
> > > eawilliamspirk@gmail.com>
> > > wrote:
> > >
> > > > Thanks Tim - yes, I've been following that thread with interest. To
> > speak
> > > > to the documentation for Pirk releases, I have been working on a page
> > for
> > > > the website documenting our release process (and the gotchas)
> > > step-by-step.
> > > > Once we complete a successful release vote internally, I will put
> forth
> > > the
> > > > page for comment. I agree with the discussion on the
> general@incubator
> > > > thread that the release process for a project needs to be documented
> > such
> > > > that anyone can walk into the project and complete a release - it
> > > shouldn't
> > > > be a mystical endeavor.
> > >
> > >
> > > I don't know precisely what steps you are following at the moment, but
> if
> > > there is an opportunity to manually intervene and fix-up the binary JAR
> > > licenses before the artefacts are hashed / signed / uploaded then that
> > > could simply be a "documented step" until the scripts handle it all.
> > >
> > > ... or even produce the JAR, then
> > > - delete the exe-jar's sig/hash
> > > - rearrange the L&N files
> > > - re-sign/hash
> > >
> > > Provided it is a repeatable process for the binaries, I think that
> would
> > be
> > > ok.
> > >
> > > WDYT?
> > >
> > > Regards,
> > > Tim
> > >
> > >
> > > > On Sat, Aug 20, 2016 at 10:58 AM, Tim Ellison <t.p.ellison@gmail.com
> >
> > > > wrote:
> > > >
> > > > > On 20 August 2016 at 04:52, Ellison Anne Williams <
> > > > > eawilliamspirk@gmail.com>
> > > > > 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!
> > > > > >
> > > > >
> > > > > Sure. Thanks for your continued focus on this Ellison Anne.
> > > > >
> > > > > FYI there is a discussion underway on general@incubator.a.o that
> is
> > > > > relevant to this thread...
> > > > >
> > > > > http://mail-archives.apache.org/mod_mbox/incubator-
> > > general/201608.mbox/%
> > > > > 3C5113b38e-e52b-0c16-eced-903e00fc4477%40apache.org%3E
> > > > >
> > > > > I mention it as I expect the Incubator PMC are likely to assess
> > Pirk's
> > > > > release by this criteria, given it will be fresh in people's mind
> > when
> > > > our
> > > > > vote is proposed.
> > > > >
> > > > > Regards,
> > > > > Tim
> > > > >
> > > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Tim Ellison <t....@gmail.com>.
On 20 August 2016 at 17:04, Ellison Anne Williams <ea...@gmail.com>
wrote:
> Yes, if that's acceptable, then I can go that route.
>
> I can allow the artifacts to be generated and pushed to Nexus, I can remove
> the binary artifacts, fix the L&N files, rehash/sign, and upload. Then, I
> can close the repo (which will run through all signing verifications) and
> provide the URL for voting. Once we get the submodules in place, the L&N
> file placement will be taken care of automatically for binary artifacts and
> the manual intervention won't be necessary.
>
> Would it be OK to go ahead and merge the PR with the binary L&N files in
> the bin-license-notice dir in META-INF? That way, folks can be responsible
> for keeping them updated as they add any new dependencies.
>
That works for me. Unless other mentors object, I say we go with this plan.
To avoid any confusion you may want to consider creating a brief readme
file in the META-INF to explain that the L&N files in there only relate to
the exe-jar.
Regards,
Tim
> On Sat, Aug 20, 2016 at 11:51 AM, Tim Ellison <t....@gmail.com>
> wrote:
>
> > On 20 August 2016 at 16:23, Ellison Anne Williams <
> > eawilliamspirk@gmail.com>
> > wrote:
> >
> > > Thanks Tim - yes, I've been following that thread with interest. To
> speak
> > > to the documentation for Pirk releases, I have been working on a page
> for
> > > the website documenting our release process (and the gotchas)
> > step-by-step.
> > > Once we complete a successful release vote internally, I will put forth
> > the
> > > page for comment. I agree with the discussion on the general@incubator
> > > thread that the release process for a project needs to be documented
> such
> > > that anyone can walk into the project and complete a release - it
> > shouldn't
> > > be a mystical endeavor.
> >
> >
> > I don't know precisely what steps you are following at the moment, but if
> > there is an opportunity to manually intervene and fix-up the binary JAR
> > licenses before the artefacts are hashed / signed / uploaded then that
> > could simply be a "documented step" until the scripts handle it all.
> >
> > ... or even produce the JAR, then
> > - delete the exe-jar's sig/hash
> > - rearrange the L&N files
> > - re-sign/hash
> >
> > Provided it is a repeatable process for the binaries, I think that would
> be
> > ok.
> >
> > WDYT?
> >
> > Regards,
> > Tim
> >
> >
> > > On Sat, Aug 20, 2016 at 10:58 AM, Tim Ellison <t....@gmail.com>
> > > wrote:
> > >
> > > > On 20 August 2016 at 04:52, Ellison Anne Williams <
> > > > eawilliamspirk@gmail.com>
> > > > 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!
> > > > >
> > > >
> > > > Sure. Thanks for your continued focus on this Ellison Anne.
> > > >
> > > > FYI there is a discussion underway on general@incubator.a.o that is
> > > > relevant to this thread...
> > > >
> > > > http://mail-archives.apache.org/mod_mbox/incubator-
> > general/201608.mbox/%
> > > > 3C5113b38e-e52b-0c16-eced-903e00fc4477%40apache.org%3E
> > > >
> > > > I mention it as I expect the Incubator PMC are likely to assess
> Pirk's
> > > > release by this criteria, given it will be fresh in people's mind
> when
> > > our
> > > > vote is proposed.
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
Yes, if that's acceptable, then I can go that route.
I can allow the artifacts to be generated and pushed to Nexus, I can remove
the binary artifacts, fix the L&N files, rehash/sign, and upload. Then, I
can close the repo (which will run through all signing verifications) and
provide the URL for voting. Once we get the submodules in place, the L&N
file placement will be taken care of automatically for binary artifacts and
the manual intervention won't be necessary.
Would it be OK to go ahead and merge the PR with the binary L&N files in
the bin-license-notice dir in META-INF? That way, folks can be responsible
for keeping them updated as they add any new dependencies.
On Sat, Aug 20, 2016 at 11:51 AM, Tim Ellison <t....@gmail.com> wrote:
> On 20 August 2016 at 16:23, Ellison Anne Williams <
> eawilliamspirk@gmail.com>
> wrote:
>
> > Thanks Tim - yes, I've been following that thread with interest. To speak
> > to the documentation for Pirk releases, I have been working on a page for
> > the website documenting our release process (and the gotchas)
> step-by-step.
> > Once we complete a successful release vote internally, I will put forth
> the
> > page for comment. I agree with the discussion on the general@incubator
> > thread that the release process for a project needs to be documented such
> > that anyone can walk into the project and complete a release - it
> shouldn't
> > be a mystical endeavor.
>
>
> I don't know precisely what steps you are following at the moment, but if
> there is an opportunity to manually intervene and fix-up the binary JAR
> licenses before the artefacts are hashed / signed / uploaded then that
> could simply be a "documented step" until the scripts handle it all.
>
> ... or even produce the JAR, then
> - delete the exe-jar's sig/hash
> - rearrange the L&N files
> - re-sign/hash
>
> Provided it is a repeatable process for the binaries, I think that would be
> ok.
>
> WDYT?
>
> Regards,
> Tim
>
>
> > On Sat, Aug 20, 2016 at 10:58 AM, Tim Ellison <t....@gmail.com>
> > wrote:
> >
> > > On 20 August 2016 at 04:52, Ellison Anne Williams <
> > > eawilliamspirk@gmail.com>
> > > 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!
> > > >
> > >
> > > Sure. Thanks for your continued focus on this Ellison Anne.
> > >
> > > FYI there is a discussion underway on general@incubator.a.o that is
> > > relevant to this thread...
> > >
> > > http://mail-archives.apache.org/mod_mbox/incubator-
> general/201608.mbox/%
> > > 3C5113b38e-e52b-0c16-eced-903e00fc4477%40apache.org%3E
> > >
> > > I mention it as I expect the Incubator PMC are likely to assess Pirk's
> > > release by this criteria, given it will be fresh in people's mind when
> > our
> > > vote is proposed.
> > >
> > > Regards,
> > > Tim
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Tim Ellison <t....@gmail.com>.
On 20 August 2016 at 16:23, Ellison Anne Williams <ea...@gmail.com>
wrote:
> Thanks Tim - yes, I've been following that thread with interest. To speak
> to the documentation for Pirk releases, I have been working on a page for
> the website documenting our release process (and the gotchas) step-by-step.
> Once we complete a successful release vote internally, I will put forth the
> page for comment. I agree with the discussion on the general@incubator
> thread that the release process for a project needs to be documented such
> that anyone can walk into the project and complete a release - it shouldn't
> be a mystical endeavor.
I don't know precisely what steps you are following at the moment, but if
there is an opportunity to manually intervene and fix-up the binary JAR
licenses before the artefacts are hashed / signed / uploaded then that
could simply be a "documented step" until the scripts handle it all.
... or even produce the JAR, then
- delete the exe-jar's sig/hash
- rearrange the L&N files
- re-sign/hash
Provided it is a repeatable process for the binaries, I think that would be
ok.
WDYT?
Regards,
Tim
> On Sat, Aug 20, 2016 at 10:58 AM, Tim Ellison <t....@gmail.com>
> wrote:
>
> > On 20 August 2016 at 04:52, Ellison Anne Williams <
> > eawilliamspirk@gmail.com>
> > 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!
> > >
> >
> > Sure. Thanks for your continued focus on this Ellison Anne.
> >
> > FYI there is a discussion underway on general@incubator.a.o that is
> > relevant to this thread...
> >
> > http://mail-archives.apache.org/mod_mbox/incubator-general/201608.mbox/%
> > 3C5113b38e-e52b-0c16-eced-903e00fc4477%40apache.org%3E
> >
> > I mention it as I expect the Incubator PMC are likely to assess Pirk's
> > release by this criteria, given it will be fresh in people's mind when
> our
> > vote is proposed.
> >
> > Regards,
> > Tim
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
Thanks Tim - yes, I've been following that thread with interest. To speak
to the documentation for Pirk releases, I have been working on a page for
the website documenting our release process (and the gotchas) step-by-step.
Once we complete a successful release vote internally, I will put forth the
page for comment. I agree with the discussion on the general@incubator
thread that the release process for a project needs to be documented such
that anyone can walk into the project and complete a release - it shouldn't
be a mystical endeavor.
On Sat, Aug 20, 2016 at 10:58 AM, Tim Ellison <t....@gmail.com> wrote:
> On 20 August 2016 at 04:52, Ellison Anne Williams <
> eawilliamspirk@gmail.com>
> 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!
> >
>
> Sure. Thanks for your continued focus on this Ellison Anne.
>
> FYI there is a discussion underway on general@incubator.a.o that is
> relevant to this thread...
>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201608.mbox/%
> 3C5113b38e-e52b-0c16-eced-903e00fc4477%40apache.org%3E
>
> I mention it as I expect the Incubator PMC are likely to assess Pirk's
> release by this criteria, given it will be fresh in people's mind when our
> vote is proposed.
>
> Regards,
> Tim
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Tim Ellison <t....@gmail.com>.
On 20 August 2016 at 04:52, Ellison Anne Williams <ea...@gmail.com>
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!
>
Sure. Thanks for your continued focus on this Ellison Anne.
FYI there is a discussion underway on general@incubator.a.o that is
relevant to this thread...
http://mail-archives.apache.org/mod_mbox/incubator-general/201608.mbox/%3C5113b38e-e52b-0c16-eced-903e00fc4477%40apache.org%3E
I mention it as I expect the Incubator PMC are likely to assess Pirk's
release by this criteria, given it will be fresh in people's mind when our
vote is proposed.
Regards,
Tim
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
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 <
eawilliamspirk@gmail.com> 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 <su...@gmail.com>
> 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 <
>> eawilliamspirk@gmail.com> 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 <
>> suneel.marthi@gmail.com>
>> > 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 <
>> > > eawilliamspirk@gmail.com> 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 <
>> t.p.ellison@gmail.com>
>> > > > 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 <
>> > smarthi@apache.org>
>> > > > > wrote:
>> > > > > >
>> > > > > >> On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <
>> > > t.p.ellison@gmail.com>
>> > > > > >> 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.
>> > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
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 <su...@gmail.com>
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 <
> eawilliamspirk@gmail.com> 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 <suneel.marthi@gmail.com
> >
> > 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 <
> > > eawilliamspirk@gmail.com> 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 <t.p.ellison@gmail.com
> >
> > > > 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 <
> > smarthi@apache.org>
> > > > > wrote:
> > > > > >
> > > > > >> On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <
> > > t.p.ellison@gmail.com>
> > > > > >> 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.
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Suneel Marthi <su...@gmail.com>.
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 <
eawilliamspirk@gmail.com> 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 <su...@gmail.com>
> 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 <
> > eawilliamspirk@gmail.com> 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 <t....@gmail.com>
> > > 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 <
> smarthi@apache.org>
> > > > wrote:
> > > > >
> > > > >> On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <
> > t.p.ellison@gmail.com>
> > > > >> 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.
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
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 <su...@gmail.com>
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 <
> eawilliamspirk@gmail.com> 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 <t....@gmail.com>
> > 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 <sm...@apache.org>
> > > wrote:
> > > >
> > > >> On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <
> t.p.ellison@gmail.com>
> > > >> 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.
> > > >>
> > > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Suneel Marthi <su...@gmail.com>.
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 <
eawilliamspirk@gmail.com> 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 <t....@gmail.com>
> 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 <sm...@apache.org>
> > wrote:
> > >
> > >> On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <t....@gmail.com>
> > >> 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.
> > >>
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
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 <t....@gmail.com> 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 <sm...@apache.org>
> wrote:
> >
> >> On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <t....@gmail.com>
> >> 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.
> >>
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Tim Ellison <t....@gmail.com>.
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 <sm...@apache.org> wrote:
>
>> On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <t....@gmail.com>
>> 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.
>>
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
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 <sm...@apache.org> wrote:
> On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <t....@gmail.com>
> 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.
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Suneel Marthi <sm...@apache.org>.
Apologies!! I ranted a little too soon (I am in a Samuel Jackson state of
mind - "Say License One more Time and ....."
Addressing the issues raised below :
1. exclude /logs from source-release.zip - easy fix
2. /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
easy fix
3. Why do we have META-INF/bin-license-notice instead of just META-INF ?
I'll address (1).
On Fri, Aug 19, 2016 at 10:53 AM, Suneel Marthi <sm...@apache.org> wrote:
>
>
> On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <t....@gmail.com>
> 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.
>
>>
>
>
>> 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.
>>
>> 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
>>
>>
>> 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.
>
>
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Suneel Marthi <sm...@apache.org>.
I agree we need to split the project into multiple modules as we have
support for Spark, Storm etc.. coming in. Would it also make sense to make
responder and querier their own modules and publishing those jars to maven
central? Would there be a Use Case wherein Responder would be needed in a
3rd party application as a library jar ?
Creating an 'assembly' module would definitely address most of the
packaging issues and is much cleaner than what we have now.
On Fri, Aug 19, 2016 at 11:20 AM, Ellison Anne Williams <
eawilliamspirk@gmail.com> wrote:
> I think that our first release should be a 'complete' one, including the
> binary artifacts, but I don't think that it has to be the most pristine on
> the L&N front as long as we meet the ASF L&N requirements (which, as far as
> I can tell, is far more than most Apache projects ;)). We can make the
> 'cleanup L&N placement' a task for release #(1 + n) where n is small. This
> seems to go hand-in-hand with a submodule refactor which won't happen for
> this release... (please correct me if you think that we can clean the L&N
> situation without the submodule refactor)
>
> Please see the specific comment that I sent a few minutes ago.
>
> Thanks!
>
>
> On Fri, Aug 19, 2016 at 11:16 AM, Suneel Marthi <su...@gmail.com>
> wrote:
>
> > On Fri, Aug 19, 2016 at 11:13 AM, Tim Ellison <t....@gmail.com>
> > wrote:
> >
> > > On 19/08/16 15:53, Suneel Marthi wrote:
> > > > On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <t.p.ellison@gmail.com
> >
> > > wrote:
> > > <snip>
> > > >> 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.
> > >
> > > The main release artefact (apache-pirk-0.0.2-source-release.zip) is
> > > looking good. I think there is a good argument to publish this as the
> > > first project release, and work on the convenience binaries to be
> > > included with the next release.
> > >
> >
> > I can confirm that the logs/ are being packaged into the sources.zip and
> > need to be excluded when building that artifact. I'll take a stab at
> this.
> >
> >
> > >
> > > It may be that the content of the next release is primarily the
> > > inclusion of the convenience binaries, and it happens within a few
> > > weeks. I don't see a problem with that.
> > >
> > > However, Ellison Anne was up for tackling the L&N's this time around,
> so
> > > I'm not going to stand in the way of that. There's no rush.
> > >
> > > Regards,
> > > Tim
> > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
I think that our first release should be a 'complete' one, including the
binary artifacts, but I don't think that it has to be the most pristine on
the L&N front as long as we meet the ASF L&N requirements (which, as far as
I can tell, is far more than most Apache projects ;)). We can make the
'cleanup L&N placement' a task for release #(1 + n) where n is small. This
seems to go hand-in-hand with a submodule refactor which won't happen for
this release... (please correct me if you think that we can clean the L&N
situation without the submodule refactor)
Please see the specific comment that I sent a few minutes ago.
Thanks!
On Fri, Aug 19, 2016 at 11:16 AM, Suneel Marthi <su...@gmail.com>
wrote:
> On Fri, Aug 19, 2016 at 11:13 AM, Tim Ellison <t....@gmail.com>
> wrote:
>
> > On 19/08/16 15:53, Suneel Marthi wrote:
> > > On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <t....@gmail.com>
> > wrote:
> > <snip>
> > >> 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.
> >
> > The main release artefact (apache-pirk-0.0.2-source-release.zip) is
> > looking good. I think there is a good argument to publish this as the
> > first project release, and work on the convenience binaries to be
> > included with the next release.
> >
>
> I can confirm that the logs/ are being packaged into the sources.zip and
> need to be excluded when building that artifact. I'll take a stab at this.
>
>
> >
> > It may be that the content of the next release is primarily the
> > inclusion of the convenience binaries, and it happens within a few
> > weeks. I don't see a problem with that.
> >
> > However, Ellison Anne was up for tackling the L&N's this time around, so
> > I'm not going to stand in the way of that. There's no rush.
> >
> > Regards,
> > Tim
> >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Suneel Marthi <su...@gmail.com>.
On Fri, Aug 19, 2016 at 11:13 AM, Tim Ellison <t....@gmail.com> wrote:
> On 19/08/16 15:53, Suneel Marthi wrote:
> > On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <t....@gmail.com>
> wrote:
> <snip>
> >> 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.
>
> The main release artefact (apache-pirk-0.0.2-source-release.zip) is
> looking good. I think there is a good argument to publish this as the
> first project release, and work on the convenience binaries to be
> included with the next release.
>
I can confirm that the logs/ are being packaged into the sources.zip and
need to be excluded when building that artifact. I'll take a stab at this.
>
> It may be that the content of the next release is primarily the
> inclusion of the convenience binaries, and it happens within a few
> weeks. I don't see a problem with that.
>
> However, Ellison Anne was up for tackling the L&N's this time around, so
> I'm not going to stand in the way of that. There's no rush.
>
> Regards,
> Tim
>
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Tim Ellison <t....@gmail.com>.
On 19/08/16 15:53, Suneel Marthi wrote:
> On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <t....@gmail.com> wrote:
<snip>
>> 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.
The main release artefact (apache-pirk-0.0.2-source-release.zip) is
looking good. I think there is a good argument to publish this as the
first project release, and work on the convenience binaries to be
included with the next release.
It may be that the content of the next release is primarily the
inclusion of the convenience binaries, and it happens within a few
weeks. I don't see a problem with that.
However, Ellison Anne was up for tackling the L&N's this time around, so
I'm not going to stand in the way of that. There's no rush.
Regards,
Tim
Re: Source JAR vs. Convenience binary JAR license files
Posted by Suneel Marthi <sm...@apache.org>.
On Fri, Aug 19, 2016 at 10:13 AM, Tim Ellison <t....@gmail.com> 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.
>
> 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.
>
> 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
>
>
> 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.
Re: Source JAR vs. Convenience binary JAR license files
Posted by Tim Ellison <t....@gmail.com>.
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
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.
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
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.
Regards,
Tim
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
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 <
eawilliamspirk@gmail.com> 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 <t....@gmail.com>
> 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 <bi...@apache.org>
>> 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 <
>> >> eawilliamspirk@gmail.com> 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 <bi...@apache.org>
>> >>> 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 <t....@gmail.com>
>> >>>> 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 <
>> >>>> suneel.marthi@gmail.com
>> >>>>>>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <
>> >>> t.p.ellison@gmail.com>
>> >>>>>>> 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
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
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 <t....@gmail.com> 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 <bi...@apache.org>
> 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 <
> >> eawilliamspirk@gmail.com> 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 <bi...@apache.org>
> >>> 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 <t....@gmail.com>
> >>>> 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 <
> >>>> suneel.marthi@gmail.com
> >>>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <
> >>> t.p.ellison@gmail.com>
> >>>>>>> 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
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Tim Ellison <t....@gmail.com>.
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 <bi...@apache.org> 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 <
>> eawilliamspirk@gmail.com> 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 <bi...@apache.org>
>>> 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 <t....@gmail.com>
>>>> 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 <
>>>> suneel.marthi@gmail.com
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <
>>> t.p.ellison@gmail.com>
>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
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 <bi...@apache.org> 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 <
> eawilliamspirk@gmail.com> 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 <bi...@apache.org>
> > 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 <t....@gmail.com>
> > > 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 <
> > > suneel.marthi@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <
> > t.p.ellison@gmail.com>
> > > > >> 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
> > > > >>>
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Billie Rinaldi <bi...@apache.org>.
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 <
eawilliamspirk@gmail.com> 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 <bi...@apache.org>
> 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 <t....@gmail.com>
> > 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 <
> > suneel.marthi@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <
> t.p.ellison@gmail.com>
> > > >> 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
> > > >>>
> > > >>
> > > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Joe Witt <jo...@gmail.com>.
A given bundle of things must have L&N that accounts for all things in that
bundle of things. That is all.
On Aug 17, 2016 11:25 AM, "Ellison Anne Williams" <ea...@gmail.com>
wrote:
Yes -- the source release would fall into case (2) below and the
convenience binary (executable jar) would fall into case (1).
Is this correct?
On Wed, Aug 17, 2016 at 2:22 PM, Joe Witt <jo...@gmail.com> wrote:
> The zip of the source is the source release. That is not a binary
> convenience artifact.
>
> On Aug 17, 2016 11:04 AM, "Ellison Anne Williams" <
> eawilliamspirk@gmail.com>
> 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 <bi...@apache.org>
> > 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 <t....@gmail.com>
> > > 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 <
> > > suneel.marthi@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <
> > t.p.ellison@gmail.com>
> > > > >> 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
> > > > >>>
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
Yes -- the source release would fall into case (2) below and the
convenience binary (executable jar) would fall into case (1).
Is this correct?
On Wed, Aug 17, 2016 at 2:22 PM, Joe Witt <jo...@gmail.com> wrote:
> The zip of the source is the source release. That is not a binary
> convenience artifact.
>
> On Aug 17, 2016 11:04 AM, "Ellison Anne Williams" <
> eawilliamspirk@gmail.com>
> 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 <bi...@apache.org>
> > 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 <t....@gmail.com>
> > > 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 <
> > > suneel.marthi@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <
> > t.p.ellison@gmail.com>
> > > > >> 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
> > > > >>>
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Joe Witt <jo...@gmail.com>.
The zip of the source is the source release. That is not a binary
convenience artifact.
On Aug 17, 2016 11:04 AM, "Ellison Anne Williams" <ea...@gmail.com>
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 <bi...@apache.org>
> 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 <t....@gmail.com>
> > 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 <
> > suneel.marthi@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <
> t.p.ellison@gmail.com>
> > > >> 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
> > > >>>
> > > >>
> > > >
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Tim Ellison <t....@gmail.com>.
On 17/08/16 19:04, Ellison Anne Williams 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)
Yes (with the caveat below).
> 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
Yes.
> 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?
It needs to be the other way around, that is the L&N files in the _root_
of the Pirk repository should reflect our managed source code (i.e. (2)
above), so that as people look at the repo, and clone it they see the
correct L&Ns.
The L&N files, accurately representing the results of building Pirk, can
be pulled in from a subdirectory and appear in the root of the exe JAR [1].
At the moment, PR#65 is looking to put the binary L&N files into the top
of the repository, and that is not correct.
[1] or the META-INF/ dir if that is how we need to do it, but root would
be preferable IMHO. Of course, the source L&Ns would not appear in the
binary JARs.
Regards,
Tim
> 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 <bi...@apache.org> 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 <t....@gmail.com>
>> 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 <
>> suneel.marthi@gmail.com
>>>>
>>>> wrote:
>>>>
>>>>> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <t....@gmail.com>
>>>>> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Ellison Anne Williams <ea...@gmail.com>.
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 <bi...@apache.org> 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 <t....@gmail.com>
> 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 <
> suneel.marthi@gmail.com
> > >
> > > wrote:
> > >
> > >> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <t....@gmail.com>
> > >> 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
> > >>>
> > >>
> > >
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Billie Rinaldi <bi...@apache.org>.
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 <t....@gmail.com> 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 <suneel.marthi@gmail.com
> >
> > wrote:
> >
> >> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <t....@gmail.com>
> >> 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
> >>>
> >>
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Tim Ellison <t....@gmail.com>.
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 <su...@gmail.com>
> wrote:
>
>> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <t....@gmail.com>
>> 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
>>>
>>
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Joe Witt <jo...@gmail.com>.
Hello,
The link Tim provided to the licesning guide NiFi uses is definitely a
great place to start as it brings together a bunch of ASF policy
and/or guidance and applies it to the context of Apache NiFi, what we
release, and our bundling model.
Whether this is a strict policy or not is clear - yes. The basic gist is:
- For any artifact you publish it must have appropriate L&N.
The other basic gist:
- If it seems easy you're probably doing it wrong.
Officially Apache Software Foundation releases are 'source releases
only'. This is the top level L&N that all projects have and as TIm
mentioned that covers anything in your source tree (has nothing to do
with dependencies pulled it during the build or runtime).
Some projects only end up having this top level source L&N and it is
because they also only provide source and they don't publish the
artifacts. By not publishing any derived binary artifacts they are
not having to worry about this though for such cases consider that
community formation is dependent on people who can adequately take the
source and produce a workable build.
Some other projects who do produce convenience binaries (such as a
zip, tar.gz, jars published to maven) also only end up top level
source L&N. This either means they have no dependencies or they're
'doin it wrong'. I've found awareness and or consideration for L&N to
be uneven though there seems to be increasing awareness here. People
like Billie, Josh, Sean, myself and perhaps most notably Justin McLean
are are definitely helping in this arena.
Now, many projects do elect to provide convenience binaries and again
you have to account for the L&N of each artifact you produce. We have
L&N files all over the place in our codebase in NiFi. The Top level
L&N accounts for source and all others account for the binary artifact
that would be produced. There are *huge* differences between our
NOTICE at the top level source and in the nifi-assembly for example.
You can ensure that an overriden L&N ends up in your uber jar pretty
easily by placing it into the correct META-INF location of your source
tree. See here [1] for an example.
Finally, I'll add that it is possible we're not doing it correctly in
NiFi. We could be overdoing it, under doing it, etc. It is just not
easy and everyone ultimately will say "IANAL". The community
consensus of 'ok this looks about right is key here'. So lets just
keep iterating on it. The uber jar must have an L&N that accounts for
all the things that get bundled in it.
[1] https://github.com/apache/nifi/blob/6de738fd04f773ba6b05b3768c5214847b55cf50/nifi-nar-bundles/nifi-update-attribute-bundle/nifi-update-attribute-nar/src/main/resources/META-INF/NOTICE
On Wed, Aug 17, 2016 at 8:13 AM, Tim Ellison <t....@gmail.com> 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
>>
>> 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.
>
> If we don't get a local answer, let's ask on general@incubator. The
> Foundation policy seems clear enough to me, and I agree that it appears
> that many projects are not following it -- so something is wrong.
>
> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
> http://www.apache.org/dev/licensing-howto.html#binary
>
> Regards,
> Tim
>
>
>> On Wed, Aug 17, 2016 at 10:55 AM, Suneel Marthi <su...@gmail.com>
>> wrote:
>>
>>> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <t....@gmail.com>
>>> 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
>>>>
>>>
>>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Billie Rinaldi <bi...@apache.org>.
Yes, we should have different L&N in different jars when necessary, and
this is possible to configure through maven. That said, I haven't done it
myself, so I'll have to track down some examples of other projects that do
this.
On Wed, Aug 17, 2016 at 8:13 AM, Tim Ellison <t....@gmail.com> 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
> >
> > 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.
>
> If we don't get a local answer, let's ask on general@incubator. The
> Foundation policy seems clear enough to me, and I agree that it appears
> that many projects are not following it -- so something is wrong.
>
> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
> http://www.apache.org/dev/licensing-howto.html#binary
>
> Regards,
> Tim
>
>
> > On Wed, Aug 17, 2016 at 10:55 AM, Suneel Marthi <suneel.marthi@gmail.com
> >
> > wrote:
> >
> >> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <t....@gmail.com>
> >> 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
> >>>
> >>
> >
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Tim Ellison <t....@gmail.com>.
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
>
> 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.
If we don't get a local answer, let's ask on general@incubator. The
Foundation policy seems clear enough to me, and I agree that it appears
that many projects are not following it -- so something is wrong.
http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
http://www.apache.org/dev/licensing-howto.html#binary
Regards,
Tim
> On Wed, Aug 17, 2016 at 10:55 AM, Suneel Marthi <su...@gmail.com>
> wrote:
>
>> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <t....@gmail.com>
>> 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
>>>
>>
>
Re: Source JAR vs. Convenience binary JAR license files (was: Re:
[GitHub] incubator-pirk pull request #65: [PIRK-53] - Fix LICENSE and NOTICE
Files fo...)
Posted by Ellison Anne Williams <ea...@gmail.com>.
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
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 <su...@gmail.com>
wrote:
> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <t....@gmail.com>
> 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
> >
>
Re: Source JAR vs. Convenience binary JAR license files (was: Re:
[GitHub] incubator-pirk pull request #65: [PIRK-53] - Fix LICENSE and NOTICE
Files fo...)
Posted by Suneel Marthi <su...@gmail.com>.
On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <t....@gmail.com> 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
>
Source JAR vs. Convenience binary JAR license files (was: Re:
[GitHub] incubator-pirk pull request #65: [PIRK-53] - Fix LICENSE and NOTICE
Files fo...)
Posted by Tim Ellison <t....@gmail.com>.
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 :-(
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
[GitHub] incubator-pirk pull request #65: [PIRK-53] - Fix LICENSE and NOTICE Files fo...
Posted by ellisonanne <gi...@git.apache.org>.
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?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk issue #65: [PIRK-53] - Fix LICENSE and NOTICE Files for Relea...
Posted by ellisonanne <gi...@git.apache.org>.
Github user ellisonanne commented on the issue:
https://github.com/apache/incubator-pirk/pull/65
Strange... it's back now.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk pull request #65: [PIRK-53] [WIP] - Fix LICENSE and NOTICE Fi...
Posted by ellisonanne <gi...@git.apache.org>.
Github user ellisonanne commented on a diff in the pull request:
https://github.com/apache/incubator-pirk/pull/65#discussion_r75311878
--- Diff: src/main/resources/META-INF/bin-license-notice/NOTICE-bin ---
@@ -0,0 +1,278 @@
+Apache Pirk (incubating)
+Copyright 2016 The Apache Software Foundation
+
+This product includes software developed at
+The Apache Software Foundation (http://www.apache.org/).
+
+========================================================================
+Common Development and Distribution License 1.0
+========================================================================
+
+The following components are provided under the Common Development and Distribution License 1.0. See project link for details.
+
+ (Common Development and Distribution License (CDDL) v1.0) JavaBeans Activation Framework (JAF) (javax.activation:activation:1.1 - http://java.sun.com/products/javabeans/jaf/index.jsp)
+ (COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0) (GNU General Public Library) Streaming API for XML (javax.xml.stream:stax-api:1.0-2 - no url defined)
+ (CDDL 1.0) Glassfish Jasper (org.mortbay.jetty:jsp-2.1:6.1.14 - http://jetty.mortbay.org/project/modules/jsp-2.1)
+ (CDDL 1.0) Servlet Specification 2.5 API (org.mortbay.jetty:servlet-api-2.5:6.1.14 - http://jetty.mortbay.org/project/modules/servlet-api-2.5)
+
+
+========================================================================
+Common Development and Distribution License 1.1
+========================================================================
+
+The following components are provided under the Common Development and Distribution License 1.1. See project link for details.
+
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-client (com.sun.jersey:jersey-client:1.9 - https://jersey.java.net/jersey-client/)
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-core (com.sun.jersey:jersey-core:1.9 - https://jersey.java.net/jersey-core/)
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-json (com.sun.jersey:jersey-json:1.9 - https://jersey.java.net/jersey-json/)
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-server (com.sun.jersey:jersey-server:1.9 - https://jersey.java.net/jersey-server/)
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-guice (com.sun.jersey.contribs:jersey-guice:1.9 - https://jersey.java.net/jersey-contribs/jersey-guice/)
+ (CDDL 1.1) (GPL2 w/ CPE) JAXB RI (com.sun.xml.bind:jaxb-impl:2.2.3-1 - http://jaxb.java.net/)
+ (CDDL 1.1) (GPL2 w/ CPE) JAXB API bundle for GlassFish V3 (javax.xml.bind:jaxb-api:2.2.2 - https://jaxb.dev.java.net/)
+
+
+========================================================================
+Eclipse Public License 1.0
+========================================================================
+
+The following components are provided under the Eclipse Public License 1.0. See project link for details.
+
+ (Eclipse Public License 1.0) JUnit (junit:junit:4.12 - http://junit.org)
+ (Eclipse Public License v1.0) Eclipse JDT Core (org.eclipse.jdt:core:3.1.1 - http://www.eclipse.org/jdt/)
+
+
+========================================================================
+NOTICE files
+========================================================================
+
+The following NOTICEs are pertain to software distributed with this project.
+
+-------------------------------------------------------------------------------
+ NOTICE file for direct Apache licensed software dependencies corresponding to
+ the section 4d of The Apache License, Version 2.0
+-------------------------------------------------------------------------------
+
+Apache Commons Math (http://commons.apache.org/proper/commons-math/)
+Copyright 2001-2016 The Apache Software Foundation
+
+json-simple (https://github.com/fangyidong/json-simple)
+The Apache Software Foundation
+
+Apache Hadoop (http://hadoop.apache.org/)
+The Apache Software Foundation
+
+Apache Spark (http://spark.apache.org/)
+Copyright 2014 and onwards The Apache Software Foundation
+
+Elasticsearch for Apache Hadoop (https://github.com/elastic/elasticsearch-hadoop)
+Copyright 2009-2016 The Apache Software Foundation
+
+jna-gmp (https://github.com/square/jna-gmp)
+The Apache Software Foundation
+
+Apache log4j (http://logging.apache.org/log4j/2.x/)
+The Apache Software Foundation
+
+
--- End diff --
Not until we actually bring them into Pirk
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk pull request #65: [PIRK-53] - Fix LICENSE and NOTICE Files fo...
Posted by tellison <gi...@git.apache.org>.
Github user tellison commented on a diff in the pull request:
https://github.com/apache/incubator-pirk/pull/65#discussion_r75086172
--- 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.
+
+
+========================================================================
+BSD-style licenses
+========================================================================
+
+The following components are provided under a BSD-style license. See project link for details.
+The text of each license is also included at licenses/LICENSE-[project].txt.
--- End diff --
I don't see the ```licenses/``` directory being included in this PR?
We really do need to include the actual text of the 3rd-party dependency licenses in our source distribution.
See http://www.apache.org/dev/licensing-howto.html#permissive-deps.
It's not quite one for _each_ of the Maven dependencies, things like Scala {compiler, library, parser, xml} are covered by a single license.
For an example, see Spark's [LICENSE](https://github.com/apache/spark/blob/master/LICENSE) and [licenses/ directory](https://github.com/apache/spark/tree/master/licenses).
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk pull request #65: [PIRK-53] - Fix LICENSE and NOTICE Files fo...
Posted by tellison <gi...@git.apache.org>.
Github user tellison commented on a diff in the pull request:
https://github.com/apache/incubator-pirk/pull/65#discussion_r75086109
--- 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 --
Just so there is no misunderstanding here, these LICENSE and NOTICE file changes are only to be included in the exe JAR, that bundles all the 3rd-party dependencies together as a convenience for the end user.
In our single project source JAR (```apache-pirk-x.x.x-incubating-sources.jar```), and Pirk-only binary (```apache-pirk-x.x.x-incubating.jar```), these LICENSE/NOTICE modifications must not appear. There will be different LICENSE and NOTICE files for the source and binary artefacts.
Ref: http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk pull request #65: [PIRK-53] - Fix LICENSE and NOTICE Files fo...
Posted by ellisonanne <gi...@git.apache.org>.
Github user ellisonanne commented on a diff in the pull request:
https://github.com/apache/incubator-pirk/pull/65#discussion_r75099716
--- 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.
+
+
+========================================================================
+BSD-style licenses
+========================================================================
+
+The following components are provided under a BSD-style license. See project link for details.
+The text of each license is also included at licenses/LICENSE-[project].txt.
--- End diff --
I will add a license directory
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk issue #65: [PIRK-53] - Fix LICENSE and NOTICE Files for Relea...
Posted by tellison <gi...@git.apache.org>.
Github user tellison commented on the issue:
https://github.com/apache/incubator-pirk/pull/65
Where did the ```licenses/``` directory go?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk issue #65: [PIRK-53] - Fix LICENSE and NOTICE Files for Relea...
Posted by ellisonanne <gi...@git.apache.org>.
Github user ellisonanne commented on the issue:
https://github.com/apache/incubator-pirk/pull/65
Just updated pom to exclude licenses during RAT checks
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk pull request #65: [PIRK-53] - Fix LICENSE and NOTICE Files fo...
Posted by smarthi <gi...@git.apache.org>.
Github user smarthi commented on a diff in the pull request:
https://github.com/apache/incubator-pirk/pull/65#discussion_r74978114
--- Diff: NOTICE ---
@@ -3,3 +3,276 @@ Copyright 2016 The Apache Software Foundation
This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).
+
+========================================================================
+Common Development and Distribution License 1.0
+========================================================================
+
+The following components are provided under the Common Development and Distribution License 1.0. See project link for details.
+
+ (Common Development and Distribution License (CDDL) v1.0) JavaBeans Activation Framework (JAF) (javax.activation:activation:1.1 - http://java.sun.com/products/javabeans/jaf/index.jsp)
+ (COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0) (GNU General Public Library) Streaming API for XML (javax.xml.stream:stax-api:1.0-2 - no url defined)
+ (CDDL 1.0) Glassfish Jasper (org.mortbay.jetty:jsp-2.1:6.1.14 - http://jetty.mortbay.org/project/modules/jsp-2.1)
--- End diff --
Do we have these 2 in Pirk, I think not. Moreover Servlet 2.5 is so 2005.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
Re: [GitHub] incubator-pirk issue #65: [PIRK-53] [WIP] - Fix LICENSE
and NOTICE Files for...
Posted by Tim Ellison <t....@gmail.com>.
I'll answer on the other mail thread "Re: Source JAR vs. Convenience
binary JAR license files"
On 19/08/16 13:15, Ellison Anne Williams wrote:
> Yes, the PR is ready. As in the email that I sent yesterday, it's not the
> most elegant solution, but it seems to satisfy the requirements.
>
> On Fri, Aug 19, 2016 at 6:54 AM, Tim Ellison <t....@gmail.com> wrote:
>
>> On 18/08/16 18:53, smarthi wrote:
>>> Github user smarthi commented on the issue:
>>>
>>> https://github.com/apache/incubator-pirk/pull/65
>>>
>>> +1 to merge, given that most of the feedback has been addressed now.
>>
>> Really? I have not done a thorough review, but a quick build of
>> remotes/ellisonanne/pirk-53 looked like there is still more to do.
>>
>> I'm waiting for Ellison Anne to declare when the PR is ready for further
>> scrutiny.
>>
>> Regards,
>> Tim
>>
>
Re: [GitHub] incubator-pirk issue #65: [PIRK-53] [WIP] - Fix LICENSE
and NOTICE Files for...
Posted by Ellison Anne Williams <ea...@gmail.com>.
Yes, the PR is ready. As in the email that I sent yesterday, it's not the
most elegant solution, but it seems to satisfy the requirements.
On Fri, Aug 19, 2016 at 6:54 AM, Tim Ellison <t....@gmail.com> wrote:
> On 18/08/16 18:53, smarthi wrote:
> > Github user smarthi commented on the issue:
> >
> > https://github.com/apache/incubator-pirk/pull/65
> >
> > +1 to merge, given that most of the feedback has been addressed now.
>
> Really? I have not done a thorough review, but a quick build of
> remotes/ellisonanne/pirk-53 looked like there is still more to do.
>
> I'm waiting for Ellison Anne to declare when the PR is ready for further
> scrutiny.
>
> Regards,
> Tim
>
Re: [GitHub] incubator-pirk issue #65: [PIRK-53] [WIP] - Fix LICENSE
and NOTICE Files for...
Posted by Tim Ellison <t....@gmail.com>.
On 18/08/16 18:53, smarthi wrote:
> Github user smarthi commented on the issue:
>
> https://github.com/apache/incubator-pirk/pull/65
>
> +1 to merge, given that most of the feedback has been addressed now.
Really? I have not done a thorough review, but a quick build of
remotes/ellisonanne/pirk-53 looked like there is still more to do.
I'm waiting for Ellison Anne to declare when the PR is ready for further
scrutiny.
Regards,
Tim
[GitHub] incubator-pirk issue #65: [PIRK-53] [WIP] - Fix LICENSE and NOTICE Files for...
Posted by smarthi <gi...@git.apache.org>.
Github user smarthi commented on the issue:
https://github.com/apache/incubator-pirk/pull/65
+1 to merge, given that most of the feedback has been addressed now.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk pull request #65: [PIRK-53] - Fix LICENSE and NOTICE Files fo...
Posted by ellisonanne <gi...@git.apache.org>.
Github user ellisonanne commented on a diff in the pull request:
https://github.com/apache/incubator-pirk/pull/65#discussion_r75099886
--- 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.
+
+
+========================================================================
+BSD-style licenses
+========================================================================
+
+The following components are provided under a BSD-style license. See project link for details.
+The text of each license is also included at licenses/LICENSE-[project].txt.
+
+ (BSD License) AntLR Parser Generator (antlr:antlr:2.7.7 - http://www.antlr.org/)
+ (New BSD License) Kryo (com.esotericsoftware.kryo:kryo:2.21 - http://code.google.com/p/kryo/)
+ (New BSD License) MinLog (com.esotericsoftware.minlog:minlog:1.2 - http://code.google.com/p/minlog/)
+ (New BSD License) ReflectASM (com.esotericsoftware.reflectasm:reflectasm:1.07 - http://code.google.com/p/reflectasm/)
+ (New BSD license) Protocol Buffer Java API (com.google.protobuf:protobuf-java:2.5.0 - http://code.google.com/p/protobuf)
+ (BSD) JSch (com.jcraft:jsch:0.1.42 - http://www.jcraft.com/jsch/)
+ (BSD) ParaNamer Core (com.thoughtworks.paranamer:paranamer:2.3 - http://paranamer.codehaus.org/paranamer)
+ (BSD) Automaton (dk.brics.automaton:automaton:1.11-8 - http://www.brics.dk/automaton/)
+ (BSD) JLine (jline:jline:1.0 - http://jline.sourceforge.net)
+ (The New BSD License) Py4J (net.sf.py4j:py4j:0.9 - http://www.py4j.org/)
+ (BSD licence) ANTLR ST4 4.0.4 (org.antlr:ST4:4.0.4 - http://www.stringtemplate.org)
+ (BSD licence) ANTLR StringTemplate (org.antlr:stringtemplate:3.2.1 - http://www.stringtemplate.org)
+ (New BSD License) Commons Compiler (org.codehaus.janino:commons-compiler:2.7.8 - http://docs.codehaus.org/display/JANINO/Home/commons-compiler)
+ (New BSD License) Janino (org.codehaus.janino:janino:2.7.8 - http://docs.codehaus.org/display/JANINO/Home/janino)
+ (The BSD 3-Clause License) leveldbjni-all (org.fusesource.leveldbjni:leveldbjni-all:1.8 - http://leveldbjni.fusesource.org/leveldbjni-all)
+ (New BSD License) Hamcrest Core (org.hamcrest:hamcrest-core:1.3 - https://github.com/hamcrest/JavaHamcrest/hamcrest-core)
+ (BSD 3-Clause) Scala Compiler (org.scala-lang:scala-compiler:2.11.0 - http://www.scala-lang.org/)
+ (BSD 3-Clause) Scala Library (org.scala-lang:scala-library:2.11.7 - http://www.scala-lang.org/)
+ (BSD 3-Clause) Scala Compiler (org.scala-lang:scala-reflect:2.11.2 - http://www.scala-lang.org/)
+ (BSD 3-Clause) Scalap (org.scala-lang:scalap:2.11.0 - http://www.scala-lang.org/)
+ (BSD 3-clause) scala-parser-combinators (org.scala-lang.modules:scala-parser-combinators_2.11:1.0.1 - http://www.scala-lang.org/)
+ (BSD 3-clause) scala-xml (org.scala-lang.modules:scala-xml_2.11:1.0.1 - http://www.scala-lang.org/)
+ (The BSD License) xmlenc Library (xmlenc:xmlenc:0.52 - http://xmlenc.sourceforge.net)
+ (BSD) Antlr 3.4 Runtime (org.antlr:antlr-runtime:3.4 - http://www.antlr.org)
+ (BSD) ASM Core (asm:asm:3.1 - http://asm.objectweb.org/asm/)
+ (BSD) HSQLDB (hsqldb:hsqldb:1.8.0.10 - http://hsqldb.org/)
+
+========================================================================
+MIT licenses
+========================================================================
+
+The following components are provided under the MIT License. See project link for details.
+The text of each license is also included at licenses/LICENSE-[project].txt.
+
+ (MIT License) pyrolite (net.razorvine:pyrolite:4.9 - https://github.com/irmen/Pyrolite)
+ (The MIT License) JOpt Simple (net.sf.jopt-simple:jopt-simple:4.6 - http://pholser.github.com/jopt-simple)
+ (MIT License) JCL 1.1.1 implemented over SLF4J (org.slf4j:jcl-over-slf4j:1.7.10 - http://www.slf4j.org)
+ (MIT License) JUL to SLF4J bridge (org.slf4j:jul-to-slf4j:1.7.10 - http://www.slf4j.org)
+ (MIT License) SLF4J API Module (org.slf4j:slf4j-api:1.7.21 - http://www.slf4j.org)
+
--- End diff --
....Yes, they came from a (painful :)) transitive walk of the dependencies obtained via `mvn license:add-third-party`
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk issue #65: [PIRK-53] - Fix LICENSE and NOTICE Files for Relea...
Posted by ellisonanne <gi...@git.apache.org>.
Github user ellisonanne commented on the issue:
https://github.com/apache/incubator-pirk/pull/65
Just added the licenses directory with the appropriate licenses. Please check. Thanks!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk pull request #65: [PIRK-53] - Fix LICENSE and NOTICE Files fo...
Posted by asfgit <gi...@git.apache.org>.
Github user asfgit closed the pull request at:
https://github.com/apache/incubator-pirk/pull/65
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk issue #65: [PIRK-53] - Fix LICENSE and NOTICE Files for Relea...
Posted by smarthi <gi...@git.apache.org>.
Github user smarthi commented on the issue:
https://github.com/apache/incubator-pirk/pull/65
+1 looks good
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk issue #65: [PIRK-53] - Fix LICENSE and NOTICE Files for Relea...
Posted by smarthi <gi...@git.apache.org>.
Github user smarthi commented on the issue:
https://github.com/apache/incubator-pirk/pull/65
Looks ok to me, but I am no expert in legalese; I would defer to others to comment on this.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk pull request #65: [PIRK-53] [WIP] - Fix LICENSE and NOTICE Fi...
Posted by ellisonanne <gi...@git.apache.org>.
Github user ellisonanne commented on a diff in the pull request:
https://github.com/apache/incubator-pirk/pull/65#discussion_r75311950
--- Diff: pom.xml ---
@@ -350,6 +350,9 @@
<exclude>docs/*</exclude> <!-- Exclude docs -->
<exclude>logs/*</exclude> <!-- Exclude logs -->
<exclude>**/m2.conf</exclude> <!-- Exclude Maven conf which gets installed on travis and fails RAT check -->
+ <exclude>src/main/resources/META-INF/bin-license-notice/licenses/*</exclude> <!-- Exclude licenses files -->
+ <exclude>src/main/resources/META-INF/bin-license-notice/*</exclude>
+ <exclude>src/main/resources/META-INF/*</exclude>
--- End diff --
will do now
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk issue #65: [PIRK-53] - Fix LICENSE and NOTICE Files for Relea...
Posted by ellisonanne <gi...@git.apache.org>.
Github user ellisonanne commented on the issue:
https://github.com/apache/incubator-pirk/pull/65
If you run `mvn license:add-third-party` you will see the dependencies above - if it appeared in the output, I accounted for it in the files...
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-pirk pull request #65: [PIRK-53] - Fix LICENSE and NOTICE Files fo...
Posted by smarthi <gi...@git.apache.org>.
Github user smarthi commented on a diff in the pull request:
https://github.com/apache/incubator-pirk/pull/65#discussion_r74978243
--- Diff: NOTICE ---
@@ -3,3 +3,276 @@ Copyright 2016 The Apache Software Foundation
This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).
+
+========================================================================
+Common Development and Distribution License 1.0
+========================================================================
+
+The following components are provided under the Common Development and Distribution License 1.0. See project link for details.
+
+ (Common Development and Distribution License (CDDL) v1.0) JavaBeans Activation Framework (JAF) (javax.activation:activation:1.1 - http://java.sun.com/products/javabeans/jaf/index.jsp)
+ (COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0) (GNU General Public Library) Streaming API for XML (javax.xml.stream:stax-api:1.0-2 - no url defined)
+ (CDDL 1.0) Glassfish Jasper (org.mortbay.jetty:jsp-2.1:6.1.14 - http://jetty.mortbay.org/project/modules/jsp-2.1)
+ (CDDL 1.0) Servlet Specification 2.5 API (org.mortbay.jetty:servlet-api-2.5:6.1.14 - http://jetty.mortbay.org/project/modules/servlet-api-2.5)
+
+
+========================================================================
+Common Development and Distribution License 1.1
+========================================================================
+
+The following components are provided under the Common Development and Distribution License 1.1. See project link for details.
+
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-client (com.sun.jersey:jersey-client:1.9 - https://jersey.java.net/jersey-client/)
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-core (com.sun.jersey:jersey-core:1.9 - https://jersey.java.net/jersey-core/)
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-json (com.sun.jersey:jersey-json:1.9 - https://jersey.java.net/jersey-json/)
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-server (com.sun.jersey:jersey-server:1.9 - https://jersey.java.net/jersey-server/)
+ (CDDL 1.1) (GPL2 w/ CPE) jersey-guice (com.sun.jersey.contribs:jersey-guice:1.9 - https://jersey.java.net/jersey-contribs/jersey-guice/)
+ (CDDL 1.1) (GPL2 w/ CPE) JAXB RI (com.sun.xml.bind:jaxb-impl:2.2.3-1 - http://jaxb.java.net/)
+ (CDDL 1.1) (GPL2 w/ CPE) JAXB API bundle for GlassFish V3 (javax.xml.bind:jaxb-api:2.2.2 - https://jaxb.dev.java.net/)
+
+
+========================================================================
+Eclipse Public License 1.0
+========================================================================
+
+The following components are provided under the Eclipse Public License 1.0. See project link for details.
+
+ (Eclipse Public License 1.0) JUnit (junit:junit:4.12 - http://junit.org)
+ (Eclipse Public License v1.0) Eclipse JDT Core (org.eclipse.jdt:core:3.1.1 - http://www.eclipse.org/jdt/)
+
+
+========================================================================
+NOTICE files
+========================================================================
+
+The following NOTICEs are pertain to software distributed with this project.
+
+-------------------------------------------------------------------------------
+ NOTICE file for direct Apache licensed software dependencies corresponding to
+ the section 4d of The Apache License, Version 2.0
+-------------------------------------------------------------------------------
+
+Apache Commons Math (http://commons.apache.org/proper/commons-math/)
+Copyright 2001-2016 The Apache Software Foundation
+
+json-simple (https://github.com/fangyidong/json-simple)
+The Apache Software Foundation
+
+Apache Hadoop (http://hadoop.apache.org/)
+The Apache Software Foundation
+
+Apache Spark (http://spark.apache.org/)
+Copyright 2014 and onwards The Apache Software Foundation
+
+Elasticsearch for Apache Hadoop (https://github.com/elastic/elasticsearch-hadoop)
+Copyright 2009-2016 The Apache Software Foundation
+
+jna-gmp (https://github.com/square/jna-gmp)
+The Apache Software Foundation
+
+Apache log4j (http://logging.apache.org/log4j/2.x/)
+The Apache Software Foundation
+
+
--- End diff --
Need to add one for Jackson
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---