date:20160718


sure

On Mon, 18 Jul 2016 22:13:46 +0200, Paul Benedict   
wrote:



Sure, I'll just have to produce a dummy example from my current project.
Can I mail you a zip personally?

Cheers,
Paul

On Mon, Jul 18, 2016 at 3:10 PM, Robert Scholte 
wrote:

Do you have the code somewhere so we can have a look at what's  
happening?

I did a quick look at the scanner code but can't find a reason why ASM
should be leaking.

Robert


On Mon, 18 Jul 2016 22:03:23 +0200, Paul Benedict 
wrote:

If I may expand this thread to the subject of class loaders, how is it
possible that a plugin's own dependencies can ever leak into mine? I  
know

shading is a common solution, but I am curious why this particular
situation can occur at all. Got any insight on the matter? I read the
stock
documentation on this subject [1], but I think more information is  
needed.


[1] http://maven.apache.org/guides/mini/guide-maven-classloading.html

Cheers,
Paul

On Mon, Jul 18, 2016 at 2:39 PM, Robert Scholte 
wrote:

On Mon, 18 Jul 2016 19:18:36 +0200, Paul Benedict  


wrote:

Hi. It seems when I build my maven plugin, ASM is being used to scan  
for

my


Mojo annotations. I use ASM internally for my own code. My ASM is the
latest 6.0_ALPHA and it's causing an NPE when the Maven Plugin Plugin
executes. If I downgrade to something less, then there is no
interference
with the build.

I am surprised to see ASM leak into my plugin like this. Whatever
version
I
am using is clearly affecting the Plugin Plugin. I would classify  
this
behavior as a bug -- no need for ASM to leak into my project.  
Thoughts?


Cheers,
Paul


Hard to tell, you might be right. Unless it is something like  
surefire,

which also needs surefire to execute the unittests. This causes class
collisions, so surefire uses a shaded version of the
maven-surefire-plugin
to handle this.
If we can't isolate ASM, we might need to shade or have a second
implementation.

Robert

-
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



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

Re: ASM leaking into my plugin build

Sure, I'll just have to produce a dummy example from my current project.
Can I mail you a zip personally?

Cheers,
Paul

On Mon, Jul 18, 2016 at 3:10 PM, Robert Scholte 
wrote:

> Do you have the code somewhere so we can have a look at what's happening?
> I did a quick look at the scanner code but can't find a reason why ASM
> should be leaking.
>
> Robert
>
>
> On Mon, 18 Jul 2016 22:03:23 +0200, Paul Benedict 
> wrote:
>
> If I may expand this thread to the subject of class loaders, how is it
>> possible that a plugin's own dependencies can ever leak into mine? I know
>> shading is a common solution, but I am curious why this particular
>> situation can occur at all. Got any insight on the matter? I read the
>> stock
>> documentation on this subject [1], but I think more information is needed.
>>
>> [1] http://maven.apache.org/guides/mini/guide-maven-classloading.html
>>
>> Cheers,
>> Paul
>>
>> On Mon, Jul 18, 2016 at 2:39 PM, Robert Scholte 
>> wrote:
>>
>> On Mon, 18 Jul 2016 19:18:36 +0200, Paul Benedict 
>>> wrote:
>>>
>>> Hi. It seems when I build my maven plugin, ASM is being used to scan for
>>> my
>>>
 Mojo annotations. I use ASM internally for my own code. My ASM is the
 latest 6.0_ALPHA and it's causing an NPE when the Maven Plugin Plugin
 executes. If I downgrade to something less, then there is no
 interference
 with the build.

 I am surprised to see ASM leak into my plugin like this. Whatever
 version
 I
 am using is clearly affecting the Plugin Plugin. I would classify this
 behavior as a bug -- no need for ASM to leak into my project. Thoughts?

 Cheers,
 Paul


>>> Hard to tell, you might be right. Unless it is something like surefire,
>>> which also needs surefire to execute the unittests. This causes class
>>> collisions, so surefire uses a shaded version of the
>>> maven-surefire-plugin
>>> to handle this.
>>> If we can't isolate ASM, we might need to shade or have a second
>>> implementation.
>>>
>>> Robert
>>>
>>> -
>>> 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: ASM leaking into my plugin build


Do you have the code somewhere so we can have a look at what's happening?
I did a quick look at the scanner code but can't find a reason why ASM  
should be leaking.


Robert

On Mon, 18 Jul 2016 22:03:23 +0200, Paul Benedict   
wrote:



If I may expand this thread to the subject of class loaders, how is it
possible that a plugin's own dependencies can ever leak into mine? I know
shading is a common solution, but I am curious why this particular
situation can occur at all. Got any insight on the matter? I read the  
stock
documentation on this subject [1], but I think more information is  
needed.


[1] http://maven.apache.org/guides/mini/guide-maven-classloading.html

Cheers,
Paul

