Re: maven: appended-resources/licenses

[Justin Mclean]

HI,

> A bundle’s LICENSE and NOTICE can only contain information relevant to 
> content present in the bundle.

Yep.

> I thought info for all bundled content (regardless of license type) must be 
> included.

No - there’s no need to list ALv2 licensed bits for instance.

>  I believe NOTICE must include info for all bundled content (regardless of 
> license type).

Not exactly and a few things need to go in NOTICE and it almost never would 
mention all bundled content.

> I don’t know the purpose of DEPENDENCIES 

There’s no requirement to have this file.

Thanks,
Justin

Re: maven: appended-resources/licenses

[Dale LaBossiere]

The licensing stuff was a huge pain that I had to deal with last year.  I make 
no claim to being an expert now :-)

A bundle’s LICENSE and NOTICE can only contain information relevant to content 
present in the bundle.  i.e., there must not be any information related to 
external dependencies that are not bundled.
I thought info for all bundled content (regardless of license type) must be 
included.  I believe NOTICE must include info for all bundled content 
(regardless of license type).

I’ll make the adjustments noted below that I believe are correct and undo/redo 
if Justin corrects me :-)

I don’t know the purpose of DEPENDENCIES as it relates to bundled 3rd party 
content (clearly it captures information about non-bundled external 
dependencies).

— Dale

> On Oct 3, 2017, at 3:13 PM, Christofer Dutz  wrote:
> 
> Hi Dale,
> 
> the others were referenced in the DEPENDENCIES file.
> As far as I know we only need to add stuff to NOTICE and LICENSE if the 
> license and notice versions of the included libs require us to do that. So 
> only for those did I add something. For the rest it should be sufficient to 
> mention them in the DEPENDENCIES and bundle their license agreements. Am I 
> correct with that assumption (Still learning this licensing stuff ;-) )?
> 
> By the way … I just pushed an update that eliminated the d3.legend.js from 
> our repo. 
> 
> Chris
> 
> Am 03.10.17, 20:52 schrieb "Dale LaBossiere" :
> 
>Hi Chris,
> 
>Why does appended-resources/licenses contains more than the licenses than 
> those referenced by META-INF/LICENSE files?
>I see just MIT, BSD 3-Clause and BSD 2.Clause referenced from the LICENSE 
> files.
> 
>Why are these present:
>  apache-license-version-2.0.txt  (will be necessary if gson and 
> metrics-core are added to LICENSE :-)
>  cddl+gplv2*
>  eclipse-public-license*
> 
>Justin, just double checking, I thought we MUST include ALL BUNDLED 
> external artifacts in our LICENSE?  If not, at least “can” they be included?  
> Just seems best.
> 
>Specifically gson and metrics-core are bundled but absent.  And I find it 
> confusing that our NOTICE includes info for a bundled item that’s not 
> mentioned in our LICENSE (metrics-core).
>Note, our current release’s binary bundle LICENSE included references for 
> them.
> 
>I’d also like to pull on the JSR-166 reference that Chris added to 
> LICENSE.  Is that supposed to be in NOTICE?  I see that in nifi that’s where 
> they have it along with the metric-core reference (like we have in our 
> NOTICE)  https://github.com/apache/nifi/blob/master/nifi-assembly/NOTICE 
> 
> 
>It also seems wrong to have a JSR-166 reference in our LICENSE and not 
> have some corresponding license reference to go with it.
> 
>Thanks!
>— Dale
> 
> 
> 

maven: d3.legend.js mods

[Dale LaBossiere]

Hi Chris, I picked up the d3.legend.js refactoring (7d8a69f 
) and it causes this 
error in Eclipse:

Plugin execution not covered by lifecycle configuration: 
com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget 
(execution: get-d3-legend-js, phase: generate-resources) pom.xml 
/edgent-console-servletsline 125Maven Project Build Lifecycle 
Mapping Problem


Also, earlier mods cause the following warnings in Eclipse that would be good 
to eliminate:

Access 
"/Users/dlaboss/git/dutz-incubator-edgent/console/server/../../src/main/appended-resources/licenses"
 directory outside of project base directory. 
(org.apache.maven.plugins:maven-resources-plugin:2.7:resources:default-resources:process-resources)
pom.xml /edgent-console-server  line 1  Maven Build Participant Problem

Access 
"/Users/dlaboss/git/dutz-incubator-edgent/console/servlets/../../src/main/appended-resources/licenses"
 directory outside of project base directory. 
(org.apache.maven.plugins:maven-resources-plugin:2.7:resources:default-resources:process-resources)
  pom.xml /edgent-console-servletsline 1  Maven Build Participant 
