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

Hi, It turns out there is a bug inside mvn.cmd when evaluating the working directory with %CD%: this needs to be escaped by enclosing the "set var" declaration in double quotes. I tested with the mvn.cmd of the latest 3.4.0-SNAPSHOT and this is apparently already fixed (MNG-5962). I reverted the

[GitHub] maven pull request #88: [MNG-5910] Fixed the description of the POM referenc...

GitHub user rajivpjs opened a pull request: https://github.com/apache/maven/pull/88 [MNG-5910] Fixed the description of the POM reference & added an exce… Please review and let me know any changes. Thanks. You can merge this pull request into a Git repository by running:

Re: ASM leaking into my plugin build

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Extending Maven to allow scope resolutions for other languages than Java

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

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

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

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

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