On Mon, Jul 18, 2016 at 2:39 PM, Robert Scholte 
wrote:


On Mon, 18 Jul 2016 19:18:36 +0200, Paul Benedict 
wrote:

Hi. It seems when I build my maven plugin, ASM is being used to scan  
for my

Mojo annotations. I use ASM internally for my own code. My ASM is the
latest 6.0_ALPHA and it's causing an NPE when the Maven Plugin Plugin
executes. If I downgrade to something less, then there is no  
interference

with the build.

I am surprised to see ASM leak into my plugin like this. Whatever  
version

I
am using is clearly affecting the Plugin Plugin. I would classify this
behavior as a bug -- no need for ASM to leak into my project. Thoughts?

Cheers,
Paul



Hard to tell, you might be right. Unless it is something like surefire,
which also needs surefire to execute the unittests. This causes class
collisions, so surefire uses a shaded version of the  
maven-surefire-plugin

to handle this.
If we can't isolate ASM, we might need to shade or have a second
implementation.

Robert

-
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: ASM leaking into my plugin build

If I may expand this thread to the subject of class loaders, how is it
possible that a plugin's own dependencies can ever leak into mine? I know
shading is a common solution, but I am curious why this particular
situation can occur at all. Got any insight on the matter? I read the stock
documentation on this subject [1], but I think more information is needed.

[1] http://maven.apache.org/guides/mini/guide-maven-classloading.html

Cheers,
Paul

On Mon, Jul 18, 2016 at 2:39 PM, Robert Scholte 
wrote:

> On Mon, 18 Jul 2016 19:18:36 +0200, Paul Benedict 
> wrote:
>
> Hi. It seems when I build my maven plugin, ASM is being used to scan for my
>> Mojo annotations. I use ASM internally for my own code. My ASM is the
>> latest 6.0_ALPHA and it's causing an NPE when the Maven Plugin Plugin
>> executes. If I downgrade to something less, then there is no interference
>> with the build.
>>
>> I am surprised to see ASM leak into my plugin like this. Whatever version
>> I
>> am using is clearly affecting the Plugin Plugin. I would classify this
>> behavior as a bug -- no need for ASM to leak into my project. Thoughts?
>>
>> Cheers,
>> Paul
>>
>
> Hard to tell, you might be right. Unless it is something like surefire,
> which also needs surefire to execute the unittests. This causes class
> collisions, so surefire uses a shaded version of the maven-surefire-plugin
> to handle this.
> If we can't isolate ASM, we might need to shade or have a second
> implementation.
>
> Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Use maven-invoker-plugin to run a Maven plugin on itself

Hi,

On 7/18/16 9:31 PM, Behrooz Nobakht wrote:

Hi,

Thanks for the reply and I agree with the logical circular dependency
argument.
But I still believe that this is valid test/use case for a Maven plugin
being developed.

I don't agree with that...cause for those things it is best having IT's
based on maven-invoker-pluginwhich will solves the problem here..

The profile idea 'self-test/run' works in this case for what I'm working on;
but I think main reason is that logic here only applies to Java sources and
the default is process-sources. In this, the plugin needs to run against
itself
before any release.

The problem here is simply you need to do a mvn install before anything
else..without a preliminary install you won't get it working...cause
during the release process you need an installed version of your
plugin..but this must be a SNAPSHOT version which can't be used during a
release cause you will rely on an unstable non reproducible artifact (it
does not matter if its a plugin or a dependency)...You will create a tag
from that state which makes that permanent which is simply wrong! (Apart
from that the release plugin will prevent that already)...

Nevertheless that profile does not really change a thing here...

In it's consquence it's wrong...This kind of bootstrap can be handled by
using maven-invoker-plugin to write appropriate integration tests...

Apart from that I don't see any change here if this would be
C++/Kotlin/Groovy or something else ?

Kind regards
Karl Heinz

Regards,
Behrooz

On Mon, Jul 18, 2016 at 1:00 PM, Karl Heinz Marbaise
wrote:

Hi,

trying to run your own plugin which you are developing within the same
project will not work cause that already sounds like a circle ..

That's the reason to use invoker-plugin to have full fledged project
running as tests...

A profile will not really help, cause you need to do a `mvn install` first
and than run your project with something like `mvn -Pself-testing verify` ?
Not a good idea?

And finally this is not best practice...

What you can do is to define a previous released version of your plugin in
your pom ...That's what for example maven-invoker-plugin itself is doing..
;-)

Kind regards
Karl Heinz Marbaise

On 7/18/16 9:43 AM, Behrooz Nobakht wrote:

Hi,

I am developing a Maven Plugin and trying to follow documentation[1] to
use
maven-invoker-plugin
from the auto-generated profile 'run-its' to run an execution of the
plugin
under dev on itself.