Problem

Duplicating managed version 2.5.3 for maven-assembly-plugin pom.xml 
/edgent-distributionline 40 Maven pom Loading Problem

Thanks!
— Dale

Re: maven: appended-resources/licenses

[Christofer Dutz]

Hi Dale,

the others were referenced in the DEPENDENCIES file.
As far as I know we only need to add stuff to NOTICE and LICENSE if the license 
and notice versions of the included libs require us to do that. So only for 
those did I add something. For the rest it should be sufficient to mention them 
in the DEPENDENCIES and bundle their license agreements. Am I correct with that 
assumption (Still learning this licensing stuff ;-) )?

By the way … I just pushed an update that eliminated the d3.legend.js from our 
repo. 

Chris

Am 03.10.17, 20:52 schrieb "Dale LaBossiere" :

Hi Chris,

Why does appended-resources/licenses contains more than the licenses than 
those referenced by META-INF/LICENSE files?
I see just MIT, BSD 3-Clause and BSD 2.Clause referenced from the LICENSE 
files.

Why are these present:
  apache-license-version-2.0.txt  (will be necessary if gson and 
metrics-core are added to LICENSE :-)
  cddl+gplv2*
  eclipse-public-license*

Justin, just double checking, I thought we MUST include ALL BUNDLED 
external artifacts in our LICENSE?  If not, at least “can” they be included?  
Just seems best.

Specifically gson and metrics-core are bundled but absent.  And I find it 
confusing that our NOTICE includes info for a bundled item that’s not mentioned 
in our LICENSE (metrics-core).
Note, our current release’s binary bundle LICENSE included references for 
them.

I’d also like to pull on the JSR-166 reference that Chris added to LICENSE. 
 Is that supposed to be in NOTICE?  I see that in nifi that’s where they have 
it along with the metric-core reference (like we have in our NOTICE)  
https://github.com/apache/nifi/blob/master/nifi-assembly/NOTICE 


It also seems wrong to have a JSR-166 reference in our LICENSE and not have 
some corresponding license reference to go with it.

Thanks!
— Dale

maven: appended-resources/licenses

[Dale LaBossiere]

Hi Chris,

Why does appended-resources/licenses contains more than the licenses than those 
referenced by META-INF/LICENSE files?
I see just MIT, BSD 3-Clause and BSD 2.Clause referenced from the LICENSE files.

Why are these present:
  apache-license-version-2.0.txt  (will be necessary if gson and metrics-core 
are added to LICENSE :-)
  cddl+gplv2*
  eclipse-public-license*

Justin, just double checking, I thought we MUST include ALL BUNDLED external 
artifacts in our LICENSE?  If not, at least “can” they be included?  Just seems 
best.

Specifically gson and metrics-core are bundled but absent.  And I find it 
confusing that our NOTICE includes info for a bundled item that’s not mentioned 
in our LICENSE (metrics-core).
Note, our current release’s binary bundle LICENSE included references for them.

I’d also like to pull on the JSR-166 reference that Chris added to LICENSE.  Is 
that supposed to be in NOTICE?  I see that in nifi that’s where they have it 
along with the metric-core reference (like we have in our NOTICE)  
https://github.com/apache/nifi/blob/master/nifi-assembly/NOTICE 


It also seems wrong to have a JSR-166 reference in our LICENSE and not have 
some corresponding license reference to go with it.

Thanks!
— Dale

Re: maven: couple of console pom questions

[Christofer Dutz]

Well I agree the “generate-test-resources” isn’t quite ideal … I am just 
running a build with “generate-resources” ...

The tomcat plugin doesn’t have any effect on the build itself as there is no 
“execution” defined in the plugin definition. What it does is it allowes a user 
to simply run “mvn tomcat:run” and have a running console server without using 
the server jar.

Chris

Am 03.10.17, 19:46 schrieb "Dale LaBossiere" :

Hi Chris, I just pushed some changes to the poms, etc for "maintenance doc”

There were two other things I noticed and didn’t understand:

console/server/pom.xml - Is the “generate-test-resources” phase appropriate 
for copying in the war?  Seems odd being tied to “test” related processing.

console/servlets/pom.xml - why is a there a declaration for 
tomcat7-maven-plugin?

Thanks
— Dale

maven: couple of console pom questions

[Dale LaBossiere]

Hi Chris, I just pushed some changes to the poms, etc for "maintenance doc”

There were two other things I noticed and didn’t understand:

console/server/pom.xml - Is the “generate-test-resources” phase appropriate for 
copying in the war?  Seems odd being tied to “test” related processing.

console/servlets/pom.xml - why is a there a declaration for 
tomcat7-maven-plugin?

