Hi Karl
On 2016-07-01 14:09, Karl Heinz Marbaise wrote: > Hi, > > On 7/1/16 1:54 PM, Grzegorz Słowikowski wrote: >> Thank you very much Stian. >> >> I have some more technical questions. >> >> 1. >> >> When I wrote about using modified class from Maven core I thought about >> ExecutionEventLogger class from maven-embedder >> (https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java) >> > >> >> I wanted to change Logger interface >> (https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java#L50) >> >> and use org.apache.maven.plugin.logging.Log available in Maven plugins. > > This means you changing the interface which means your version of Maven > is not compatible with the Apache Maven ? No > >> >> Now I'm testing another approach. I've added provided dependency on >> maven-embedder and use original class. Minimal Maven version is set to >> 3.1.0 in prerequisities of my plugin. >> >> My first question is, can I expect ExecutionEventLogger to be stable API >> in future releases? > > > What I don't understand is why you need to change such interface? May be > you can describe your exact problems (here on the list) or better into a > JIRA ticket and may be the Maven project can help or change things there > if it makes sense...Or your provide a patch (as already mentioned) to > solve your problem ? > > Otherwise you start to creating a Maven which is not compatible with > Apache Maven which will confuse people and will produce many problems... > I didn't write it before, I'm implementing mojo running the application (Play! Framework), watching source changes and rebuilding projects, all this while application is still running. Play! Framework supports this. They use SBT and I'm reimplementing this functionality in Maven. To run Maven build, I create 'MavenExecutionRequest', new 'MavenSession', etc. and execute this session using 'LifecycleExecutor'. To see build progress, I need 'ExecutionListener' (see https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java#L376) There is one implementation available in maven-embedder https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java I didn't want to depend on 'maven-embedder', so my first thought was to copy this class, change 'org.slf4j.Logger' class of the 'logger' variable to 'org.apache.maven.plugin.logging.Log', I have (in 'AbstractMojo') Advantage - I control the class Disadvantages - e.g. no colors in future Maven versions (because using class from Maven not supporting colors yet), licensing questions > > > > Kind regards > Karl Heinz Marbaise > > > >> >> My second questions is how and where should I describe my modifications? >> Do I need to provide somehow the original source of modified class? >> >> 2. >> >> When using (not modified) classes from another ASLv2 project do I need >> to create NOTICE file (I've had no NOTICE file before) in the root >> directory of my repository containing: >> >> This product includes software developed at >> XXX Inc. <https://www.xxx.com>, >> which is licensed under the Apache 2 license. >> >> Is this note OK? >> >> Additionally, identical NOTICE file should be added to >> /src/main/resources/META-INF directory of every module using external >> classes, right? >> >> >> I will ask next questions on [email protected]. Thank you in >> advance. Regards. >> >> Grzegorz Slowikowski >> >> >> On 2016-06-30 12:24, Stian Soiland-Reyes wrote: >>> This would be more a question for [email protected], but I'll >>> try to respond anyway :). Sorry for the long answer.. Please correct >>> me! >>> >>> On 29 June 2016 at 19:30, Grzegorz Słowikowski >>> <[email protected]> wrote: >>>> 1. Can I include slightly modified class from Maven code in one of my >>>> plugins? How should I note this fact? >>> >>> Of course - that's explicitly permitted as long as you follow the >>> Apache License clause 5 >>> >>> https://www.apache.org/licenses/LICENSE-2.0.html#redistribution >>> >>> >>> You should note it by keeping the license header in the files, and by >>> propagating the content of the NOTICE from the Maven code, e.g. from >>> >>> https://github.com/apache/maven/blob/master/NOTICE >>> >>> if the code you are modifying is from the main Maven code. (Note that >>> most plugins have their own repositories with slightly different >>> NOTICE files) >>> >>> Remember: >>> >>>> You must cause any modified files to carry prominent notices stating >>>> that You changed the files; and >>> >>> So if you modify a file, then append to the existing license header >>> what you have changed. >>> >>> >>> >>> You will probably want to add your own (c) as well to the new NOTICE. >>> >>> Note that Apache trademarks mean you can't call your derived product >>> for "Apache Maven", however you may want to say "partially based on >>> Apache Maven" if that is true. >>> >>> >>> >>> You should still reconsider if you really NEED to do your own >>> modifications - perhaps the modifications can be provided to us >>> upstream instead in order for you to do subclassing or use the Maven >>> classes as they are? This would remove your need in the future to >>> "keep track" with Apache Maven development. >>> >>> >>>> 2. Can I include classes from other project with ASLv2 license (Play! >>>> Framework)? >>> >>> You can mix and match source code from any compatible license, as long >>> as you keep their license headers and NOTICE content, and provide the >>> Apache license with your work. >>> >>> You are not required to license your own derived work under the Apache >>> license (e.g. you could license it as GPL 3.0 or a commercial license >>> instead), but in most cases keeping it as Apache License 2.0 makes >>> things easier :) >>> >>> Note that while software from ASF always ensures that there is a >>> NOTICE file and /** Apache **/ license header, not all open source >>> software under the Apache License do this (it's not a requirement). >>> You should still append a license header saying which files you have >>> modified, if you need to. >>> >>> You may want to keep note in your new NOTICE what files came from where. >>> >>>> JNotify uses different licenses: GNU LGPL 2.1 + EPL >>>> Can, from legal PoV, JNotify implementation be used automatically >>>> (without user configuration) in any case (OSX here)? >>> >>> Yes, there is no legal reason why you can't use Apache licensed >>> software with LGPL or EPL. You will have to respect LGPL or EPL >>> separately for those parts - you can't distribute those as if they are >>> Apache License. This is normally easily achieved by your software >>> downloading their JARs separately using normal Maven <dependency> >>> mechanisms. >>> >>> Note that LGPL contains a clause that requires downstream users to be >>> get the source for, modify, debug and replace the LGPL part. The code >>> that uses LGPL can be under any license as long (and even just a >>> binary) as it does not restrict those possibilities. >>> >>> This is normally quite easy to achieve by keeping the LGPL dep as a >>> separate JAR - but this is a restrictions of the "freedoms" of the >>> Apache License, e.g. you are allowed to take your modified Apache >>> Maven source code and burn it into a ROM within a hardware component, >>> without having to provide the source code or a mechanism for >>> downstream users to modify it. >>> >>> LGPL on the other hand protects the "freedom of the source" - you >>> can't deny your downstream users the source code of the LGPL bit and >>> the freedom to modify that. And so your "closed" or "other" bit can't >>> do things like "Ensure that jnotify.jar has the correct checksum". >>> >>> Because of these complications it is an Apache Software Foundation >>> policy to not allow LGPL dependencies [1] in software contributed to >>> the ASF because we want all our software to be usable by the Apache >>> LIcense alone (or by licenses which don't permit less than AL2). >>> (Truly <optional> LGPL dependencies are allowed as long as the Apache >>> software still works without that). >>> >>> A EPL-licensed dependency is however easier [2] as long as the EPL >>> dependency is kept as a binary and not mixed into the source code. >>> >>> I must say JNotify is confusing with its two licenses, is it a >>> dual-license where you can choose, or do you have to comply with both >>> licenses? Make sure your own README and LICENSE makes clear what is >>> the case for your end produxct. >>> >>> >>> If you are not considering contributing your work to the Apache >>> Software Foundation (why wouldn't you? :) - then you are not required >>> to follow ASF policies. You only need to follow the Apache License >>> terms for the source code that is covered by that license. >>> >>> >>> >>> [1] https://www.apache.org/legal/resolved#category-x >>> [2] https://www.apache.org/legal/resolved#category-b >>> >>>> Can it be used, if it requires user configuration (in pom.xml or >>>> command >>>> line parameter)? >>>> >>>> Regards >>>> Grzegorz Slowikowski >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