As an example, let's consider mojouas/license-maven-plugin. One of it's
goals is 'update-file-header'.
And, it actually has an integration-test executed by maven-invoker-plugin
but it's on a sample project.
What if I wanted to run the update-file-header on the license-maven-plugin
itself? How?

One straight way would be introduce another profile to configure the
plugin
to run on itself, but is this a
good practice on Maven plugin development?

Thanks,
Behrooz

[1]: http://maven.apache.org/plugins/maven-invoker-plugin/
[2]:

https://github.com/mojohaus/license-maven-plugin/tree/master/src/it/update-file-header-test-mojo

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

Re: ASM leaking into my plugin build

On Mon, 18 Jul 2016 19:18:36 +0200, Paul Benedict   
wrote:


Hi. It seems when I build my maven plugin, ASM is being used to scan for  
my

Mojo annotations. I use ASM internally for my own code. My ASM is the
latest 6.0_ALPHA and it's causing an NPE when the Maven Plugin Plugin
executes. If I downgrade to something less, then there is no interference
with the build.

I am surprised to see ASM leak into my plugin like this. Whatever  
version I

am using is clearly affecting the Plugin Plugin. I would classify this
behavior as a bug -- no need for ASM to leak into my project. Thoughts?

Cheers,
Paul


Hard to tell, you might be right. Unless it is something like surefire,  
which also needs surefire to execute the unittests. This causes class  
collisions, so surefire uses a shaded version of the maven-surefire-plugin  
to handle this.
If we can't isolate ASM, we might need to shade or have a second  
implementation.


Robert

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

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


Hi Karl Heinz,

I would expect the problem to be in the maven-aether-provider.
Aether does all the management, but it is this provider which decides what  
are dependencies.
And yes, there's a cache:  
org.apache.maven.repository.internal.DefaultModelCache


Robert


On Mon, 18 Jul 2016 20:40:26 +0200, Karl Heinz Marbaise  
 wrote:



Hi,

no one and idea ?

Kind regards
Karl Heinz


On 7/17/16 11:46 AM, Karl Heinz Marbaise wrote:

Hi,

so after I found the issue related to reactor order (MNG-6057) (Thanks
Robert for the tip which brought me to right direction) now I'm diving
more into the problem related to the resolution of the artifacts which I
have described related to maven-assembly-plugin after more testing I
have found that it seemed to be related to the following line of code:


@Requirement
private RepositorySystem resolver;
...

And the following line is the culprit (transition to Maven Core):

result = resolver.resolve( req );

The request in maven-assembly-plugin seemed to be filled with the
correct data:
final MavenProject project = configSource.getProject();

ArtifactResolutionRequest req = new ArtifactResolutionRequest();
req.setLocalRepository( configSource.getLocalRepository() );
req.setResolveRoot( false );
req.setRemoteRepositories( repos );
req.setResolveTransitively( true );
req.setArtifact( project.getArtifact() );
req.setArtifactDependencies( dependencyArtifacts );
req.setManagedVersionMap( project.getManagedVersionMap() );
req.setCollectionFilter( filter );
req.setOffline( configSource.getMavenSession().isOffline() );
req.setForceUpdate(
configSource.getMavenSession().getRequest().isUpdateSnapshots() );
req.setServers(
configSource.getMavenSession().getRequest().getServers() );
req.setMirrors(
configSource.getMavenSession().getRequest().getMirrors() );
req.setProxies(
configSource.getMavenSession().getRequest().getProxies() );

And non of the above data does contain the wrong versions
(1.7.2-SNAPSHOT), but I get always errors like this:

[DEBUG] Could not find metadata
com.soebes.examples.j2ee:service-client:1.7.2-SNAPSHOT/maven-metadata.xml  
in

local (/Users/kama/.m2/repository)
[WARNING] Missing POM for
com.soebes.examples.j2ee:service-client:jar:1.7.2-SNAPSHOT: Error
resolving project artifact: Could not find artifact
com.soebes.examples.j2ee:service-client:pom:1.7.2-SNAPSHOT for project
com.soebes.examples.j2ee:service-client:pom:1.7.2-SNAPSHOT
[DEBUG] Could not find metadata
com.soebes.examples.j2ee:webgui:1.7.2-SNAPSHOT/maven-metadata.xml in
local (/Users/kama/.m2/repository)


What I can't explain where those wrong version numbers are coming from?
Is there a kind of cache involved which contains this versions ? Where
is this defined? Can I clean it ? (RepositorySystem)

At the moment I'm convinced that it is a Maven core issue.

The RepositorySystem is an interface where two implementation
exist:LegacyRepositorySystem and TestMavenRepositorySystem.

So LegacyRepositorySystem contains an appropriate implementation of:

public ArtifactResolutionResult resolve( ArtifactResolutionRequest
request )


But I can't find a hint of where those wrong version numbers could come
from cause the ArtifactResolutionRequest contains the correct data ...


Anyone an idea? Hint ? Good questions?

Kind regards
Karl Heinz Marbaise


