Re: Maven plugin - some licensing questions

[Stian Soiland-Reyes]

On 1 July 2016 at 12:54, Grzegorz Słowikowski  wrote:

> I have some more technical questions.

I'll let the actual Maven developers chip in on those :)


> My second questions is how and where should I describe my modifications?
> Do I need to provide somehow the original source of modified class?

So in this case it's easy, it just needs to "carry prominent notices
stating that You changed the files".

The top of the file says:

/*
* Licensed to the Apache Software Foundation (ASF) under one
(..)
* specific language governing permissions and limitations
* under the License.
*/

Simply add right below:

/*
 * This file was adapted from Apache Maven Embedder
 * 
https://github.com/apache/maven/blob/maven-3.3.5/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java
 * and modified by XXX Inc.
 * to use org.apache.maven.plugin.logging.Log
 * instead of org.slf4j.Logger
 */

Note that legally you don't have to say WHAT you have changed, but of
course that's good engineering practice as otherwise you wouldn't know
why this file was modified at all. :)

I would include the exact tag/commit id and repository of where it
came from - this will make it easier if you come back later to compare
with a newer ExecutionEventLogger from Maven.


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

No, you do not NEED to create a NOTICE file if none exists already in
any of the sources you have redistributed.

In a way not having a NOTICE file is good for the user as then they
don't need to propagate it; it's almost like a "Public domain under
ASF" option.

But in your case I think you are including code from Apache Maven,
which HAS a NOTICE file, in which case you would want to propagate it.
However you need to insert your stuff to the top, as your new thing is
not "Apache Maven". :)


> This product includes software developed at
> XXX Inc. ,
> which is licensed under the Apache 2 license.
>
> Is this note OK?

I would keep your private NOTICE in a similar format to the Apache
style, e.g. for a product Foo Bar:

Foo Bar
Copyright 2015-2016 XXX Inc.
This product includes software developed at
XXX Inc. .


And then as you have included your Apache Maven files, in the same
NOTICE file also add BELOW:

-
foo-module-x/src/main/java/com/example/ExecutionEventLogger.java

Apache Maven
Copyright 2001-2015 The Apache Software Foundation
This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).


(and similar for any other files from other AL2 sources that also have
a NOTICE).


You have to propagate the NOTICE content verbatim - except if it
doesn't apply to what you copy. (E.g. if someone copies from you now,
but don't copy your modified ExecutionEventLogger.java, then they
don't need to propagate those separate Maven NOTICE lines, but would
have to propagate the Foo Bar lines.)

Because of this, for Apache projects we try to keep our NOTICEs slim -
so don't add stuff there that you don't need to.


> Additionally, identical NOTICE file should be added to
> /src/main/resources/META-INF directory of every module using external
> classes, right?

Yes, that would be very good practice - however you should only NEED
to do this if you are going to distribute the compiled JARs separate
from your source code (which would also have the top level NOTICE).
Publishing to Maven Central could be seen as such a distribution - but
if you just provide your JARs within say a ZIP file, then you can just
put the NOTICE (and LICENSE) file in that ZIP file.


> I will ask next questions on legal-disc...@apache.org. Thank you in
> advance. Regards.

You seem to have got a great understanding of this already - but that
would probably be the best place for more generic Apache license and
attribution questions :-)

And thank you for following open source licensing seriously! :-)

-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven plugin - some licensing questions

[Mark Derricutt]

When I was writing my LifecycleExtension recently I hit this same issue,
with the two different logger classes depending on where my common code was
being called from.

I just changed my base code to accept a Consumer and passed in
getLog()::info and the relevant other method from the other logger as
method references. Worked a charm in my small use case anyway.

On Sat, Jul 2, 2016 at 12:35 AM, Grzegorz Słowikowski <
gslowikow...@gmail.com> wrote:

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



-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: https://issues.apache.org/jira/browse/MNG-5895

[Robert Scholte]

Hi Karl Heinz,