Thanks
— Dale

maven: supplemental-model.xml

[Dale LaBossiere]

Hi Chris,

I was trying to educate myself more about supplemental-model.xml and our need 
for it.

I may have missed something but it didn’t look to me like there was any default 
generated DEPENDENCY file info which was critical or at least very important to 
“override/fix”.  Do you disagree?
Did you review the info for our various connector’s external dependencies too?

I’m hoping we can do away with it and simplify our lives and subsequent 
maintenance burden :-)

Note, our bundles' LICENSE files and the license copies we made and bundle are 
accurate and not influenced by the contents of supplemental-model.xml.

So, your thoughts?

— Dale

Re: maven: war LICENSE file

[Dale LaBossiere]

Sounds good.  The dynamic download was cool but having more places with 
duplicated/manually sync’d info was a bit ugly :-)
I’ll pull and check it out!

— Dale

> On Oct 3, 2017, at 7:44 AM, Christofer Dutz  wrote:
> 
> Hi Dale,
> 
> So, I completely removed the usage of the license-maven-plugin and hereby 
> also removed all of these licenses.xml files. 
> Thinking about what I was planning on using it for, seemed a little over the 
> top for just downloading 5 text files. So, I decided to check-in these 
> license texts and to have default maven mechanisms copy them into the project.
> I think things are a lot less complicated this way.
> 
> Chris
> 
> 
> 
> Am 02.10.17, 23:09 schrieb "Dale LaBossiere" :
> 
>Hi Chris, I see you added a bunch of comments to the wiki, thanks!
> 
>I think we has a misunderstanding :-)  There are many artifacts that 
> *have* an entry in license.xml but are not bundled.  e.g., junit, jetty-*.
>That’s what I was trying to say in the tables.  Shouldn’t only bundled 
> things be present in license.xml?
> 
>— Dale
> 
> 
>> On Oct 2, 2017, at 1:34 PM, Dale LaBossiere  wrote:
>> 
>> I did a review and captured what I learned along with questions and/or 
>> problems in new item 21 (at the bottom of) [1]
>> The details (table) are for only console/servlets at the moment.  I’ll be 
>> doing similar for console/server shortly.
>> 
>> [1] https://cwiki.apache.org/confluence/display/EDGENT/Maven+vs+Gradle 
>> 
>> 
>> Thanks!
>> — Dale
>> 
>>> On Oct 2, 2017, at 9:07 AM, Dale LaBossiere >> > wrote:
>>> 
>>> I’m on it!
>>> 
 On Oct 2, 2017, at 8:52 AM, Christofer Dutz > wrote:
 ...
 I just committed some more changes to the java8 and jaca7 console. I hope 
 that now all should be in place and the modules should be ok from a legal 
 point of view. 
 ...
 Please inspect my latest changes and especially their output.
>>> 
>> 
> 
> 
> 

Re: maven: war LICENSE file

[Christofer Dutz]

Hi Dale,

So, I completely removed the usage of the license-maven-plugin and hereby also 
removed all of these licenses.xml files. 
Thinking about what I was planning on using it for, seemed a little over the 
top for just downloading 5 text files. So, I decided to check-in these license 
texts and to have default maven mechanisms copy them into the project.
I think things are a lot less complicated this way.

Chris



Am 02.10.17, 23:09 schrieb "Dale LaBossiere" :

Hi Chris, I see you added a bunch of comments to the wiki, thanks!

I think we has a misunderstanding :-)  There are many artifacts that *have* 
an entry in license.xml but are not bundled.  e.g., junit, jetty-*.
That’s what I was trying to say in the tables.  Shouldn’t only bundled 
things be present in license.xml?

— Dale


> On Oct 2, 2017, at 1:34 PM, Dale LaBossiere  wrote:
> 
> I did a review and captured what I learned along with questions and/or 
problems in new item 21 (at the bottom of) [1]
> The details (table) are for only console/servlets at the moment.  I’ll be 
doing similar for console/server shortly.
> 
> [1] https://cwiki.apache.org/confluence/display/EDGENT/Maven+vs+Gradle 

> 
> Thanks!
> — Dale
> 
>> On Oct 2, 2017, at 9:07 AM, Dale LaBossiere > wrote:
>> 
>> I’m on it!
>> 
>>> On Oct 2, 2017, at 8:52 AM, Christofer Dutz > wrote:
>>> ...
>>> I just committed some more changes to the java8 and jaca7 console. I 
hope that now all should be in place and the modules should be ok from a legal 
point of view. 
>>> ...
>>> Please inspect my latest changes and especially their output.
>> 
>