So this looks at the moment like an issue in Maven core...


-
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: Use maven-invoker-plugin to run a Maven plugin on itself

2016-07-18 Thread Behrooz Nobakht

Hi,

Thanks for the reply and I agree with the logical circular dependency
argument.
But I still believe that this is valid test/use case for a Maven plugin
being
developed.

The profile idea 'self-test/run' works in this case for what I'm working on;
but I think main reason is that logic here only applies to Java sources and
the default is process-sources. In this, the plugin needs to run against
itself
before any release.

Regards,
Behrooz


On Mon, Jul 18, 2016 at 1:00 PM, Karl Heinz Marbaise 
wrote:

>
> Hi,
>
> trying to run your own plugin which you are developing within the same
> project will not work cause that already sounds like a circle ..
>
> That's the reason to use invoker-plugin to have full fledged project
> running as tests...
>
> A profile will not really help, cause you need to do a `mvn install` first
> and than run your project with something like `mvn -Pself-testing verify` ?
> Not a good idea?
>
> And finally this is not best practice...
>
> What you can do is to define a previous released version of your plugin in
> your pom ...That's what for example maven-invoker-plugin itself is doing..
> ;-)
>
>
> Kind regards
> Karl Heinz Marbaise
>
> On 7/18/16 9:43 AM, Behrooz Nobakht wrote:
>
>> Hi,
>>
>> I am developing a Maven Plugin and trying to follow documentation[1] to
>> use
>> maven-invoker-plugin
>> from the auto-generated profile 'run-its' to run an execution of the
>> plugin
>> under dev on itself.
>>
>> As an example, let's consider mojouas/license-maven-plugin. One of it's
>> goals is 'update-file-header'.
>> And, it actually has an integration-test executed by maven-invoker-plugin
>> but it's on a sample project.
>> What if I wanted to run the update-file-header on the license-maven-plugin
>> itself? How?
>>
>> One straight way would be introduce another profile to configure the
>> plugin
>> to run on itself, but is this a
>> good practice on Maven plugin development?
>>
>> Thanks,
>> Behrooz
>>
>>
>>
>> [1]: http://maven.apache.org/plugins/maven-invoker-plugin/
>> [2]:
>>
>> https://github.com/mojohaus/license-maven-plugin/tree/master/src/it/update-file-header-test-mojo
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
-- Behrooz Nobakht

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


Hi,

no one and idea ?

Kind regards
Karl Heinz


On 7/17/16 11:46 AM, Karl Heinz Marbaise wrote:

Hi,

so after I found the issue related to reactor order (MNG-6057) (Thanks
Robert for the tip which brought me to right direction) now I'm diving
more into the problem related to the resolution of the artifacts which I
have described related to maven-assembly-plugin after more testing I
have found that it seemed to be related to the following line of code:


@Requirement
private RepositorySystem resolver;
...

And the following line is the culprit (transition to Maven Core):

result = resolver.resolve( req );

The request in maven-assembly-plugin seemed to be filled with the
correct data:
final MavenProject project = configSource.getProject();

ArtifactResolutionRequest req = new ArtifactResolutionRequest();
req.setLocalRepository( configSource.getLocalRepository() );
req.setResolveRoot( false );
req.setRemoteRepositories( repos );
req.setResolveTransitively( true );
req.setArtifact( project.getArtifact() );
req.setArtifactDependencies( dependencyArtifacts );
req.setManagedVersionMap( project.getManagedVersionMap() );
req.setCollectionFilter( filter );
req.setOffline( configSource.getMavenSession().isOffline() );
req.setForceUpdate(
configSource.getMavenSession().getRequest().isUpdateSnapshots() );
req.setServers(
configSource.getMavenSession().getRequest().getServers() );
req.setMirrors(
configSource.getMavenSession().getRequest().getMirrors() );
req.setProxies(
configSource.getMavenSession().getRequest().getProxies() );

And non of the above data does contain the wrong versions
(1.7.2-SNAPSHOT), but I get always errors like this:

[DEBUG] Could not find metadata
com.soebes.examples.j2ee:service-client:1.7.2-SNAPSHOT/maven-metadata.xml in
local (/Users/kama/.m2/repository)
[WARNING] Missing POM for
com.soebes.examples.j2ee:service-client:jar:1.7.2-SNAPSHOT: Error
resolving project artifact: Could not find artifact
com.soebes.examples.j2ee:service-client:pom:1.7.2-SNAPSHOT for project
com.soebes.examples.j2ee:service-client:pom:1.7.2-SNAPSHOT
[DEBUG] Could not find metadata
com.soebes.examples.j2ee:webgui:1.7.2-SNAPSHOT/maven-metadata.xml in
local (/Users/kama/.m2/repository)


What I can't explain where those wrong version numbers are coming from?
Is there a kind of cache involved which contains this versions ? Where
is this defined? Can I clean it ? (RepositorySystem)