I think you should focus on the org.apache.maven.graph.DefaultGraphBuilder  
when you're talking about the reactor order.


Robert

On Fri, 01 Jul 2016 19:55:56 +0200, Karl Heinz Marbaise  
 wrote:



Hi,

I have described two issues within this issue.

First the changed reactor order based on using a property for the  
version and second the problem related to the version which is used for  
artifacts.


At the moment I'm trying to identify the first issue...but currently I'm  
a little bit lost...


May be one or more of the other devs can give me hint where to search in  
Maven Core for the problem or a hint how to solve the problem?


I have also checked with the current master of 3.4.0-SNAPSHOT and see  
the same changed order of the reactor if i use a property for the  
version in such multi module build...



The second issue I will investigate further if the first one has been  
done...


Any help is appreciated...Many thanks in advance..


Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plugin resolution for Maven 3.5

[Karl Heinz Marbaise]

Hi,

On 7/1/16 9:03 PM, Christian Schulte wrote:

Am 07/01/16 um 20:11 schrieb Karl Heinz Marbaise:

Hi,

wouldn't it make sense to create a branch for Maven 3.5.0 ? And
summarize all changes there ? Makes it more clear ?

Cause there are some issues fixed related to JIRA...for 3.5.0 ?

WDYT ?




Already done. That's the MNG-6006 branch.


couldn't we name it 3.5.0 ?

Kind regards
Karl Heinz

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plugin resolution for Maven 3.5

[Christian Schulte]

Am 07/01/16 um 20:11 schrieb Karl Heinz Marbaise:
> Hi,
> 
> wouldn't it make sense to create a branch for Maven 3.5.0 ? And 
> summarize all changes there ? Makes it more clear ?
> 
> Cause there are some issues fixed related to JIRA...for 3.5.0 ?
> 
> WDYT ?
> 
> 

Already done. That's the MNG-6006 branch.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plugin resolution for Maven 3.5

[Karl Heinz Marbaise]

Hi,

wouldn't it make sense to create a branch for Maven 3.5.0 ? And 
summarize all changes there ? Makes it more clear ?


Cause there are some issues fixed related to JIRA...for 3.5.0 ?

WDYT ?


Kind regards
Karl Heinz Marbaise

On 7/1/16 9:16 AM, Christian Schulte wrote:

Hi,

I am currently stumbling upon the following issue. Maven resolves
plugins as if they were a direct dependency of Maven core. That means it
will not consider any 'test' or 'provided' scope dependencies of plugins
when building plugin runtime classpaths. I am not sure if this is the
correct way to go. If it would resolve plugins the same way it resolves
projects, things like the following will start to happen.

Execution default-resources of goal
org.apache.maven.plugins:maven-resources-plugin:3.0.1:resources failed:
A required class was missing while executing
org.apache.maven.plugins:maven-resources-plugin:3.0.1:resources:
org/apache/commons/io/input/XmlStreamReader

Caused by: java.lang.ClassNotFoundException:
org.apache.commons.io.input.XmlStreamReader

