[jira] [Commented] (MDEPLOY-157) Add deployAtEnd option for multimodule projects

2016-01-08 Thread Alexander Kriegisch (JIRA)

[ 
https://issues.apache.org/jira/browse/MDEPLOY-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089080#comment-15089080
 ] 

Alexander Kriegisch commented on MDEPLOY-157:
-

Sorry for digging up this issue. I have this in my parent POM's 
{{pluginManagement}} section:

{code}

org.apache.maven.plugins
maven-install-plugin
2.5.2

true




org.apache.maven.plugins
maven-deploy-plugin
2.8.2

true


{code}

I see artifacts being uploaded to the repository manager per module anyway. Am 
I doing anything wrong?

> Add deployAtEnd option for multimodule projects
> ---
>
> Key: MDEPLOY-157
> URL: https://issues.apache.org/jira/browse/MDEPLOY-157
> Project: Maven Deploy Plugin
>  Issue Type: New Feature
>  Components: deploy:deploy
>Affects Versions: 2.7
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 2.8
>
>
> With this option it will be possible to only deploy artifacts if all have 
> been succesfully installed.
> See MRELEASE-664 for further details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MNG-5958) java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase

2016-01-08 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/MNG-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089159#comment-15089159
 ] 

ASF GitHub Bot commented on MNG-5958:
-

Github user michael-o commented on the pull request:


https://github.com/apache/maven-integration-testing/pull/13#issuecomment-169988105
  
Just trying to run the ITs without your patch first.


> java.lang.String cannot be cast to 
> org.apache.maven.lifecycle.mapping.LifecyclePhase
> 
>
> Key: MNG-5958
> URL: https://issues.apache.org/jira/browse/MNG-5958
> Project: Maven
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 3.3.9
> Environment: win 8.1
>Reporter: Meytal Genah
>Priority: Minor
>
> Our app uses flex mojo.
> We upgraded from Maven 3.3.3 to Maven 3.3.9 and when building we get:
> [ERROR] Internal error: java.lang.ClassCastException: java.lang.String cannot 
> be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error: 
> java.lang.ClassCastException: java.lang.String cannot be cast to 
> org.apache.maven.lifecycle.mapping.LifecyclePhas
> e
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:121)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to 
> org.apache.maven.lifecycle.mapping.LifecyclePhase
> at 
> org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:119)
> at 
> org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:64)
> at 
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:451)
> at 
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:421)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:620)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:411)
> at 
> org.apache.maven.graph.DefaultGraphBuilder.collectProjects(DefaultGraphBuilder.java:419)
> at 
> org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor(DefaultGraphBuilder.java:410)
> at 
> org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:83)
> at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:491)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> ... 11 more
> I didn’t see anyone encountering the same problem. Maybe it is related to the 
> fix of https://issues.apache.org/jira/browse/MNG-5805.
> Also, according to the stack trace, the invalid casting is in this line:
> LifecyclePhase goals = goalsForLifecyclePhase.getValue();
> this is the content of the pom.xml:
> http://maven.apache.org/POM/4.0.0";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>  http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> 
>com.myapp.plugin
>   GUI
>   trunk
> 
> myapp-war
>   1.0
> war
>  

[jira] [Commented] (ARCHETYPE-488) Goal integration-test of maven-archetype-plugin fails with 'Cannot run additions goals." in version 3.3.1

2016-01-08 Thread JIRA

[ 
https://issues.apache.org/jira/browse/ARCHETYPE-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089212#comment-15089212
 ] 

Jörg Hohwiller commented on ARCHETYPE-488:
--

> Is there a workaround for it?

Yep. Just create a copy of "mvn.cmd" that you call "mvn.bat" in MAVEN_HOME/bin.

> Goal integration-test of maven-archetype-plugin fails with 'Cannot run 
> additions goals." in version 3.3.1
> -
>
> Key: ARCHETYPE-488
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-488
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Plugin
>Affects Versions: 2.4
> Environment: maven-archetype-plugin 2.3
>Reporter: Andreas Horst
>  Labels: archetype, integration-test
>
> Running the goal 'integration-test' of the 'maven-archetype-plugin' fails 
> with the following output:
> {noformat}
> [INFO] Invoking post-archetype-generation goals: verify
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 2.048 s
> [INFO] Finished at: 2015-04-23T18:17:07+02:00
> [INFO] Final Memory: 18M/309M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-archetype-plugin:2.3:integration-test 
> (default-integration-test) on project simple-archetype:
> [ERROR] Archetype IT 'it' failed: Cannot run additions goals.
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-archetype-plugin:2.3:integration-test 
> (default-integration-test) on project simple-archetype:
> Archetype IT 'it' failed: Cannot run additions goals.
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> Archetype IT 'it' failed: Cannot run additions goals.
> at 
> org.apache.maven.archetype.mojos.IntegrationTestMojo.execute(IntegrationTestMojo.java:258)
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
> [ERROR]
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {noformat}
> This works fine in earlier versions (tested with Maven 3.2.5 and 3.2.3).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MNG-5958) java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase

2016-01-08 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/MNG-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089258#comment-15089258
 ] 

ASF GitHub Bot commented on MNG-5958:
-

Github user michael-o commented on the pull request:


https://github.com/apache/maven-integration-testing/pull/13#issuecomment-170016837
  
Seems like I can't run the tests in a locked down environment, regardless 
of a Nexus instance and am HTTP proxy. Artifact resolution always points to 
`file:target/null`


> java.lang.String cannot be cast to 
> org.apache.maven.lifecycle.mapping.LifecyclePhase
> 
>
> Key: MNG-5958
> URL: https://issues.apache.org/jira/browse/MNG-5958
> Project: Maven
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 3.3.9
> Environment: win 8.1
>Reporter: Meytal Genah
>Priority: Minor
>
> Our app uses flex mojo.
> We upgraded from Maven 3.3.3 to Maven 3.3.9 and when building we get:
> [ERROR] Internal error: java.lang.ClassCastException: java.lang.String cannot 
> be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error: 
> java.lang.ClassCastException: java.lang.String cannot be cast to 
> org.apache.maven.lifecycle.mapping.LifecyclePhas
> e
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:121)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to 
> org.apache.maven.lifecycle.mapping.LifecyclePhase
> at 
> org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:119)
> at 
> org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:64)
> at 
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:451)
> at 
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:421)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:620)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:411)
> at 
> org.apache.maven.graph.DefaultGraphBuilder.collectProjects(DefaultGraphBuilder.java:419)
> at 
> org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor(DefaultGraphBuilder.java:410)
> at 
> org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:83)
> at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:491)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> ... 11 more
> I didn’t see anyone encountering the same problem. Maybe it is related to the 
> fix of https://issues.apache.org/jira/browse/MNG-5805.
> Also, according to the stack trace, the invalid casting is in this line:
> LifecyclePhase goals = goalsForLifecyclePhase.getValue();
> this is the content of the pom.xml:
> http://maven.apache.org/POM/4.0.0";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>  http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
>

[jira] [Commented] (MNG-5958) java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase

2016-01-08 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/MNG-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089305#comment-15089305
 ] 

ASF GitHub Bot commented on MNG-5958:
-

Github user atanasenko commented on the pull request:


https://github.com/apache/maven-integration-testing/pull/13#issuecomment-170025305
  
I've had troubles running tests when following official guidelines [1].
But changing 'mvn clean test ...' to 'mvn clean install ...' helped.
[1] https://maven.apache.org/core-its/core-it-suite/


> java.lang.String cannot be cast to 
> org.apache.maven.lifecycle.mapping.LifecyclePhase
> 
>
> Key: MNG-5958
> URL: https://issues.apache.org/jira/browse/MNG-5958
> Project: Maven
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 3.3.9
> Environment: win 8.1
>Reporter: Meytal Genah
>Priority: Minor
>
> Our app uses flex mojo.
> We upgraded from Maven 3.3.3 to Maven 3.3.9 and when building we get:
> [ERROR] Internal error: java.lang.ClassCastException: java.lang.String cannot 
> be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error: 
> java.lang.ClassCastException: java.lang.String cannot be cast to 
> org.apache.maven.lifecycle.mapping.LifecyclePhas
> e
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:121)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to 
> org.apache.maven.lifecycle.mapping.LifecyclePhase
> at 
> org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:119)
> at 
> org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:64)
> at 
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:451)
> at 
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:421)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:620)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:411)
> at 
> org.apache.maven.graph.DefaultGraphBuilder.collectProjects(DefaultGraphBuilder.java:419)
> at 
> org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor(DefaultGraphBuilder.java:410)
> at 
> org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:83)
> at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:491)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> ... 11 more
> I didn’t see anyone encountering the same problem. Maybe it is related to the 
> fix of https://issues.apache.org/jira/browse/MNG-5805.
> Also, according to the stack trace, the invalid casting is in this line:
> LifecyclePhase goals = goalsForLifecyclePhase.getValue();
> this is the content of the pom.xml:
> http://maven.apache.org/POM/4.0.0";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>  http://maven.apache.org/maven

[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies

2016-01-08 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089687#comment-15089687
 ] 

Hudson commented on MCOMPILER-203:
--