At the moment I'm convinced that it is a Maven core issue.

The RepositorySystem is an interface where two implementation
exist:LegacyRepositorySystem and TestMavenRepositorySystem.

So LegacyRepositorySystem contains an appropriate implementation of:

public ArtifactResolutionResult resolve( ArtifactResolutionRequest
request )


But I can't find a hint of where those wrong version numbers could come
from cause the ArtifactResolutionRequest contains the correct data ...


Anyone an idea? Hint ? Good questions?

Kind regards
Karl Heinz Marbaise


So this looks at the moment like an issue in Maven core...


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

Re: Extending Maven to allow scope resolutions for other languages than Java

On Mon, 18 Jul 2016 15:54:24 +0200, Christian Schulte
wrote:

Am 07/18/16 um 15:02 schrieb Christofer Dutz:

Hi,

Unfortuantely I wrote this down as a Jira ticket, but it seems it
wasn't created in the end so I'll post this via Email ;-)

I am currently working on clean support for Apache Flex build with
Maven. Prior to 3.3.1 non-java builds were sort of relying on a
scope-resolution bug that was fixed in newer version. Now non-default
scopes can no longer have transitive dependencies. In order to fix
this, I did a little refactoring of the scope resolution code in
MavenRepositorySystemUtils.newSession().

The idea is to wrap together the language-dependent parts of the scope
resolution and have these automatically injected into
DefaultRepositorySystemFactory. Per default there would only be one
instance (JavaLanguageSupport) available. But I could provide other
LanguageSupport implementations for other languages via Maven
extensions.

I implemented this as a POC. I didn't find my changes breaking anything
in the maven test-suite and I was able to add my FlexJsLanguageSupport
to maven and have it called for scope resolution requests.

I just pushed a commit to my maven fork:

https://github.com/chrisdutz/maven/commit/cd205837540c3df74ad4a8eb8b6c710a93cff156

And here ist the FlexJS counterpart:

https://git1-us-west.apache.org/repos/asf?p=flex-falcon.git;a=commit;h=aea14be67db2b28b766d274d900ce076fdb8522b

Does it make sense to invest more time into this feature, or is this
road a dead-end?

Instead of adding that 'LanguageSupport' interface, I would go for
injecting the 'DependencyGraphTransformer' to use directly. No need for
a new interface. So that a customized 'ConflictResolver' can be injected
you can setup the way you want. Makes things like your
'MultiLanguageScopeDeriver' part of your extension instead of Maven
core. I think some kind of 'DependencyGraphTransformer' extension point
will be provided in 3.5. Maybe there will be more than just one
transformer for the various classpaths. We currently resolve the project
artifacts once and then make Maven build the classpaths based on those
artifacts. In 3.5 this may be enhanced to provide various artifact
resolution strategies based on the classpath to build. So that
'MavenProject.getCompileClasspathElements' may provide different
artifacts than 'MavenProject.getTestClasspathElements'. Nothing concrete
yet.

Regards,

I'd like to deprecate both MavenProject.getClasspathElements and
MavenProject.getTestClasspathElements. These are too tightly bound to
Java, whereas Maven should be language independent.
Yes, I thought of language extensions too, but with the new visions
regarding scopes it might not be necessary anymore.

Robert

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

Re: maven git commit: [MNG-6069] Migrated to non deprecated API of Commons CLI o Migrated calls of OptionBuilder to Option.builder( ... )...build(). [Forced Update!]


Am 18.07.2016 um 19:59 schrieb Karl Heinz Marbaise:

Hi Christian,

thanks for the hint...

So this means at the moment not to migrate this (or to merge the
branch)..simply until a fixed version is available...



I am not sure this will ever get fixed. The DefaultParser is based on a 
short option to contain only a single character almost everywhere.



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

Re: maven git commit: [MNG-6069] Migrated to non deprecated API of Commons CLI o Migrated calls of OptionBuilder to Option.builder( ... )...build(). [Forced Update!]


Hi Christian,

thanks for the hint...

So this means at the moment not to migrate this (or to merge the 
branch)..simply until a fixed version is available...


Kind regards
Karl Heinz
On 7/18/16 7:54 PM, Christian Schulte wrote:

Watch out for . The
DefaultParser is severely broken regarding long options. See my example
at CLI-255.

Am 18.07.2016 um 19:49 schrieb khmarba...@apache.org:

Repository: maven
Updated Branches:
  refs/heads/MNG-6069 8a89efd9e -> 2b567a7d9 (forced update)


[MNG-6069] Migrated to non deprecated API of Commons CLI
 o Migrated calls of OptionBuilder to Option.builder( ... )...build().


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

Re: maven git commit: [MNG-6069] Migrated to non deprecated API of Commons CLI o Migrated calls of OptionBuilder to Option.builder( ... )...build(). [Forced Update!]