Here is the plugin's classpath resolved by Maven <= 3.4.0-SNAPSHOT:

 [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=4,
ConflictMarker.markTime=4, ConflictMarker.nodeCount=69,
ConflictIdSorter.graphTime=2, ConflictIdSorter.topsortTime=1,
ConflictIdSorter.conflictIdCount=28,
ConflictIdSorter.conflictIdCycleCount=0, ConflictResolver.totalTime=17,
ConflictResolver.conflictItemCount=68,
DefaultDependencyCollector.collectTime=850,
DefaultDependencyCollector.transformTime=36}
[DEBUG] org.apache.maven.plugins:maven-resources-plugin:jar:3.0.1:
[DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG]   org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG]  org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
[DEBUG]org.apache.maven:maven-core:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-settings-builder:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-repository-metadata:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-model-builder:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-aether-provider:jar:3.0:runtime
[DEBUG]   org.sonatype.aether:aether-impl:jar:1.7:compile
[DEBUG]  org.sonatype.aether:aether-spi:jar:1.7:compile
[DEBUG]   org.sonatype.aether:aether-api:jar:1.7:compile
[DEBUG]   org.sonatype.aether:aether-util:jar:1.7:compile
[DEBUG]   org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG]
org.codehaus.plexus:plexus-component-annotations:jar:1.6:compile
[DEBUG]   org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
[DEBUG]  org.sonatype.plexus:plexus-cipher:jar:1.4:compile
[DEBUG]org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG]org.apache.maven:maven-settings:jar:3.0:compile
[DEBUG]org.apache.maven:maven-model:jar:3.0:compile
[DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
[DEBUG]org.apache.maven.shared:maven-filtering:jar:3.1.1:compile
[DEBUG]   org.apache.maven.shared:maven-shared-utils:jar:3.0.0:compile
[DEBUG]  commons-io:commons-io:jar:2.4:compile
[DEBUG]  com.google.code.findbugs:jsr305:jar:2.0.1:compile
[DEBUG]   org.sonatype.plexus:plexus-build-api:jar:0.0.7:compile
[DEBUG]org.codehaus.plexus:plexus-interpolation:jar:1.22:compile

And here is the plugin's classpath resolved the same way projects are
resolved (3.5.0-SNAPSHOT):

[DEBUG] Dependency collection stats:
{ConflictMarker.analyzeTime=3907145, ConflictMarker.markTime=5714366,
ConflictMarker.nodeCount=172, ConflictIdSorter.graphTime=2411000,
ConflictIdSorter.topsortTime=1248278,
ConflictIdSorter.conflictIdCount=38,
ConflictIdSorter.conflictIdCycleCount=0,
ConflictResolver.totalTime=21802925,
ConflictResolver.conflictItemCount=90,
DefaultDependencyCollector.collectTime=1324192650,
DefaultDependencyCollector.transformTime=190157370}
[DEBUG] org.apache.maven.plugins:maven-resources-plugin:jar:3.0.1:
[DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG]   org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG]  org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
[DEBUG]org.apache.maven:maven-core:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-settings-builder:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-repository-metadata:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-model-builder:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-aether-provider:jar:3.0:runtime
[DEBUG]   org.sonatype.aether:aether-impl:jar:1.7:compile
[DEBUG]  org.sonatype.aether:aether-spi:jar:1.7:compile
[DEBUG]   org.sonatype.aether:aether-api:jar:1.7:compile
[DEBUG]   org.sonatype.aether:aether-util:jar:1.7:compile
[DEBUG]   org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG]
org.codehaus.plexus:plexus-component-anno

Re: https://issues.apache.org/jira/browse/MNG-5895

[Karl Heinz Marbaise]

Hi,

I also realized that we currently having failing Maven Core IT[1] which 
is related to this subject[2]


Kind regards
Karl Heinz

[1]: 
https://builds.apache.org/view/M-R/view/Maven%20Core%20ITs/job/core-integration-testing-maven-3-jdk-1.7/1820/console

[2] https://issues.apache.org/jira/browse/MNG-5576


On 7/1/16 7:55 PM, Karl Heinz Marbaise wrote:

Hi,

I have described two issues within this issue.

First the changed reactor order based on using a property for the
version and second the problem related to the version which is used for
artifacts.

At the moment I'm trying to identify the first issue...but currently I'm
a little bit lost...

May be one or more of the other devs can give me hint where to search in
Maven Core for the problem or a hint how to solve the problem?

I have also checked with the current master of 3.4.0-SNAPSHOT and see
the same changed order of the reactor if i use a property for the
version in such multi module build...


The second issue I will investigate further if the first one has been
done...

Any help is appreciated...Many thanks in advance..


Kind regards
Karl Heinz Marbaise


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

https://issues.apache.org/jira/browse/MNG-5895

[Karl Heinz Marbaise]

Hi,

I have described two issues within this issue.

