[GitHub] maven issue #88: [MNG-5910] Fixed the description of the POM reference & add...

[rajivpjs]

Github user rajivpjs commented on the issue:

https://github.com/apache/maven/pull/88
  
@khmarbaise - I have it working now. Please see changes. This works by 
enabling @Test annotations together with @Rule.


---
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: Extending Maven to allow scope resolutions for other languages than Java

[Christian Schulte]

Am 07/18/16 um 20:39 schrieb Robert Scholte:
> 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.

+1

And I am all for adding an interface allowing to resolve artifacts based
on something I currently don't now how to name.

Set|Tree|Node|what? resolveArtifacts(Object|String|what?
classpath|identifier|target|main|test|app|what?);

Regards,
-- 
Christian


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

New Releases - Android Maven Plugin and Android NDK Maven Plugin

[Manfred Moser]

Hi all, 

Just a quick heads up that we cut two new releases of the Android-related Maven 
plugins. 

Android NDK Maven Plugin 1.1.2 - see 
http://www.simpligility.com/2016/07/android-ndk-maven-plugin-1-1-2-released/
Android Maven Plugin 4.4.3 - see 
http://www.simpligility.com/2016/07/android-maven-plugin-4-4-3-released/

The release announcements as well as the changelogs and web sites of the two 
project provide further detail as usual .

Enjoy

Manfred

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

[GitHub] maven issue #88: [MNG-5910] Fixed the description of the POM reference & add...

[rajivpjs]

Github user rajivpjs commented on the issue:

https://github.com/apache/maven/pull/88
  
I agree.

I have applied the following to the test class:

@Rule
private ExpectedException expectedException = ExpectedException.none();

Within the test I have added:

expectedException.expect(ModelBuildingException.class);
expectedException.expectMessage("Failed due to exists and 
missing properties are enabled for profile exists-missing-condition");
builder.build( request );

However, the expectedException is not been triggered. Whatever, I do to 
expectedException nothing seems to trigger the Exception. Do you know if I am 
missing anything?


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

[GitHub] maven issue #88: [MNG-5910] Fixed the description of the POM reference & add...

[khmarbaise]

Github user khmarbaise commented on the issue:

https://github.com/apache/maven/pull/88
  
The @Test (expected =...) approach has one drawback, cause you can't check 
the message of the exceptionWould be great...


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

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

[rajivpjs]

Github user rajivpjs commented on a diff in the pull request:

https://github.com/apache/maven/pull/88#discussion_r71407078
  
--- Diff: 
maven-model-builder/src/test/java/org/apache/maven/model/building/ComplexActivationTest.java
 ---
@@ -56,5 +56,26 @@ public void testAndConditionInActivation()
 assertEquals( "activated-1", 
result.getEffectiveModel().getProperties().get( "profile.file" ) );
 assertNull( result.getEffectiveModel().getProperties().get( 
"profile.miss" ) );
 }