Watch out for . The 
DefaultParser is severely broken regarding long options. See my example 
at CLI-255.


Am 18.07.2016 um 19:49 schrieb khmarba...@apache.org:

Repository: maven
Updated Branches:
  refs/heads/MNG-6069 8a89efd9e -> 2b567a7d9 (forced update)


[MNG-6069] Migrated to non deprecated API of Commons CLI
 o Migrated calls of OptionBuilder to Option.builder( ... )...build().


Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/2b567a7d
Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/2b567a7d
Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/2b567a7d

Branch: refs/heads/MNG-6069
Commit: 2b567a7d9d713174dc74d3ae6b3a0c1651cab489
Parents: 90f26c2
Author: Karl Heinz Marbaise 
Authored: Mon Jul 18 12:29:18 2016 +0200
Committer: Karl Heinz Marbaise 
Committed: Mon Jul 18 19:48:10 2016 +0200

--
 .../java/org/apache/maven/cli/CLIManager.java   | 120 ++-
 .../java/org/apache/maven/cli/MavenCli.java |   1 +
 2 files changed, 63 insertions(+), 58 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/maven/blob/2b567a7d/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
--
diff --git a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java 
b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
index f86f48b..506df6f 100644
--- a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
+++ b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
@@ -24,9 +24,9 @@ import java.io.PrintWriter;

 import org.apache.commons.cli.CommandLine;
 import org.apache.commons.cli.CommandLineParser;
-import org.apache.commons.cli.GnuParser;
+import org.apache.commons.cli.DefaultParser;
 import org.apache.commons.cli.HelpFormatter;
-import org.apache.commons.cli.OptionBuilder;
+import org.apache.commons.cli.Option;
 import org.apache.commons.cli.Options;
 import org.apache.commons.cli.ParseException;