First the changed reactor order based on using a property for the 
version and second the problem related to the version which is used for 
artifacts.


At the moment I'm trying to identify the first issue...but currently I'm 
a little bit lost...


May be one or more of the other devs can give me hint where to search in 
Maven Core for the problem or a hint how to solve the problem?


I have also checked with the current master of 3.4.0-SNAPSHOT and see 
the same changed order of the reactor if i use a property for the 
version in such multi module build...



The second issue I will investigate further if the first one has been 
done...


Any help is appreciated...Many thanks in advance..


Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-shared pull request #13: [MSHARED-562] override default colors with ja...

[seblm]

GitHub user seblm opened a pull request:

https://github.com/apache/maven-shared/pull/13

[MSHARED-562] override default colors with java properties

This pull request allow a user to redefine default maven colors with some 
java properties.

For example one can edit his `~/.mavenrc` with the following:

```bash
MAVEN_OPTS="-Dstyle.info=cyan -Dstyle.warning=bold,yellow"
```

Possible values are (case insensitive):

 - colors
   - `BLACK`
   - `RED`
   - `GREEN`
   - `YELLOW`
   - `BLUE`
   - `MAGENTA`
   - `CYAN`
   - `WHITE`
   - `DEFAULT`
 - styles
   - `BOLD`

Additional note about tests: as configuration is handled into one single 
enum thus testing with java property is merely impossible. Enum `Style` is 
already loaded when test is starting.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/seblm/maven-shared trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-shared/pull/13.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 #13


commit 1b248c0c12ba98df1bd5cc79e8fdc712d060e58e
Author: Sébastian Le Merdy 
Date:   2016-07-01T14:47:15Z

[MSHARED-562] test default colors for each style

commit 6180b4bdcd4f5ecbd0a1bd64d9237692327224f9
Author: Sébastian Le Merdy 
Date:   2016-07-01T14:51:33Z

[MSHARED-562] allow color configuration with java properties




---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven plugin - some licensing questions

[Grzegorz Słowikowski]

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. ,
>> 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 legal-disc...@apache.org. Thank you in
>> advance. Regards.
>>
>> Grzegorz Slowikowski
>>
>>
>> On 2016-06-30 12:24, Stian Soiland-Reyes wrote:
>>> This would be more a question for legal-disc...@apache.org, 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
>>>  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 y

Re: Maven plugin - some licensing questions

[Karl Heinz Marbaise]

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 ?




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





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. ,
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 legal-disc...@apache.org. Thank you in
advance. Regards.

Grzegorz Slowikowski


On 2016-06-30 12:24, Stian Soiland-Reyes wrote:

This would be more a question for legal-disc...@apache.org, 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  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 o

Re: Maven plugin - some licensing questions

[Grzegorz Słowikowski]

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.

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?

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. ,
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 legal-disc...@apache.org. Thank you in
advance. Regards.

Grzegorz Slowikowski


On 2016-06-30 12:24, Stian Soiland-Reyes wrote:
> This would be more a question for legal-disc...@apache.org, 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  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 
> 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 

Re: [VOTE] Release Apache Maven SCM version 1.9.5

[Anders Hammar]

Shouldn't this rather be v1.10.0 as there are new features?

/Anders

On Fri, Jul 1, 2016 at 1:24 PM, Karl Heinz Marbaise 
wrote:

> Hi,
>
> We solved 24 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317828&version=12331366
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SCM%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1281
>
> https://repository.apache.org/content/repositories/maven-1281/org/apache/maven/scm/maven-scm/1.9.5/maven-scm-1.9.5-source-release.zip
>
> Source release checksum(s):
> maven-scm-1.9.5-source-release.zip sha1:
> a35799bfe9a0888997f4fc10001eb8380280b62e
>
> Staging site:
> https://maven.apache.org/scm-archives/scm-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [1/2] maven-scm git commit: [SCM-824] Upgrade of 'plexus-utils' to 3.0.23.

[Olivier Lamy]

Thanks a lot Karl!