+
+public void testConditionExistingAndMissingInActivation() throws 
Exception
+{
+Properties sysProperties = new Properties();
+sysProperties.setProperty( "myproperty", "test" );
+
+ModelBuilder builder = new 
DefaultModelBuilderFactory().newInstance();
+assertNotNull( builder );
+
+DefaultModelBuildingRequest request = new 
DefaultModelBuildingRequest();
+request.setProcessPlugins( true );
+request.setPomFile( getPom( "complexEmptyAndMissing" ) );
+request.setSystemProperties( sysProperties );
+
+try {
--- End diff --

oh ok!!!

I think it is a great idea. Usually, when I want to test for Exceptions I 
use annotation approach like having @Test(expected = Exception.class). However, 
looking at the existing examples of Apache I couldn't find any. So, I actually 
learnt the Rule approach is kind of equivalent. I am just applying the change.

Thanks.


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

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

[khmarbaise]

Github user khmarbaise commented on a diff in the pull request:

https://github.com/apache/maven/pull/88#discussion_r71406374
  
--- Diff: 
maven-model-builder/src/test/java/org/apache/maven/model/building/ComplexActivationTest.java
 ---
@@ -56,5 +56,26 @@ public void testAndConditionInActivation()
 assertEquals( "activated-1", 
result.getEffectiveModel().getProperties().get( "profile.file" ) );
 assertNull( result.getEffectiveModel().getProperties().get( 
"profile.miss" ) );
 }
+
+public void testConditionExistingAndMissingInActivation() throws 
Exception
+{
+Properties sysProperties = new Properties();
+sysProperties.setProperty( "myproperty", "test" );
+
+ModelBuilder builder = new 
DefaultModelBuilderFactory().newInstance();
+assertNotNull( builder );
+
+DefaultModelBuildingRequest request = new 
DefaultModelBuildingRequest();
+request.setProcessPlugins( true );
+request.setPomFile( getPom( "complexEmptyAndMissing" ) );
+request.setSystemProperties( sysProperties );
+
+try {
--- End diff --

Hi, WDYT means What Do You Think ? I wanted that you shared your 
opinion.


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

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

[rajivpjs]

Github user rajivpjs commented on a diff in the pull request:

https://github.com/apache/maven/pull/88#discussion_r71405276
  
--- Diff: 
maven-model-builder/src/test/java/org/apache/maven/model/building/ComplexActivationTest.java
 ---
@@ -56,5 +56,26 @@ public void testAndConditionInActivation()
 assertEquals( "activated-1", 
result.getEffectiveModel().getProperties().get( "profile.file" ) );
 assertNull( result.getEffectiveModel().getProperties().get( 
"profile.miss" ) );
 }
+
+public void testConditionExistingAndMissingInActivation() throws 
Exception
+{
+Properties sysProperties = new Properties();
+sysProperties.setProperty( "myproperty", "test" );
+
+ModelBuilder builder = new 
DefaultModelBuilderFactory().newInstance();
+assertNotNull( builder );
+
+DefaultModelBuildingRequest request = new 
DefaultModelBuildingRequest();
+request.setProcessPlugins( true );
+request.setPomFile( getPom( "complexEmptyAndMissing" ) );
+request.setSystemProperties( sysProperties );
+
+try {
--- End diff --

I will work on this and have this done shortly. What do you mean by WDYT?


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

[Paul Benedict]

Thanks Robert. Congratulations on the outstanding research.

Personally I am surprised that the Maven Plugin Plugin was scanning *all*
my dependencies. I have nothing to offer it. :-) My project source is where
my Mojo annotations are and not in any dependencies. So when I reported a
suspected ASM leak, I was reading the error wrong -- the mojo scanner was
scanning my version of ASM instead. I appreciate you going to create new
ticket to customize the scanning behavior. I fully agree with you that (1)
special classes like module/package-info.class should not be scanned and
(2) scanning should be configurable to be finer tuned.

Again, thanks!

Cheers,
Paul

On Tue, Jul 19, 2016 at 1:10 PM, Robert Scholte 
wrote:

> Hi,
>
> after some investigation Paul and I have good news: *none* of the classes
> is leaking into the plugin.
>
> Some details: the Annotation scanners doesn't only scan the compiled
> classes in the outputDirectory, but also in all the dependencies in search
> for other (Abstract)Mojo's.
> One of the files which the scanner found was
> asm-6.0_ALPHA.jar!/module-info.class
> maven-plugin-plugin:3.2 will throw a NullPointerException on this file,
> more recent versions throw an IllegalArgumentException.
> The plugin can't handle this Java9 file, yet.
>
> I will create some Jira issues regarding this:
> - ensure that special classes are never scanned
> - better control over the dependencies to scan, where I would prefer a
> solution where the plugin knows if additional scanning of dependencies is
> required based on the superclass(es) of the mojo's.
>
> thanks,
> Robert
>
>
> On Mon, 18 Jul 2016 22:20:41 +0200, Robert Scholte 
> wrote:
>
> 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 <
> pbened...@apache.org>
>
>> 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
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional 

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

[khmarbaise]

Github user khmarbaise commented on a diff in the pull request:

https://github.com/apache/maven/pull/88#discussion_r71401238
  
--- Diff: 
maven-model-builder/src/test/java/org/apache/maven/model/building/ComplexActivationTest.java
 ---
@@ -56,5 +56,26 @@ public void testAndConditionInActivation()
 assertEquals( "activated-1", 
result.getEffectiveModel().getProperties().get( "profile.file" ) );
 assertNull( result.getEffectiveModel().getProperties().get( 
"profile.miss" ) );
 }
+
+public void testConditionExistingAndMissingInActivation() throws 
Exception
+{
+Properties sysProperties = new Properties();
+sysProperties.setProperty( "myproperty", "test" );
+
+ModelBuilder builder = new 
DefaultModelBuilderFactory().newInstance();
+assertNotNull( builder );
+
+DefaultModelBuildingRequest request = new 
DefaultModelBuildingRequest();
+request.setProcessPlugins( true );
+request.setPomFile( getPom( "complexEmptyAndMissing" ) );
+request.setSystemProperties( sysProperties );
+
+try {
--- End diff --

As far as I know we use JUnit 4.X where you can @Rule for exceptions ?


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

[Robert Scholte]

Hi,

after some investigation Paul and I have good news: *none* of the classes  
is leaking into the plugin.


Some details: the Annotation scanners doesn't only scan the compiled  
classes in the outputDirectory, but also in all the dependencies in search  
for other (Abstract)Mojo's.
One of the files which the scanner found was  
asm-6.0_ALPHA.jar!/module-info.class
maven-plugin-plugin:3.2 will throw a NullPointerException on this file,  
more recent versions throw an IllegalArgumentException.

The plugin can't handle this Java9 file, yet.

I will create some Jira issues regarding this:
- ensure that special classes are never scanned
- better control over the dependencies to scan, where I would prefer a  
solution where the plugin knows if additional scanning of dependencies is  
required based on the superclass(es) of the mojo's.


thanks,
Robert

On Mon, 18 Jul 2016 22:20:41 +0200, Robert Scholte   
wrote:



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


-
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

[Stephen Connolly]

The code for the project formerly known as Aether is being migrated to
Maven as the Eclipse Aether project has been retired.

Ideally we do not want to expose the code known as Aether to plugins, so we
will probably expose APIs targeted for the use-cases of Maven plugins...

We were somewhat hampered until we got guidance from the Eclipse Foundation
as to some issues around the transition of the code. Most of those seem to
be being resolved, so hopefully we can get some momentum going again.

-Stephen

On 19 July 2016 at 07:36, Christofer Dutz  wrote:

> Hi Guys,
>
>
> thanks for that feedback ... I know my implementation was sort of ugly,
> but I tried to keep it as simple as possilbe as it seemed that the Eclipse
> Aether project didn't work on Aether for quite some time (Don't know if
> it's simply "finished" or if it's now maintained elsewhere). My option was
> a simple way to be able to extend this without having to change anything in
> Aether. But if there's a better, simpler, cleaner way ... I'd be more than
> happy to use that.
>
>
> I have to admit that I'm still getting used to the internals of mavens DI
> mechanisms, so please forgive a mabe stupid question:
>
> - I can see the DependencyGraphTransformer interface in Aether-API, can I
> already use this in Maven? I didn't quite understand if you said "it's
> coming" or "it's new but you can use it" ;-)
>
> - If it's already there, how can I use it? Do I only have to provide an
> implementation of that? How do I tell Maven to use it (I'd really like to
> know if there is a way to inject custom versions of default services and
> have them used instead of the "Default" versions).
>
> - If it's not there, what can I do to make it happen as soon as possible?
>
>
> And Robert, I haven't forgotten about MPLUGIN-302 ... I'm still on it ...
> but for me it is very tightly coupled with this thing here ;-)
>
>
> Chris
>
>
>
> 
> Von: Robert Scholte 
> Gesendet: Montag, 18. Juli 2016 20:39:58
> An: Maven Developers List
> Betreff: 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 

Re: Banner for deprecated plugin documentation

[Arnaud Héritier]

+1 to explicitly marke them as deprecated

On Mon, Jul 18, 2016 at 5:23 PM, Paul Benedict  wrote:

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



-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

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

[Behrooz Nobakht]

Hi Karl,

Thanks again for the argument. For me it's still a valid question of how
for example the license plugin
would apply itself on its source structure to fix/update Java header before
a release? (Of course, I
understand the principle of linearizability to fix the circular issue).

Just in case, this is what I've been trying to apply this to:
https://github.com/google/google-java-format/issues/69
The plugin should be able to apply the formatter to itself before any
commit for example.

Regards,
Behrooz


On Mon, Jul 18, 2016 at 9:59 PM, Karl Heinz Marbaise 
wrote:

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


-- 
-- Behrooz Nobakht

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

[Christofer Dutz]

Hi Guys,


thanks for that feedback ... I know my implementation was sort of ugly, but I 
tried to keep it as simple as possilbe as it seemed that the Eclipse Aether 
project didn't work on Aether for quite some time (Don't know if it's simply 
"finished" or if it's now maintained elsewhere). My option was a simple way to 
be able to extend this without having to change anything in Aether. But if 
there's a better, simpler, cleaner way ... I'd be more than happy to use that.


I have to admit that I'm still getting used to the internals of mavens DI 
mechanisms, so please forgive a mabe stupid question:

- I can see the DependencyGraphTransformer interface in Aether-API, can I 
already use this in Maven? I didn't quite understand if you said "it's coming" 
or "it's new but you can use it" ;-)

- If it's already there, how can I use it? Do I only have to provide an 
implementation of that? How do I tell Maven to use it (I'd really like to know 
if there is a way to inject custom versions of default services and have them 
used instead of the "Default" versions).

- If it's not there, what can I do to make it happen as soon as possible?


And Robert, I haven't forgotten about MPLUGIN-302 ... I'm still on it ... but 
for me it is very tightly coupled with this thing here ;-)


Chris




Von: Robert Scholte 
Gesendet: Montag, 18. Juli 2016 20:39:58
An: Maven Developers List
Betreff: 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