@@ -35,43 +35,43 @@ import org.apache.commons.cli.ParseException;
  */
 public class CLIManager
 {
-public static final char ALTERNATE_POM_FILE = 'f';
+public static final String ALTERNATE_POM_FILE = "f";

-public static final char BATCH_MODE = 'B';
+public static final String BATCH_MODE = "B";

-public static final char SET_SYSTEM_PROPERTY = 'D';
+public static final String SET_SYSTEM_PROPERTY = "D";

-public static final char OFFLINE = 'o';
+public static final String OFFLINE = "o";

-public static final char QUIET = 'q';
+public static final String QUIET = "q";

-public static final char DEBUG = 'X';
+public static final String DEBUG = "X";

-public static final char ERRORS = 'e';
+public static final String ERRORS = "e";

-public static final char HELP = 'h';
+public static final String HELP = "h";

-public static final char VERSION = 'v';
+public static final String VERSION = "v";

-public static final char SHOW_VERSION = 'V';
+public static final String SHOW_VERSION = "V";

-public static final char NON_RECURSIVE = 'N';
+public static final String NON_RECURSIVE = "N";

-public static final char UPDATE_SNAPSHOTS = 'U';
+public static final String UPDATE_SNAPSHOTS = "U";

-public static final char ACTIVATE_PROFILES = 'P';
+public static final String ACTIVATE_PROFILES = "P";

 public static final String SUPRESS_SNAPSHOT_UPDATES = "nsu";

-public static final char CHECKSUM_FAILURE_POLICY = 'C';
+public static final String CHECKSUM_FAILURE_POLICY = "C";

-public static final char CHECKSUM_WARNING_POLICY = 'c';
+public static final String CHECKSUM_WARNING_POLICY = "c";

-public static final char ALTERNATE_USER_SETTINGS = 's';
+public static final String ALTERNATE_USER_SETTINGS = "s";

 public static final String ALTERNATE_GLOBAL_SETTINGS = "gs";

-public static final char ALTERNATE_USER_TOOLCHAINS = 't';
+public static final String ALTERNATE_USER_TOOLCHAINS = "t";

 public static final String ALTERNATE_GLOBAL_TOOLCHAINS = "gt";

@@ -107,45 +107,49 @@ public class CLIManager
 public CLIManager()
 {
 options = new Options();
-options.addOption( OptionBuilder.withLongOpt( "help" ).withDescription( 
"Display help information" ).create( HELP ) );
-options.addOption( OptionBuilder.withLongOpt( "file" ).hasArg().withDescription( 
"Force the use of an alternate POM file (or directory with pom.xml)" ).create( 
ALTERNATE_POM_FILE ) );
-options.addOption( OptionBuilder.withLongOpt( "define" 
).hasArg().withDescription( "Define a system property" ).create( SET_SYSTEM_PROPERTY ) );
-

Re: svn commit: r1753099 - in /maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features: simple-dir-format/ this & that/


Hi Guillaume,

the next time you see a file or folder with spaces and special characters  
you'll probably recognize the reason. But if you think that it'll help, go  
ahead.


Robert

On Sun, 17 Jul 2016 22:50:20 +0200, Guillaume Boué  
 wrote:



Hi Robert,

I see, I will try to debug why the test is failing for spaces and special
characters. How about naming the folder "space & special char" instead?  
It

would make it clearer that this is the purpose of the test.

Regards,
Guillaume

2016-07-17 22:39 GMT+02:00 Robert Scholte :


Hi Guillaume,

there's a reason why this directory was called like this (spaces +  
special

character).
It is failing on my Windows machine too, but haven't investigated why it
is failing, I think the Plexus Commandline doesn't like it...
This should be reverted and fixed or excluded for Windows, i.e
invoker.family = !windows

thanks,
Robert


On Sun, 17 Jul 2016 20:34:02 +0200,  wrote:

Author: gboue

Date: Sun Jul 17 18:34:01 2016
New Revision: 1753099

URL: http://svn.apache.org/viewvc?rev=1753099=rev
Log:
Renamed "this & that" IT test folder to "simple-dir-format", as this
breaks the ITs when run on Windows: the '&' gets interpreted and  
Windows

tries to launch the "that" program.

Added:

maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features/simple-dir-format/
  - copied from r1753098,
maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features/this
& that/
Removed:

maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features/this
& that/



-
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

ASM leaking into my plugin build

Hi. It seems when I build my maven plugin, ASM is being used to scan for my
Mojo annotations. I use ASM internally for my own code. My ASM is the
latest 6.0_ALPHA and it's causing an NPE when the Maven Plugin Plugin
executes. If I downgrade to something less, then there is no interference
with the build.

I am surprised to see ASM leak into my plugin like this. Whatever version I
am using is clearly affecting the Plugin Plugin. I would classify this
behavior as a bug -- no need for ASM to leak into my project. Thoughts?

Cheers,
Paul

Re: Banner for deprecated plugin documentation

Any thoughts on this? Could it coincide with the new skinning initiative?

Cheers,
Paul

On Wed, Jun 29, 2016 at 4:31 PM, Paul Benedict  wrote:

> All,
>
> Today I googled for "maven blank webapp archetype" and the top hit is an
> example published using 1.0-alpha-7 of the Archetype plugin. Unfortunately,
> I didn't catch that the page was for a plugin version so old. I wasted a
> good 15 minutes (at least).
>
> It would be really useful to include an SSI banner for pages in the
> /plugins-archives folder [1] so that users know they are looking at stale
> information. Apache does something similar with Attic projects [2] already.
>
> WDYT? I think it's a disservice not to call out old documentation.
>
> [1] https://maven.apache.org/plugins-archives/
> [2] http://jakarta.apache.org/
>
> Cheers,
> Paul
>

Re: Extending Maven to allow scope resolutions for other languages than Java

Am 07/18/16 um 15:54 schrieb Christian Schulte:
> Am 07/18/16 um 15:02 schrieb Christofer Dutz:
>> Hi,
>>
>>
>> Unfortuantely I wrote this down as a Jira ticket, but it seems it wasn't 
>> created in the end so I'll post this via Email ;-)
>>
>>
>> I am currently working on clean support for Apache Flex build with Maven. 
>> Prior to 3.3.1 non-java builds were sort of relying on a scope-resolution 
>> bug that was fixed in newer version. Now non-default scopes can no longer 
>> have transitive dependencies. In order to fix this, I did a little 
>> refactoring of the scope resolution code in 
>> MavenRepositorySystemUtils.newSession().
>>
>>
>> The idea is to wrap together the language-dependent parts of the scope 
>> resolution and have these automatically injected into 
>> DefaultRepositorySystemFactory. Per default there would only be one instance 
>> (JavaLanguageSupport) available. But I could provide other LanguageSupport 
>> implementations for other languages via Maven extensions.
>>
>>
>> I implemented this as a POC. I didn't find my changes breaking anything in 
>> the maven test-suite and I was able to add my FlexJsLanguageSupport to maven 
>> and have it called for scope resolution requests.
>>
>>
>> I just pushed a commit to my maven fork:
>>
>> https://github.com/chrisdutz/maven/commit/cd205837540c3df74ad4a8eb8b6c710a93cff156
>>
>> And here ist the FlexJS counterpart:
>>
>> https://git1-us-west.apache.org/repos/asf?p=flex-falcon.git;a=commit;h=aea14be67db2b28b766d274d900ce076fdb8522b
>>
>>
>> Does it make sense to invest more time into this feature, or is this road a 
>> dead-end?
>>
> 
> Instead of adding that 'LanguageSupport' interface, I would go for
> injecting the 'DependencyGraphTransformer' to use directly. No need for
> a new interface. So that a customized 'ConflictResolver' can be injected
> you can setup the way you want. Makes things like your
> 'MultiLanguageScopeDeriver' part of your extension instead of Maven
> core. I think some kind of 'DependencyGraphTransformer' extension point
> will be provided in 3.5. Maybe there will be more than just one
> transformer for the various classpaths. We currently resolve the project
> artifacts once and then make Maven build the classpaths based on those
> artifacts. In 3.5 this may be enhanced to provide various artifact
> resolution strategies based on the classpath to build. So that
> 'MavenProject.getCompileClasspathElements' may provide different
> artifacts than 'MavenProject.getTestClasspathElements'. Nothing concrete
> yet.
> 
> Regards,
> 

'DependencyGraphTransformer' is declared in 'aether-api'.
'ConflictResolver.ScopeDeriver' etc. are declared in 'aether-util'.
Either we want the extension point based on 'aether-api', or we will add
a new interface to Maven core for delegation. That interface could be
named 'DependencyGraphTransformer' as well but declared somewhere Maven.

Regards,
-- 
Christian


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

Re: Extending Maven to allow scope resolutions for other languages than Java

Am 07/18/16 um 15:02 schrieb Christofer Dutz:
> Hi,
> 
> 
> Unfortuantely I wrote this down as a Jira ticket, but it seems it wasn't 
> created in the end so I'll post this via Email ;-)
> 
> 
> I am currently working on clean support for Apache Flex build with Maven. 
> Prior to 3.3.1 non-java builds were sort of relying on a scope-resolution bug 
> that was fixed in newer version. Now non-default scopes can no longer have 
> transitive dependencies. In order to fix this, I did a little refactoring of 
> the scope resolution code in MavenRepositorySystemUtils.newSession().
> 
> 
> The idea is to wrap together the language-dependent parts of the scope 
> resolution and have these automatically injected into 
> DefaultRepositorySystemFactory. Per default there would only be one instance 
> (JavaLanguageSupport) available. But I could provide other LanguageSupport 
> implementations for other languages via Maven extensions.
> 
> 
> I implemented this as a POC. I didn't find my changes breaking anything in 
> the maven test-suite and I was able to add my FlexJsLanguageSupport to maven 
> and have it called for scope resolution requests.
> 
> 
> I just pushed a commit to my maven fork:
> 
> https://github.com/chrisdutz/maven/commit/cd205837540c3df74ad4a8eb8b6c710a93cff156
> 
> And here ist the FlexJS counterpart:
> 
> https://git1-us-west.apache.org/repos/asf?p=flex-falcon.git;a=commit;h=aea14be67db2b28b766d274d900ce076fdb8522b
> 
> 
> Does it make sense to invest more time into this feature, or is this road a 
> dead-end?
> 

Instead of adding that 'LanguageSupport' interface, I would go for
injecting the 'DependencyGraphTransformer' to use directly. No need for
a new interface. So that a customized 'ConflictResolver' can be injected
you can setup the way you want. Makes things like your
'MultiLanguageScopeDeriver' part of your extension instead of Maven
core. I think some kind of 'DependencyGraphTransformer' extension point
will be provided in 3.5. Maybe there will be more than just one
transformer for the various classpaths. We currently resolve the project
artifacts once and then make Maven build the classpaths based on those
artifacts. In 3.5 this may be enhanced to provide various artifact
resolution strategies based on the classpath to build. So that
'MavenProject.getCompileClasspathElements' may provide different
artifacts than 'MavenProject.getTestClasspathElements'. Nothing concrete
yet.

Regards,
-- 
Christian


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

Extending Maven to allow scope resolutions for other languages than Java

2016-07-18 Thread Christofer Dutz

Hi,


Unfortuantely I wrote this down as a Jira ticket, but it seems it wasn't 
created in the end so I'll post this via Email ;-)


I am currently working on clean support for Apache Flex build with Maven. Prior 
to 3.3.1 non-java builds were sort of relying on a scope-resolution bug that 
was fixed in newer version. Now non-default scopes can no longer have 
transitive dependencies. In order to fix this, I did a little refactoring of 
the scope resolution code in MavenRepositorySystemUtils.newSession().


The idea is to wrap together the language-dependent parts of the scope 
resolution and have these automatically injected into 
DefaultRepositorySystemFactory. Per default there would only be one instance 
(JavaLanguageSupport) available. But I could provide other LanguageSupport 
implementations for other languages via Maven extensions.


I implemented this as a POC. I didn't find my changes breaking anything in the 
maven test-suite and I was able to add my FlexJsLanguageSupport to maven and 
have it called for scope resolution requests.


I just pushed a commit to my maven fork:

https://github.com/chrisdutz/maven/commit/cd205837540c3df74ad4a8eb8b6c710a93cff156

And here ist the FlexJS counterpart:

https://git1-us-west.apache.org/repos/asf?p=flex-falcon.git;a=commit;h=aea14be67db2b28b766d274d900ce076fdb8522b


Does it make sense to invest more time into this feature, or is this road a 
dead-end?


Chris

Re: Use maven-invoker-plugin to run a Maven plugin on itself