On Friday, 1 July 2016, Karl Heinz Marbaise  wrote:

> Hi Craig,
>
> I have taken a the liberty to cut a release
>
> starting the release process. I hope this helps.
>
> Kind regards
> Karl Heinz Marbaise
>
> On 6/29/16 6:07 AM, Craig Rodrigues wrote:
>
>> Hi,
>>
>> Do you think you will be able to do a release of maven-scm this week?
>> I am still receiving queries from Jenkins users who need an updated
>> maven-scm
>> for the Jenkins SCM Sync Configuration plugin.
>>
>> Thanks.
>>
>> --
>> Craig
>>
>>
>> On Thu, Jun 9, 2016 at 11:48 PM, Olivier Lamy  wrote:
>>
>> Hi
>>> Definitely on my TODO list. I hope to have a bit of time next week.
>>> Cheers
>>> Olivier
>>> PS: thanks for the reminder :-)
>>>
>>> On 10 June 2016 at 16:34, Craig Rodrigues  wrote:
>>>
>>> Olivier,

 Any ETA on a maven-scm release?  Several Jenkins users have been asking

>>> me,
>>>
 due to the bugfixes that have gone into maven-scm for git since the last
 maven-scm official release.

 Thanks.

 --
 Craig

 On Thu, May 26, 2016 at 5:58 PM, Olivier Lamy  wrote:

 ping.
> I will revert this commit as I'd like to cut a release.
>
>
>

> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Olivier

Re: [1/2] maven-scm git commit: [SCM-824] Upgrade of 'plexus-utils' to 3.0.23.

[Karl Heinz Marbaise]

Hi Craig,

I have taken a the liberty to cut a release

starting the release process. I hope this helps.

Kind regards
Karl Heinz Marbaise

On 6/29/16 6:07 AM, Craig Rodrigues wrote:

Hi,

Do you think you will be able to do a release of maven-scm this week?
I am still receiving queries from Jenkins users who need an updated
maven-scm
for the Jenkins SCM Sync Configuration plugin.

Thanks.

--
Craig


On Thu, Jun 9, 2016 at 11:48 PM, Olivier Lamy  wrote:


Hi
Definitely on my TODO list. I hope to have a bit of time next week.
Cheers
Olivier
PS: thanks for the reminder :-)

On 10 June 2016 at 16:34, Craig Rodrigues  wrote:


Olivier,

Any ETA on a maven-scm release?  Several Jenkins users have been asking

me,

due to the bugfixes that have gone into maven-scm for git since the last
maven-scm official release.

Thanks.

--
Craig

On Thu, May 26, 2016 at 5:58 PM, Olivier Lamy  wrote:


ping.
I will revert this commit as I'd like to cut a release.






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[VOTE] Release Apache Maven SCM version 1.9.5

[Karl Heinz Marbaise]

Hi,

We solved 24 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317828&version=12331366

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20SCM%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1281
https://repository.apache.org/content/repositories/maven-1281/org/apache/maven/scm/maven-scm/1.9.5/maven-scm-1.9.5-source-release.zip

Source release checksum(s):
maven-scm-1.9.5-source-release.zip sha1: 
a35799bfe9a0888997f4fc10001eb8380280b62e


Staging site:
https://maven.apache.org/scm-archives/scm-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [1/2] maven-scm git commit: [SCM-824] Upgrade of 'plexus-utils' to 3.0.23.

[Karl Heinz Marbaise]

Hi,

I can do this today if you have no objections...

Kind regards
Karl Heinz

On 7/1/16 11:22 AM, Olivier Lamy wrote:

Hi
I'm on holidays with very limited network
I apologise for delay as I was busy before holidays next week might better.


On Wednesday, 29 June 2016, Craig Rodrigues  wrote:


Hi,

Do you think you will be able to do a release of maven-scm this week?
I am still receiving queries from Jenkins users who need an updated
maven-scm
for the Jenkins SCM Sync Configuration plugin.

Thanks.