FAILURE: Integrated in maven-plugins #4994 (See 
[https://builds.apache.org/job/maven-plugins/4994/])
[MCOMPILER-203] Allow specifying annotation processor path dependencies 
(agudian: [http://svn.apache.org/viewvc/?view=rev&rev=1723779])
* maven-compiler-plugin/pom.xml
* maven-compiler-plugin/src/it/MCOMPILER-203-processorpath
* maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/pom.xml
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/src
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/src/main
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/src/main/java
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/src/main/java/org
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/src/main/java/org/issue
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/src/main/java/org/issue/SimpleAnnotationProcessor.java
* maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/pom.xml
* maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/main
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/main/java
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/main/java/org
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/main/java/org/issue
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/main/java/org/issue/SimpleAnnotation.java
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/main/java/org/issue/SimpleObject.java
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/test
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/test/java
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/test/java/org
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/test/java/org/issue
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/test/java/org/issue/SimpleTestObject.java
* maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/pom.xml
* maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/src
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/src/main
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/src/main/java
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/src/main/java/org
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/src/main/java/org/issue
* 
maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/src/main/java/org/issue/SourcePathReadGoal.java
* maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/invoker.properties
* maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/pom.xml
* 
maven-compiler-plugin/src/it/jdk16-annotation/src/main/resources/META-INF/services/javax.annotation.processing.Processor
* 
maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
* 
maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/DependencyCoordinate.java


> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
>
> Right now the status quo for annotation processor artifacts requires one of 
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and 
> ill-supported, and inflexible/hard to use.  The latter is suboptimal because 
> it is often the case that you do not want to leak annotation processor 
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the 
> compiler plugin configuration such tha

[jira] [Updated] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies

2016-01-08 Thread Andreas Gudian (JIRA)

 [ 
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Gudian updated MCOMPILER-203:
-
Fix Version/s: 3.5

> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of 
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and 
> ill-supported, and inflexible/hard to use.  The latter is suboptimal because 
> it is often the case that you do not want to leak annotation processor 
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the 
> compiler plugin configuration such that they are recognized by the annotation 
> processing search algorithm of the compiler, but they do not actually appear 
> on the compilation class path.  Ideally they would also be isolated from one 
> another (dependency graphs and all), but that's more of a "nice to have".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MCOMPILER-204) Add a switch to disable unwanted annotation processors

2016-01-08 Thread Andreas Gudian (JIRA)

 [ 
https://issues.apache.org/jira/browse/MCOMPILER-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Gudian closed MCOMPILER-204.

Resolution: Not A Problem

A little late, but I'm closing this issue now as there are some ways of doing 
this.
For example, just use the {{}} config option to specify which 
processors are to be used. And/or use the new parameter to define the 
processor-path that is handed over to the compiler (see MCOMPILER-203 - will be 
available with maven-compiler-plugin version 3.5).

> Add a switch to disable unwanted annotation processors
> --
>
> Key: MCOMPILER-204
> URL: https://issues.apache.org/jira/browse/MCOMPILER-204
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Affects Versions: 2.3.2
> Environment: Java 6+
>Reporter: David M. Lloyd
>
> Right now you can turn annotation processing on and off globally.  However, 
> you cannot turn on annotation processing such that only processor artifacts 
> are considered for processing.  This in particular makes it very hard to 
> build artifacts which include an annotation processor but also *use* 
> annotation processors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies

2016-01-08 Thread David M. Lloyd (JIRA)

[ 
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089964#comment-15089964
 ] 

David M. Lloyd commented on MCOMPILER-203:
--

Does the proposed solution isolate the processor paths from each other?

> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of 
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and 
> ill-supported, and inflexible/hard to use.  The latter is suboptimal because 
> it is often the case that you do not want to leak annotation processor 
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the 
> compiler plugin configuration such that they are recognized by the annotation 
> processing search algorithm of the compiler, but they do not actually appear 
> on the compilation class path.  Ideally they would also be isolated from one 
> another (dependency graphs and all), but that's more of a "nice to have".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies

2016-01-08 Thread David M. Lloyd (JIRA)

[ 
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089965#comment-15089965
 ] 

David M. Lloyd commented on MCOMPILER-203:
--

Also, is there a way to override or exclude transitive dependencies of the 
processor path entries?

> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of 
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and 
> ill-supported, and inflexible/hard to use.  The latter is suboptimal because 
> it is often the case that you do not want to leak annotation processor 
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the 
> compiler plugin configuration such that they are recognized by the annotation 
> processing search algorithm of the compiler, but they do not actually appear 
> on the compilation class path.  Ideally they would also be isolated from one 
> another (dependency graphs and all), but that's more of a "nice to have".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (SUREFIRE-964) TEST-*.xml files generated by Surefire throw validation warnings in Eclipse for no grammer constraints (DTD or XML schema) referenced in the document

2016-01-08 Thread Mirko Friedenhagen (JIRA)

[ 
https://issues.apache.org/jira/browse/SUREFIRE-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089976#comment-15089976
 ] 

Mirko Friedenhagen commented on SUREFIRE-964:
-

Hello [~tibor17], I think the XSD is not correct, see 
https://issues.jenkins-ci.org/browse/JENKINS-31553 as well.
When I open:
{code}

http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report.xsd";
 errors="0" failures="0" name="User sessions"
   tests="12"
   time="66.864949">





{code}
in IntelliJ I get an error because the namespacing is not correct. Xerces 
complains with:
{code}
schemaLocation value = 
'https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report.xsd'
 must have even number of URI's.
{code}

In the definition for the Maven POM the line in the XSD reads like this:
{code}
http://www.w3.org/2001/XMLSchema"; 
elementFormDefault="qualified" 
targetNamespace="http://maven.apache.org/POM/4.0.0"; 
xmlns="http://maven.apache.org/POM/4.0.0";>
{code}

so probably the surefire XSD should start with:
{code}
http://www.w3.org/2001/XMLSchema"; 
elementFormDefault="qualified" 
targetNamespace="https://maven.apache.org/surefire/surefire-test-report"; 
xmlns="https://maven.apache.org/surefire/surefire-test-report";>
{code}

and the surefire TEST xml files should start with:
{code}
https://maven.apache.org/surefire/surefire-test-report"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="https://maven.apache.org/surefire/surefire-test-report 
https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report.xsd";
{code}

> TEST-*.xml files generated by Surefire throw validation warnings in Eclipse 
> for no grammer constraints (DTD or XML schema) referenced in the document
> -
>
> Key: SUREFIRE-964
> URL: https://issues.apache.org/jira/browse/SUREFIRE-964
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Report Plugin
>Affects Versions: 2.13
> Environment: Any OS, Eclipse Juno with m2e and m2e-wtp.
>Reporter: Josh Unger
>Assignee: Tibor Digana
>Priority: Trivial
> Fix For: 2.19
>
>
> 1. Create a Maven project in Eclipse.
> 2. Add a single class and a single test method decorated with @Test.
> {code}
> import org.junit.Test;
> public class ATest
> {
>   @Test
>   public void test()
>   {
>   
>   }
> }
> {code}
> 3. Add the necessary information to the POM -
> {code}
> 
> 
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.13
> 
> 
> 
> 
> 
> junit
> junit
> 4.7
> test
> 
> 
> {code}
> 4. Close Eclipse.
> 5. Edit your .project file to include the validator -
> {code}
> 
> org.eclipse.wst.validation.validationbuilder
> 
> 
> {code}
> 6. Build from the command line -
> > mvn install
> 7. Open Eclipse.
> EXPECTING: no warnings appear out of the box.  I understand workarounds, but 
> for the benefit of anyone going forward and existing users, there should be 
> no warnings.
> ACTUAL: warning appears -
> Description   ResourcePathLocationType
> No grammar constraints (DTD or XML Schema) referenced in the document.
> TEST-ATest.xml  /test/target/surefire-reports   line 1  XML Problem



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies

2016-01-08 Thread Andreas Gudian (JIRA)

[ 
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089988#comment-15089988
 ] 

Andreas Gudian commented on MCOMPILER-203:
--

>From the new documentation:

{quote}
Classpath elements to supply as annotation processor path. If specified, the 
compiler will detect annotation processors only in those classpath elements. If 
omitted, the default classpath is used to detect annotation processors. The 
detection itself depends on the configuration of annotationProcessors.

Each classpath element is specified using their Maven coordinates (groupId, 
artifactId, version, classifier, type). Transitive dependencies are added 
automatically. Example:

{code}

  

  org.sample
  sample-annotation-processor
  1.2.3


  

{code}
{quote}

Transitive dependencies are resolved. Exclusions can't be defined, and just as 
with plugin-dependencies, the {{dependencyManagement}} section does NOT have 
any influence on these processor classpath elements.

As to your question with the isolation: it's not possible to hand over 
different sets of processor classpaths to javac - there is only one 
{{-processorpath}} option there.
If you have multiple processors that have conflicting dependencies, then please 
take that up with the providers of those processors. Both Javac and the Eclipse 
JDT compiler implementation only support that one processor path and developers 
of such processors should be aware of that. That's actually a good use case for 
the maven-shade-plugin, where dependencies are mapped to private packages and 
inlined into the jar (the so-called fat-jar). That's how it's done for example 
in the [MapStruct 
processor|https://github.com/mapstruct/mapstruct/blob/master/processor/pom.xml].

> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of 
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and 
> ill-supported, and inflexible/hard to use.  The latter is suboptimal because 
> it is often the case that you do not want to leak annotation processor 
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the 
> compiler plugin configuration such that they are recognized by the annotation 
> processing search algorithm of the compiler, but they do not actually appear 
> on the compilation class path.  Ideally they would also be isolated from one 
> another (dependency graphs and all), but that's more of a "nice to have".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (SUREFIRE-964) TEST-*.xml files generated by Surefire throw validation warnings in Eclipse for no grammer constraints (DTD or XML schema) referenced in the document

2016-01-08 Thread Mirko Friedenhagen (JIRA)

[ 
https://issues.apache.org/jira/browse/SUREFIRE-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089992#comment-15089992
 ] 

Mirko Friedenhagen commented on SUREFIRE-964:
-

Another solution would be if the generated XML looks like this:
{code}

http://www.w3.org/2001/XMLSchema-instance"; 
xsi:noNamespaceSchemaLocation="https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report.xsd";
 errors="0" failures="0" skipped="0" name="User sessions"
   tests="12"
   time="66.864">





{code}

The attribute {{skipped}} is mandatory and the time attributes must not be more 
precise than milliseconds, i.e. 3 digits after the decimal separator.

> TEST-*.xml files generated by Surefire throw validation warnings in Eclipse 
> for no grammer constraints (DTD or XML schema) referenced in the document
> -
>
> Key: SUREFIRE-964
> URL: https://issues.apache.org/jira/browse/SUREFIRE-964
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Report Plugin
>Affects Versions: 2.13
> Environment: Any OS, Eclipse Juno with m2e and m2e-wtp.
>Reporter: Josh Unger
>Assignee: Tibor Digana
>Priority: Trivial
> Fix For: 2.19
>
>
> 1. Create a Maven project in Eclipse.
> 2. Add a single class and a single test method decorated with @Test.
> {code}
> import org.junit.Test;
> public class ATest
> {
>   @Test
>   public void test()
>   {
>   
>   }
> }
> {code}
> 3. Add the necessary information to the POM -
> {code}
> 
> 
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.13
> 
> 
> 
> 
> 
> junit
> junit
> 4.7
> test
> 
> 
> {code}
> 4. Close Eclipse.
> 5. Edit your .project file to include the validator -
> {code}
> 
> org.eclipse.wst.validation.validationbuilder
> 
> 
> {code}
> 6. Build from the command line -
> > mvn install
> 7. Open Eclipse.
> EXPECTING: no warnings appear out of the box.  I understand workarounds, but 
> for the benefit of anyone going forward and existing users, there should be 
> no warnings.
> ACTUAL: warning appears -
> Description   ResourcePathLocationType
> No grammar constraints (DTD or XML Schema) referenced in the document.
> TEST-ATest.xml  /test/target/surefire-reports   line 1  XML Problem



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (SUREFIRE-1216) TEST-*.xml files generated by Surefire is invalid

2016-01-08 Thread Mirko Friedenhagen (JIRA)
Mirko Friedenhagen created SUREFIRE-1216:


 Summary: TEST-*.xml files generated by Surefire is invalid
 Key: SUREFIRE-1216
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1216
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.19.1
Reporter: Mirko Friedenhagen


See SUREFIRE-964 as well. The XML produced is invalid because 
{{schemaLocation}} *must* include two URIs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies

2016-01-08 Thread David M. Lloyd (JIRA)

[ 
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1509#comment-1509
 ] 

David M. Lloyd commented on MCOMPILER-203:
--

The idea is to not use javac anymore, or at most, do not support processor 
specification for javac, which I believe is consistent with the current design 
climate (in fact I'm not even sure that the latest version supports using javac 
anymore, does it?).  Instead the javax.tools API should be used, as it is not 
only far more flexible but also solves a number of other unrelated bugs 
relating to output parsing, error reporting, etc.

Using this API, it is trivial to specify isolated processors.

> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of 
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and 
> ill-supported, and inflexible/hard to use.  The latter is suboptimal because 
> it is often the case that you do not want to leak annotation processor 
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the 
> compiler plugin configuration such that they are recognized by the annotation 
> processing search algorithm of the compiler, but they do not actually appear 
> on the compilation class path.  Ideally they would also be isolated from one 
> another (dependency graphs and all), but that's more of a "nice to have".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MDEPLOY-204) Must deploy maven-metadata.xml last

2016-01-08 Thread Dan Tran (JIRA)
Dan Tran created MDEPLOY-204:


 Summary: Must deploy maven-metadata.xml last
 Key: MDEPLOY-204
 URL: https://issues.apache.org/jira/browse/MDEPLOY-204
 Project: Maven Deploy Plugin
  Issue Type: Bug
  Components: deploy:deploy
Affects Versions: 2.8.2
Reporter: Dan Tran


detail discussion at 
http://maven.40175.n5.nabble.com/maven-metadata-xml-should-be-deployed-last-tt5858382.html





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies

2016-01-08 Thread Andreas Gudian (JIRA)

[ 
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090022#comment-15090022
 ] 

Andreas Gudian commented on MCOMPILER-203:
--

The javac executable and what's behind javax.tools is very much the same in 
terms of options.

For example, I'm not aware of a way to specify isolated processors or paths 
with that API. You'd have to invoke multiple rounds with proc:only followed 
with proc:none with either. the API or the javac process to do something like 
that. Is that what you mean?

> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of 
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and 
> ill-supported, and inflexible/hard to use.  The latter is suboptimal because 
> it is often the case that you do not want to leak annotation processor 
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the 
> compiler plugin configuration such that they are recognized by the annotation 
> processing search algorithm of the compiler, but they do not actually appear 
> on the compilation class path.  Ideally they would also be isolated from one 
> another (dependency graphs and all), but that's more of a "nice to have".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies

2016-01-08 Thread Andreas Gudian (JIRA)

[ 
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090024#comment-15090024
 ] 

Andreas Gudian commented on MCOMPILER-203:
--

Oh and you still can use the external javac in the current version, which is 
important for example for toolchain-support. So I'd favour to support the 
configuration options for both variants, the (faster) API and the 
bulletproof/toolchain-supporting forked javac.

> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of 
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and 
> ill-supported, and inflexible/hard to use.  The latter is suboptimal because 
> it is often the case that you do not want to leak annotation processor 
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the 
> compiler plugin configuration such that they are recognized by the annotation 
> processing search algorithm of the compiler, but they do not actually appear 
> on the compilation class path.  Ideally they would also be isolated from one 
> another (dependency graphs and all), but that's more of a "nice to have".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (SUREFIRE-964) TEST-*.xml files generated by Surefire throw validation warnings in Eclipse for no grammer constraints (DTD or XML schema) referenced in the document

2016-01-08 Thread Tibor Digana (JIRA)

[ 
https://issues.apache.org/jira/browse/SUREFIRE-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090032#comment-15090032
 ] 

Tibor Digana commented on SUREFIRE-964:
---

[~mfriedenhagen]
We have a chance to fix issues after 2.19 since we are preparing Surefire 
project for version 3.0 in git branch 3.0-RC1.
Meanwhile we can fix this issue as well but I would not do it immediately 
because it's just few days after 2.19.1 and the users have not noticed Version 
2.19.1.

The physical locations are two, so we should check the implementation and wait 
one week for another issue.
https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report.xsd
https://maven.apache.org/surefire/maven-failsafe-plugin/xsd/surefire-test-report.xsd

How much urgent issue it is for Jenkins plugin?

> TEST-*.xml files generated by Surefire throw validation warnings in Eclipse 
> for no grammer constraints (DTD or XML schema) referenced in the document
> -
>
> Key: SUREFIRE-964
> URL: https://issues.apache.org/jira/browse/SUREFIRE-964
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Report Plugin
>Affects Versions: 2.13
> Environment: Any OS, Eclipse Juno with m2e and m2e-wtp.
>Reporter: Josh Unger
>Assignee: Tibor Digana
>Priority: Trivial
> Fix For: 2.19
>
>
> 1. Create a Maven project in Eclipse.
> 2. Add a single class and a single test method decorated with @Test.
> {code}
> import org.junit.Test;
> public class ATest
> {
>   @Test
>   public void test()
>   {
>   
>   }
> }
> {code}
> 3. Add the necessary information to the POM -
> {code}
> 
> 
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.13
> 
> 
> 
> 
> 
> junit
> junit
> 4.7
> test
> 
> 
> {code}
> 4. Close Eclipse.
> 5. Edit your .project file to include the validator -
> {code}
> 
> org.eclipse.wst.validation.validationbuilder
> 
> 
> {code}
> 6. Build from the command line -
> > mvn install
> 7. Open Eclipse.
> EXPECTING: no warnings appear out of the box.  I understand workarounds, but 
> for the benefit of anyone going forward and existing users, there should be 
> no warnings.
> ACTUAL: warning appears -
> Description   ResourcePathLocationType
> No grammar constraints (DTD or XML Schema) referenced in the document.
> TEST-ATest.xml  /test/target/surefire-reports   line 1  XML Problem



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (SUREFIRE-1216) TEST-*.xml files generated by Surefire is invalid

2016-01-08 Thread Tibor Digana (JIRA)

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana reassigned SUREFIRE-1216:
--

Assignee: Tibor Digana

> TEST-*.xml files generated by Surefire is invalid
> -
>
> Key: SUREFIRE-1216
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1216
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Mirko Friedenhagen
>Assignee: Tibor Digana
>
> See SUREFIRE-964 as well. The XML produced is invalid because 
> {{schemaLocation}} *must* include two URIs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (SUREFIRE-1216) TEST-*.xml files generated by Surefire is invalid

2016-01-08 Thread Tibor Digana (JIRA)

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana updated SUREFIRE-1216:
---
Fix Version/s: 2.19.2

> TEST-*.xml files generated by Surefire is invalid
> -
>
> Key: SUREFIRE-1216
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1216
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Mirko Friedenhagen
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> See SUREFIRE-964 as well. The XML produced is invalid because 
> {{schemaLocation}} *must* include two URIs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MJAVADOC-368) Can not use a comma (,) in option additionalparam

2016-01-08 Thread Christopher Tubbs (JIRA)

[ 
https://issues.apache.org/jira/browse/MJAVADOC-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090050#comment-15090050
 ] 

Christopher Tubbs commented on MJAVADOC-368:


Have you found a workaround? I can't seem to find any syntax for the 
maven-javadoc-plugin to do this.

> Can not use a comma (,) in option additionalparam
> -
>
> Key: MJAVADOC-368
> URL: https://issues.apache.org/jira/browse/MJAVADOC-368
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Andy Schönemann
>
> I would like to set an additional parameter for javadoc like
> {{-header 'A,B'}}
> But this is not possible! Every comma here separates the string into 
> different parameters. So I'm not able to set parameters including commas.
> Furthermore, the options name is {{additionalparam}} and NOT 
> {{additionalparamS}}. So it should not be possible to set multiple parameters 
> here.
> I also tried 
> {{-header 'A,B'}}
> but this doesn't work either.
> [Plugin 
> documentation|http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalparam]
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MJAVADOC-387) Handle JDK8 -Xdoclint

2016-01-08 Thread Christopher Tubbs (JIRA)

[ 
https://issues.apache.org/jira/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090051#comment-15090051
 ] 

Christopher Tubbs commented on MJAVADOC-387:


That doesn't work when you want to do something like 
{{-Xdoclint:all,-missing}}. In fact, I can't find any syntax which will make 
that happen.

> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://issues.apache.org/jira/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>Reporter: scolebourne2
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates 
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default 
> settings, it rejects many HTML elements that are perfectly acceptable to 
> browsers, and all invalid Javadoc references (@links). This is likely to 
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can 
> control the doclint tool (currently this requires using additionalparam 
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in, 
> not opt-out (ie. fix Oracle's messed up default). This will also make it much 
> easier for developers to handle migration to JDK 8.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies

2016-01-08 Thread David M. Lloyd (JIRA)

[ 
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090068#comment-15090068
 ] 

David M. Lloyd commented on MCOMPILER-203:
--

All you have to do with the API is call 
javax.tools.JavaCompiler.CompilationTask#setProcessors().  Each processor can 
be instantiated from an isolated class loader according to any rules or 
strategy that you like.  To specify isolated options, you can simply wrap each 
Processor with one that provides the specific arguments that were configured to 
the delegate processor on init().

I'm not aware of a use case that external javac solves which cannot be solved 
with the javax.tools API, given how old that API is now.

> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of 
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and 
> ill-supported, and inflexible/hard to use.  The latter is suboptimal because 
> it is often the case that you do not want to leak annotation processor 
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the 
> compiler plugin configuration such that they are recognized by the annotation 
> processing search algorithm of the compiler, but they do not actually appear 
> on the compilation class path.  Ideally they would also be isolated from one 
> another (dependency graphs and all), but that's more of a "nice to have".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (SUREFIRE-964) TEST-*.xml files generated by Surefire throw validation warnings in Eclipse for no grammer constraints (DTD or XML schema) referenced in the document

2016-01-08 Thread Tibor Digana (JIRA)

[ 
https://issues.apache.org/jira/browse/SUREFIRE-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090104#comment-15090104
 ] 

Tibor Digana commented on SUREFIRE-964:
---

no workarounds. This would be another issue.

> TEST-*.xml files generated by Surefire throw validation warnings in Eclipse 
> for no grammer constraints (DTD or XML schema) referenced in the document
> -
>
> Key: SUREFIRE-964
> URL: https://issues.apache.org/jira/browse/SUREFIRE-964
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Report Plugin
>Affects Versions: 2.13
> Environment: Any OS, Eclipse Juno with m2e and m2e-wtp.
>Reporter: Josh Unger
>Assignee: Tibor Digana
>Priority: Trivial
> Fix For: 2.19
>
>
> 1. Create a Maven project in Eclipse.
> 2. Add a single class and a single test method decorated with @Test.
> {code}
> import org.junit.Test;
> public class ATest
> {
>   @Test
>   public void test()
>   {
>   
>   }
> }
> {code}
> 3. Add the necessary information to the POM -
> {code}
> 
> 
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.13
> 
> 
> 
> 
> 
> junit
> junit
> 4.7
> test
> 
> 
> {code}
> 4. Close Eclipse.
> 5. Edit your .project file to include the validator -
> {code}
> 
> org.eclipse.wst.validation.validationbuilder
> 
> 
> {code}
> 6. Build from the command line -
> > mvn install
> 7. Open Eclipse.
> EXPECTING: no warnings appear out of the box.  I understand workarounds, but 
> for the benefit of anyone going forward and existing users, there should be 
> no warnings.
> ACTUAL: warning appears -
> Description   ResourcePathLocationType
> No grammar constraints (DTD or XML Schema) referenced in the document.
> TEST-ATest.xml  /test/target/surefire-reports   line 1  XML Problem



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MJAVADOC-368) Can not use a comma (,) in option additionalparam

2016-01-08 Thread Michael Osipov (JIRA)

[ 
https://issues.apache.org/jira/browse/MJAVADOC-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090136#comment-15090136
 ] 

Michael Osipov commented on MJAVADOC-368:
-

Obviously you did not read my Protokoll, did you?

> Can not use a comma (,) in option additionalparam
> -
>
> Key: MJAVADOC-368
> URL: https://issues.apache.org/jira/browse/MJAVADOC-368
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Andy Schönemann
>
> I would like to set an additional parameter for javadoc like
> {{-header 'A,B'}}
> But this is not possible! Every comma here separates the string into 
> different parameters. So I'm not able to set parameters including commas.
> Furthermore, the options name is {{additionalparam}} and NOT 
> {{additionalparamS}}. So it should not be possible to set multiple parameters 
> here.
> I also tried 
> {{-header 'A,B'}}
> but this doesn't work either.
> [Plugin 
> documentation|http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalparam]
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies

2016-01-08 Thread Andreas Gudian (JIRA)

[ 
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090143#comment-15090143
 ] 

Andreas Gudian commented on MCOMPILER-203:
--

Ah, ok, right. I guess that could work for the javax.tools case.

Regarding the external javac, the use case is for whenever you need to compile 
/ test your code with a different compiler than the JDK used to execute Maven - 
e.g. for building code for a JDK version older than the runtime-requirements of 
the maven version or of some plugins, a JDK of a different vendor, or for 
running integration tests of annotation-processors against multiple different 
JDKs within one build... ;)
So it's still an important capability to have and to keep.

Anyway, I think we're getting a little off-topic and that separation idea 
should be discussed in MCOMPILER-207 after all - I don't see it within the 
scope of this issue.

> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of 
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and 
> ill-supported, and inflexible/hard to use.  The latter is suboptimal because 
> it is often the case that you do not want to leak annotation processor 
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the 
> compiler plugin configuration such that they are recognized by the annotation 
> processing search algorithm of the compiler, but they do not actually appear 
> on the compilation class path.  Ideally they would also be isolated from one 
> another (dependency graphs and all), but that's more of a "nice to have".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MJAVADOC-368) Can not use a comma (,) in option additionalparam

2016-01-08 Thread Kannan Goundan (JIRA)

[ 
https://issues.apache.org/jira/browse/MJAVADOC-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090162#comment-15090162
 ] 

Kannan Goundan commented on MJAVADOC-368:
-

An imperfect workaround: 
https://github.com/dropbox/dropbox-sdk-java/blob/886b128e15ead87ae43877d3172cbe46ba26ff1b/pom.xml#L319

> Can not use a comma (,) in option additionalparam
> -
>
> Key: MJAVADOC-368
> URL: https://issues.apache.org/jira/browse/MJAVADOC-368
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Andy Schönemann
>
> I would like to set an additional parameter for javadoc like
> {{-header 'A,B'}}
> But this is not possible! Every comma here separates the string into 
> different parameters. So I'm not able to set parameters including commas.
> Furthermore, the options name is {{additionalparam}} and NOT 
> {{additionalparamS}}. So it should not be possible to set multiple parameters 
> here.
> I also tried 
> {{-header 'A,B'}}
> but this doesn't work either.
> [Plugin 
> documentation|http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalparam]
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MJAVADOC-387) Handle JDK8 -Xdoclint

2016-01-08 Thread Christopher Tubbs (JIRA)

[ 
https://issues.apache.org/jira/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090164#comment-15090164
 ] 

Christopher Tubbs commented on MJAVADOC-387:


Correction: It looks like 
{{-Xdoclint:all,-Xdoclint:-missing}} *might* 
work.

> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://issues.apache.org/jira/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>Reporter: scolebourne2
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates 
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default 
> settings, it rejects many HTML elements that are perfectly acceptable to 
> browsers, and all invalid Javadoc references (@links). This is likely to 
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can 
> control the doclint tool (currently this requires using additionalparam 
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in, 
> not opt-out (ie. fix Oracle's messed up default). This will also make it much 
> easier for developers to handle migration to JDK 8.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MJAVADOC-368) Can not use a comma (,) in option additionalparam

2016-01-08 Thread Christopher Tubbs (JIRA)

[ 
https://issues.apache.org/jira/browse/MJAVADOC-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090350#comment-15090350
 ] 

Christopher Tubbs commented on MJAVADOC-368:


It appears that 
{{-Xdoclint:all,-Xdoclint:-missing}} 
works... so far as I can tell, but I'm not sure if it's going to be stable 
across different JDKs (8+) and maven plugin versions.

> Can not use a comma (,) in option additionalparam
> -
>
> Key: MJAVADOC-368
> URL: https://issues.apache.org/jira/browse/MJAVADOC-368
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Andy Schönemann
>
> I would like to set an additional parameter for javadoc like
> {{-header 'A,B'}}
> But this is not possible! Every comma here separates the string into 
> different parameters. So I'm not able to set parameters including commas.
> Furthermore, the options name is {{additionalparam}} and NOT 
> {{additionalparamS}}. So it should not be possible to set multiple parameters 
> here.
> I also tried 
> {{-header 'A,B'}}
> but this doesn't work either.
> [Plugin 
> documentation|http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalparam]
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)