--
Craig


On Thu, Jun 9, 2016 at 11:48 PM, Olivier Lamy > wrote:


Hi
Definitely on my TODO list. I hope to have a bit of time next week.
Cheers
Olivier
PS: thanks for the reminder :-)

On 10 June 2016 at 16:34, Craig Rodrigues 
> wrote:



Olivier,

Any ETA on a maven-scm release?  Several Jenkins users have been asking

me,

due to the bugfixes that have gone into maven-scm for git since the

last

maven-scm official release.

Thanks.

--
Craig

On Thu, May 26, 2016 at 5:58 PM, Olivier Lamy 
> wrote:



ping.
I will revert this commit as I'd like to cut a release.








--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy







-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [1/2] maven-scm git commit: [SCM-824] Upgrade of 'plexus-utils' to 3.0.23.

[Olivier Lamy]

Hi
I'm on holidays with very limited network
I apologise for delay as I was busy before holidays next week might better.


On Wednesday, 29 June 2016, Craig Rodrigues  wrote:

> Hi,
>
> Do you think you will be able to do a release of maven-scm this week?
> I am still receiving queries from Jenkins users who need an updated
> maven-scm
> for the Jenkins SCM Sync Configuration plugin.
>
> Thanks.
>
> --
> Craig
>
>
> On Thu, Jun 9, 2016 at 11:48 PM, Olivier Lamy  > wrote:
>
> > Hi
> > Definitely on my TODO list. I hope to have a bit of time next week.
> > Cheers
> > Olivier
> > PS: thanks for the reminder :-)
> >
> > On 10 June 2016 at 16:34, Craig Rodrigues  > wrote:
> >
> > > Olivier,
> > >
> > > Any ETA on a maven-scm release?  Several Jenkins users have been asking
> > me,
> > > due to the bugfixes that have gone into maven-scm for git since the
> last
> > > maven-scm official release.
> > >
> > > Thanks.
> > >
> > > --
> > > Craig
> > >
> > > On Thu, May 26, 2016 at 5:58 PM, Olivier Lamy  > wrote:
> > >
> > > > ping.
> > > > I will revert this commit as I'd like to cut a release.
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>


-- 
Olivier

[GitHub] maven-archetype issue #8: ARCHETYPE-491

[ptahchiev]

Github user ptahchiev commented on the issue:

https://github.com/apache/maven-archetype/pull/8
  
Hi @michael-o can you have a look at this pull-request. I don't have the 
rights to have it merged.


---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plugin resolution for Maven 3.5

[Anders Hammar]

Not sure I completely understand the question, but we've always said that
you shouldn't use another plugin as a dependency. Re-usable logic should be
kept in a library instead.

/Anders

On Fri, Jul 1, 2016 at 9:16 AM, Christian Schulte  wrote:

> Hi,
>
> I am currently stumbling upon the following issue. Maven resolves
> plugins as if they were a direct dependency of Maven core. That means it
> will not consider any 'test' or 'provided' scope dependencies of plugins
> when building plugin runtime classpaths. I am not sure if this is the
> correct way to go. If it would resolve plugins the same way it resolves
> projects, things like the following will start to happen.
>
> Execution default-resources of goal
> org.apache.maven.plugins:maven-resources-plugin:3.0.1:resources failed:
> A required class was missing while executing
> org.apache.maven.plugins:maven-resources-plugin:3.0.1:resources:
> org/apache/commons/io/input/XmlStreamReader
>
> Caused by: java.lang.ClassNotFoundException:
> org.apache.commons.io.input.XmlStreamReader
>
> Here is the plugin's classpath resolved by Maven <= 3.4.0-SNAPSHOT:
>
>  [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=4,
> ConflictMarker.markTime=4, ConflictMarker.nodeCount=69,
> ConflictIdSorter.graphTime=2, ConflictIdSorter.topsortTime=1,
> ConflictIdSorter.conflictIdCount=28,
> ConflictIdSorter.conflictIdCycleCount=0, ConflictResolver.totalTime=17,
> ConflictResolver.conflictItemCount=68,
> DefaultDependencyCollector.collectTime=850,
> DefaultDependencyCollector.transformTime=36}
> [DEBUG] org.apache.maven.plugins:maven-resources-plugin:jar:3.0.1:
> [DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
> [DEBUG]   org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
> [DEBUG]  org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
> [DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
> [DEBUG]org.apache.maven:maven-core:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-settings-builder:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-repository-metadata:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-model-builder:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-aether-provider:jar:3.0:runtime
> [DEBUG]   org.sonatype.aether:aether-impl:jar:1.7:compile
> [DEBUG]  org.sonatype.aether:aether-spi:jar:1.7:compile
> [DEBUG]   org.sonatype.aether:aether-api:jar:1.7:compile
> [DEBUG]   org.sonatype.aether:aether-util:jar:1.7:compile
> [DEBUG]   org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
> [DEBUG]
> org.codehaus.plexus:plexus-component-annotations:jar:1.6:compile
> [DEBUG]   org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
> [DEBUG]  org.sonatype.plexus:plexus-cipher:jar:1.4:compile
> [DEBUG]org.apache.maven:maven-artifact:jar:3.0:compile
> [DEBUG]org.apache.maven:maven-settings:jar:3.0:compile
> [DEBUG]org.apache.maven:maven-model:jar:3.0:compile
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
> [DEBUG]org.apache.maven.shared:maven-filtering:jar:3.1.1:compile
> [DEBUG]   org.apache.maven.shared:maven-shared-utils:jar:3.0.0:compile
> [DEBUG]  commons-io:commons-io:jar:2.4:compile
> [DEBUG]  com.google.code.findbugs:jsr305:jar:2.0.1:compile
> [DEBUG]   org.sonatype.plexus:plexus-build-api:jar:0.0.7:compile
> [DEBUG]org.codehaus.plexus:plexus-interpolation:jar:1.22:compile
>
> And here is the plugin's classpath resolved the same way projects are
> resolved (3.5.0-SNAPSHOT):
>
> [DEBUG] Dependency collection stats:
> {ConflictMarker.analyzeTime=3907145, ConflictMarker.markTime=5714366,
> ConflictMarker.nodeCount=172, ConflictIdSorter.graphTime=2411000,
> ConflictIdSorter.topsortTime=1248278,
> ConflictIdSorter.conflictIdCount=38,
> ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=21802925,
> ConflictResolver.conflictItemCount=90,
> DefaultDependencyCollector.collectTime=1324192650,
> DefaultDependencyCollector.transformTime=190157370}
> [DEBUG] org.apache.maven.plugins:maven-resources-plugin:jar:3.0.1:
> [DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
> [DEBUG]   org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
> [DEBUG]  org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
> [DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
> [DEBUG]org.apache.maven:maven-core:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-settings-builder:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-repository-metadata:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-model-builder:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-aether-provider:jar:3.0:runtime
> [DEBUG]   org.sonatype.aether:aether-impl:jar:1.7:compile
> [DEBUG]  org.sonatype.aether:aether-spi:jar:1.7:compile
> [DEBUG]   org.sonatype.aether:aether-api:jar:1.7:compile
> [DEBUG]   org.sonatype.aether:aether-util:jar:1

Plugin resolution for Maven 3.5

[Christian Schulte]

Hi,

I am currently stumbling upon the following issue. Maven resolves
plugins as if they were a direct dependency of Maven core. That means it
will not consider any 'test' or 'provided' scope dependencies of plugins
when building plugin runtime classpaths. I am not sure if this is the
correct way to go. If it would resolve plugins the same way it resolves
projects, things like the following will start to happen.

Execution default-resources of goal
org.apache.maven.plugins:maven-resources-plugin:3.0.1:resources failed:
A required class was missing while executing
org.apache.maven.plugins:maven-resources-plugin:3.0.1:resources:
org/apache/commons/io/input/XmlStreamReader

Caused by: java.lang.ClassNotFoundException:
org.apache.commons.io.input.XmlStreamReader

Here is the plugin's classpath resolved by Maven <= 3.4.0-SNAPSHOT:

 [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=4,
ConflictMarker.markTime=4, ConflictMarker.nodeCount=69,
ConflictIdSorter.graphTime=2, ConflictIdSorter.topsortTime=1,
ConflictIdSorter.conflictIdCount=28,
ConflictIdSorter.conflictIdCycleCount=0, ConflictResolver.totalTime=17,
ConflictResolver.conflictItemCount=68,
DefaultDependencyCollector.collectTime=850,
DefaultDependencyCollector.transformTime=36}
[DEBUG] org.apache.maven.plugins:maven-resources-plugin:jar:3.0.1:
[DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG]   org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG]  org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
[DEBUG]org.apache.maven:maven-core:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-settings-builder:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-repository-metadata:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-model-builder:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-aether-provider:jar:3.0:runtime
[DEBUG]   org.sonatype.aether:aether-impl:jar:1.7:compile
[DEBUG]  org.sonatype.aether:aether-spi:jar:1.7:compile
[DEBUG]   org.sonatype.aether:aether-api:jar:1.7:compile
[DEBUG]   org.sonatype.aether:aether-util:jar:1.7:compile
[DEBUG]   org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG]
org.codehaus.plexus:plexus-component-annotations:jar:1.6:compile
[DEBUG]   org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
[DEBUG]  org.sonatype.plexus:plexus-cipher:jar:1.4:compile
[DEBUG]org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG]org.apache.maven:maven-settings:jar:3.0:compile
[DEBUG]org.apache.maven:maven-model:jar:3.0:compile
[DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
[DEBUG]org.apache.maven.shared:maven-filtering:jar:3.1.1:compile
[DEBUG]   org.apache.maven.shared:maven-shared-utils:jar:3.0.0:compile
[DEBUG]  commons-io:commons-io:jar:2.4:compile
[DEBUG]  com.google.code.findbugs:jsr305:jar:2.0.1:compile
[DEBUG]   org.sonatype.plexus:plexus-build-api:jar:0.0.7:compile
[DEBUG]org.codehaus.plexus:plexus-interpolation:jar:1.22:compile

And here is the plugin's classpath resolved the same way projects are
resolved (3.5.0-SNAPSHOT):

[DEBUG] Dependency collection stats:
{ConflictMarker.analyzeTime=3907145, ConflictMarker.markTime=5714366,
ConflictMarker.nodeCount=172, ConflictIdSorter.graphTime=2411000,
ConflictIdSorter.topsortTime=1248278,
ConflictIdSorter.conflictIdCount=38,
ConflictIdSorter.conflictIdCycleCount=0,
ConflictResolver.totalTime=21802925,
ConflictResolver.conflictItemCount=90,
DefaultDependencyCollector.collectTime=1324192650,
DefaultDependencyCollector.transformTime=190157370}
[DEBUG] org.apache.maven.plugins:maven-resources-plugin:jar:3.0.1:
[DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG]   org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG]  org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
[DEBUG]org.apache.maven:maven-core:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-settings-builder:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-repository-metadata:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-model-builder:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-aether-provider:jar:3.0:runtime
[DEBUG]   org.sonatype.aether:aether-impl:jar:1.7:compile
[DEBUG]  org.sonatype.aether:aether-spi:jar:1.7:compile
[DEBUG]   org.sonatype.aether:aether-api:jar:1.7:compile
[DEBUG]   org.sonatype.aether:aether-util:jar:1.7:compile
[DEBUG]   org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG]
org.codehaus.plexus:plexus-component-annotations:jar:1.6:compile
[DEBUG]   org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
[DEBUG]  org.sonatype.plexus:plexus-cipher:jar:1.4:compile
[DEBUG]org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG]org.apache.maven:maven-settings:jar:3.0:compi