[jira] [Updated] (ARCHETYPE-478) cannot run archetype:create-from-project when dependency on maven-ear-plugin
[ https://issues.apache.org/jira/browse/ARCHETYPE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pop Qvarnström updated ARCHETYPE-478: - Attachment: Debug screenshot showing call stack.png cannot run archetype:create-from-project when dependency on maven-ear-plugin Key: ARCHETYPE-478 URL: https://issues.apache.org/jira/browse/ARCHETYPE-478 Project: Maven Archetype Issue Type: Bug Affects Versions: 2.3 Environment: Windows 7, Maven 3.2.5 and 3.0.5, JDK 7.0.75 Reporter: Bernard LUPIN Attachments: Debug screenshot showing call stack.png, myproj.zip I'm migrating maven-archetype-plugin from 2.2 to 2.3. I cannot create an archetype if my project has a dependency on maven-ear-plugin. Using attached pom.xml and running mvn archetype:create-from-project gives me following error : [ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project (default-cli) on project myproj: null: MojoFailureException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project (default-cli) on project myproj: null at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) 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:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoFailureException at org.apache.maven.archetype.mojos.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:258) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) I tried several versions of maven-ear-plugin, adding configuration or not, I always get this obscure error. Everything works well with previous archetype plugin version 2.2. And everything works well with archetype plugin version 2.3 without maven-ear-plugin. Regards, Bernard -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARCHETYPE-478) cannot run archetype:create-from-project when dependency on maven-ear-plugin
[ https://issues.apache.org/jira/browse/ARCHETYPE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pop Qvarnström updated ARCHETYPE-478: - Attachment: Debug screenshot showing more call stack.png cannot run archetype:create-from-project when dependency on maven-ear-plugin Key: ARCHETYPE-478 URL: https://issues.apache.org/jira/browse/ARCHETYPE-478 Project: Maven Archetype Issue Type: Bug Affects Versions: 2.3 Environment: Windows 7, Maven 3.2.5 and 3.0.5, JDK 7.0.75 Reporter: Bernard LUPIN Attachments: Debug screenshot showing call stack.png, Debug screenshot showing more call stack.png, myproj.zip I'm migrating maven-archetype-plugin from 2.2 to 2.3. I cannot create an archetype if my project has a dependency on maven-ear-plugin. Using attached pom.xml and running mvn archetype:create-from-project gives me following error : [ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project (default-cli) on project myproj: null: MojoFailureException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project (default-cli) on project myproj: null at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) 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:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoFailureException at org.apache.maven.archetype.mojos.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:258) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) I tried several versions of maven-ear-plugin, adding configuration or not, I always get this obscure error. Everything works well with previous archetype plugin version 2.2. And everything works well with archetype plugin version 2.3 without maven-ear-plugin. Regards, Bernard -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ARCHETYPE-478) cannot run archetype:create-from-project when dependency on maven-ear-plugin
[
https://issues.apache.org/jira/browse/ARCHETYPE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578667#comment-14578667
]
Pop Qvarnström edited comment on ARCHETYPE-478 at 6/9/15 10:20 AM:
---
FilesetArchetypeCreator:rewriteEARPluginReferences(...) seems to be the place
where it blows up, while rewriting pluginManagement items. Ear plugin
references are treated specially, and a configuration seems to be expected. If
there is none (not uncommon in plugin management), there will be an NPE.
{code:title=FilesetArchetypeCreator.java:686-}
private void rewriteEARPluginReferences( Plugin plugin, String
rootArtifactId, String groupId )
{
Xpp3Dom configuration = (Xpp3Dom) plugin.getConfiguration();
HERE --Xpp3Dom[] modules = configuration.getChild( modules ).getChildren();
for ( int i = 0; i modules.length; i++ )
{code}
!Debug screenshot showing call stack.png!
!Debug screenshot showing more call stack.png!
was (Author: popq):
FilesetArchetypeCreator:rewriteEARPluginReferences(...) seems to be the place
where it blows up, while rewriting pluginManagement items. Ear plugin
references are treated specially, and a configuration seems to be expected. If
there is none (not uncommon in plugin management), there will be an NPE.
{code:title=FilesetArchetypeCreator.java:686-}
private void rewriteEARPluginReferences( Plugin plugin, String
rootArtifactId, String groupId )
{
Xpp3Dom configuration = (Xpp3Dom) plugin.getConfiguration();
HERE --Xpp3Dom[] modules = configuration.getChild( modules ).getChildren();
for ( int i = 0; i modules.length; i++ )
{code}
!Debug screenshot showing call stack.png|thumbnail!
!Debug screenshot showing more call stack.png|thumbnail!
cannot run archetype:create-from-project when dependency on maven-ear-plugin
Key: ARCHETYPE-478
URL: https://issues.apache.org/jira/browse/ARCHETYPE-478
Project: Maven Archetype
Issue Type: Bug
Affects Versions: 2.3
Environment: Windows 7, Maven 3.2.5 and 3.0.5, JDK 7.0.75
Reporter: Bernard LUPIN
Attachments: Debug screenshot showing call stack.png, Debug
screenshot showing more call stack.png, myproj.zip
I'm migrating maven-archetype-plugin from 2.2 to 2.3.
I cannot create an archetype if my project has a dependency on
maven-ear-plugin.
Using attached pom.xml and running mvn archetype:create-from-project gives me
following error :
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project
(default-cli) on project myproj: null: MojoFailureException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project
(default-cli) on project myproj: null
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
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:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoFailureException
at
[jira] [Comment Edited] (ARCHETYPE-478) cannot run archetype:create-from-project when dependency on maven-ear-plugin
[
https://issues.apache.org/jira/browse/ARCHETYPE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578667#comment-14578667
]
Pop Qvarnström edited comment on ARCHETYPE-478 at 6/9/15 10:21 AM:
---
FilesetArchetypeCreator:rewriteEARPluginReferences(...) seems to be the place
where it blows up, while rewriting pluginManagement items. Ear plugin
references are treated specially, and a configuration seems to be expected. If
there is none (not uncommon in plugin management), there will be an NPE.
{code:title=FilesetArchetypeCreator.java:686-}
private void rewriteEARPluginReferences( Plugin plugin, String
rootArtifactId, String groupId )
{
Xpp3Dom configuration = (Xpp3Dom) plugin.getConfiguration();
HERE --Xpp3Dom[] modules = configuration.getChild( modules ).getChildren();
for ( int i = 0; i modules.length; i++ )
{code}
Where it blows up:
!Debug screenshot showing call stack.png!
Source of the call:
!Debug screenshot showing more call stack.png!
was (Author: popq):
FilesetArchetypeCreator:rewriteEARPluginReferences(...) seems to be the place
where it blows up, while rewriting pluginManagement items. Ear plugin
references are treated specially, and a configuration seems to be expected. If
there is none (not uncommon in plugin management), there will be an NPE.
{code:title=FilesetArchetypeCreator.java:686-}
private void rewriteEARPluginReferences( Plugin plugin, String
rootArtifactId, String groupId )
{
Xpp3Dom configuration = (Xpp3Dom) plugin.getConfiguration();
HERE --Xpp3Dom[] modules = configuration.getChild( modules ).getChildren();
for ( int i = 0; i modules.length; i++ )
{code}
!Debug screenshot showing call stack.png!
!Debug screenshot showing more call stack.png!
cannot run archetype:create-from-project when dependency on maven-ear-plugin
Key: ARCHETYPE-478
URL: https://issues.apache.org/jira/browse/ARCHETYPE-478
Project: Maven Archetype
Issue Type: Bug
Affects Versions: 2.3
Environment: Windows 7, Maven 3.2.5 and 3.0.5, JDK 7.0.75
Reporter: Bernard LUPIN
Attachments: Debug screenshot showing call stack.png, Debug
screenshot showing more call stack.png, myproj.zip
I'm migrating maven-archetype-plugin from 2.2 to 2.3.
I cannot create an archetype if my project has a dependency on
maven-ear-plugin.
Using attached pom.xml and running mvn archetype:create-from-project gives me
following error :
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project
(default-cli) on project myproj: null: MojoFailureException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project
(default-cli) on project myproj: null
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
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:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoFailureException
at
[jira] [Commented] (ARCHETYPE-478) cannot run archetype:create-from-project when dependency on maven-ear-plugin
[
https://issues.apache.org/jira/browse/ARCHETYPE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578667#comment-14578667
]
Pop Qvarnström commented on ARCHETYPE-478:
--
FilesetArchetypeCreator:rewriteEARPluginReferences(...) seems to be the place
where it blows up, while rewriting pluginManagement items. Ear plugin
references are treated specially, and a configuration seems to be expected. If
there is none (not uncommon in plugin management), there will be an NPE.
{code:title=FilesetArchetypeCreator.java:686-}
private void rewriteEARPluginReferences( Plugin plugin, String
rootArtifactId, String groupId )
{
Xpp3Dom configuration = (Xpp3Dom) plugin.getConfiguration();
HERE --Xpp3Dom[] modules = configuration.getChild( modules ).getChildren();
for ( int i = 0; i modules.length; i++ )
{code}
cannot run archetype:create-from-project when dependency on maven-ear-plugin
Key: ARCHETYPE-478
URL: https://issues.apache.org/jira/browse/ARCHETYPE-478
Project: Maven Archetype
Issue Type: Bug
Affects Versions: 2.3
Environment: Windows 7, Maven 3.2.5 and 3.0.5, JDK 7.0.75
Reporter: Bernard LUPIN
Attachments: myproj.zip
I'm migrating maven-archetype-plugin from 2.2 to 2.3.
I cannot create an archetype if my project has a dependency on
maven-ear-plugin.
Using attached pom.xml and running mvn archetype:create-from-project gives me
following error :
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project
(default-cli) on project myproj: null: MojoFailureException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project
(default-cli) on project myproj: null
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
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:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoFailureException
at
org.apache.maven.archetype.mojos.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:258)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
I tried several versions of maven-ear-plugin, adding configuration or not, I
always get this obscure error.
Everything works well with previous archetype plugin version 2.2.
And everything works well with archetype plugin version 2.3 without
maven-ear-plugin.
Regards,
Bernard
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ARCHETYPE-478) cannot run archetype:create-from-project when dependency on maven-ear-plugin
[
https://issues.apache.org/jira/browse/ARCHETYPE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578667#comment-14578667
]
Pop Qvarnström edited comment on ARCHETYPE-478 at 6/9/15 10:19 AM:
---
FilesetArchetypeCreator:rewriteEARPluginReferences(...) seems to be the place
where it blows up, while rewriting pluginManagement items. Ear plugin
references are treated specially, and a configuration seems to be expected. If
there is none (not uncommon in plugin management), there will be an NPE.
{code:title=FilesetArchetypeCreator.java:686-}
private void rewriteEARPluginReferences( Plugin plugin, String
rootArtifactId, String groupId )
{
Xpp3Dom configuration = (Xpp3Dom) plugin.getConfiguration();
HERE --Xpp3Dom[] modules = configuration.getChild( modules ).getChildren();
for ( int i = 0; i modules.length; i++ )
{code}
!Debug screenshot showing call stack.png|thumbnail!
!Debug screenshot showing more call stack.png|thumbnail!
was (Author: popq):
FilesetArchetypeCreator:rewriteEARPluginReferences(...) seems to be the place
where it blows up, while rewriting pluginManagement items. Ear plugin
references are treated specially, and a configuration seems to be expected. If
there is none (not uncommon in plugin management), there will be an NPE.
{code:title=FilesetArchetypeCreator.java:686-}
private void rewriteEARPluginReferences( Plugin plugin, String
rootArtifactId, String groupId )
{
Xpp3Dom configuration = (Xpp3Dom) plugin.getConfiguration();
HERE --Xpp3Dom[] modules = configuration.getChild( modules ).getChildren();
for ( int i = 0; i modules.length; i++ )
{code}
cannot run archetype:create-from-project when dependency on maven-ear-plugin
Key: ARCHETYPE-478
URL: https://issues.apache.org/jira/browse/ARCHETYPE-478
Project: Maven Archetype
Issue Type: Bug
Affects Versions: 2.3
Environment: Windows 7, Maven 3.2.5 and 3.0.5, JDK 7.0.75
Reporter: Bernard LUPIN
Attachments: Debug screenshot showing call stack.png, Debug
screenshot showing more call stack.png, myproj.zip
I'm migrating maven-archetype-plugin from 2.2 to 2.3.
I cannot create an archetype if my project has a dependency on
maven-ear-plugin.
Using attached pom.xml and running mvn archetype:create-from-project gives me
following error :
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project
(default-cli) on project myproj: null: MojoFailureException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project
(default-cli) on project myproj: null
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
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:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoFailureException
at
org.apache.maven.archetype.mojos.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:258)
at
[jira] [Commented] (MCOMPILER-236) Compilation error due to MCOMPILER-157 in deploy phase
[
https://issues.apache.org/jira/browse/MCOMPILER-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578675#comment-14578675
]
Miroslav Zaťko commented on MCOMPILER-236:
--
Still here with Maven 3.3.3, Java 1.8.0_45 and maven-compiler-plugin 3.3. No
mentioned workaround seems to be working
Compilation error due to MCOMPILER-157 in deploy phase
--
Key: MCOMPILER-236
URL: https://issues.apache.org/jira/browse/MCOMPILER-236
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.2
Environment: Maven 3.2.3, Java 1.8.0_25
Reporter: Federico Gaule
Attachments: example_prj.tar.gz
After upgrading from 3.1 to 3.2 i'm experiencing compilation errors when
running deploy phase.
It's a mult module project where plugin is configured in master pom:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version3.1/version
configuration
source${compiler.version}/source
target${compiler.version}/target
encodingUTF-8/encoding
!-- -parameter: used to retrieve
parameter names in runtime. i.e get parameter names for api validations --
compilerArgument-parameters/compilerArgument
/configuration
/plugin
{code}
And in one of the modules like this:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
annotationProcessors
!--
JPAMetaModelEntityProcessor is an annotation processor based on JSR_269 with
the task of creating JPA 2 static metamodel classes --
annotationProcessor
org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor
/annotationProcessor
/annotationProcessors
/configuration
/plugin
{code}
Common builds are all ok, but when using deploy phase i got a compiler error
{noformat}
An exception has occurred in the compiler (1.8.0_25). Please file a bug at
the Java Developer Connection (http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and the
following diagnostic in your report. Thank you.
java.lang.IllegalStateException: endPosTable already set
at
com.sun.tools.javac.util.DiagnosticSource.setEndPosTable(DiagnosticSource.java:136)
at com.sun.tools.javac.util.Log.setEndPosTable(Log.java:350)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667)
at
com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.init(JavacProcessingEnvironment.java:892)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.next(JavacProcessingEnvironment.java:921)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1187)
at
com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
at com.sun.tools.javac.main.Main.compile(Main.java:523)
at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129)
at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138)
at
org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
at
org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:169)
at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:823)
at
org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[jira] [Commented] (MSHADE-181) Allow including dependencies of scope:provided
[
https://issues.apache.org/jira/browse/MSHADE-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578679#comment-14578679
]
Matthias Stevens commented on MSHADE-181:
-
To be perfectly honest, I don't remember. It's been too long :-).
I'll try to find some time to dig into this again so I can answer your question.
Allow including dependencies of scope:provided
---
Key: MSHADE-181
URL: https://issues.apache.org/jira/browse/MSHADE-181
Project: Maven Shade Plugin
Issue Type: Wish
Affects Versions: 2.3
Reporter: Matthias Stevens
Fix For: waiting-for-feedback
I have a project for which I'd like to create a shaded jar.
It has a bunch of dependencies in scope:provided, because they really are, in
the normal use-case of this artifact; it's meant to be deployed as a plugin
in another app, so, for example, {{myapp-api}} really is provided.
The project's assembly depends on these deps to be scope:provided (so they're
not included in the assembly)
If a webapp project is made and depends on this project, the scope:provided
also helps avoiding duplicated dependencies in some cases.
.. but yes, this project now also needs a standalone/executable jar; some of
the provided dependencies are needed at runtime for this. As far as I can
tell, the shade plugin currently does not propose any solution for this.
Is there any way this could be considered for the plugin ? Or am I looking at
it the wrong way ? I suppose I could split my project and have 2 modules, one
simply being the standalone/shaded version of the other, but it seems
overkill, since they're really the same source.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSHADE-181) Allow including dependencies of scope:provided
[
https://issues.apache.org/jira/browse/MSHADE-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578761#comment-14578761
]
Karl Heinz Marbaise commented on MSHADE-181:
Hey no problem take your time. I just wan't to prevent if this is really an
issue...
Allow including dependencies of scope:provided
---
Key: MSHADE-181
URL: https://issues.apache.org/jira/browse/MSHADE-181
Project: Maven Shade Plugin
Issue Type: Wish
Affects Versions: 2.3
Reporter: Matthias Stevens
Fix For: waiting-for-feedback
I have a project for which I'd like to create a shaded jar.
It has a bunch of dependencies in scope:provided, because they really are, in
the normal use-case of this artifact; it's meant to be deployed as a plugin
in another app, so, for example, {{myapp-api}} really is provided.
The project's assembly depends on these deps to be scope:provided (so they're
not included in the assembly)
If a webapp project is made and depends on this project, the scope:provided
also helps avoiding duplicated dependencies in some cases.
.. but yes, this project now also needs a standalone/executable jar; some of
the provided dependencies are needed at runtime for this. As far as I can
tell, the shade plugin currently does not propose any solution for this.
Is there any way this could be considered for the plugin ? Or am I looking at
it the wrong way ? I suppose I could split my project and have 2 modules, one
simply being the standalone/shaded version of the other, but it seems
overkill, since they're really the same source.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SCM-798) scm:branch ignores the tagBase parameter, there is not branchBase parameter
[
https://issues.apache.org/jira/browse/SCM-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Bochenski updated SCM-798:
Description:
{code}[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic
configurator --
[DEBUG] (f) basedir = /home/acme/gotham/common_ui
[DEBUG] (f) branch = 2.2/2.2.0
[DEBUG] (f) connectionType = connection
[DEBUG] (s) connectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) developerConnectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) pushChanges = true
[DEBUG] (f) remoteBranching = false
[DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
[DEBUG] -- end configuration --
[INFO] Final Branch Name: '2.2/2.2.0'
[INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui svn
--non-interactive copy --file /tmp/maven-scm-1267210601.commit .
svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
{code}
I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
{code}
if ( !StringUtils.isEmpty( tagBase )
repository.getProvider().equals( svn ) )
{
SvnScmProviderRepository svnRepo = (SvnScmProviderRepository)
repository.getProviderRepository();
svnRepo.setTagBase( tagBase );
}{code}
Adding a parallel handling for {{branchBase}} param should be trivial.
Correcting the documentation is another thing -- the {{tagBase}} parameter is
present on the base Mojo class even though it's ignored in some goals.
was:
{code}[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic
configurator --
[DEBUG] (f) basedir = /home/acme/gotham/common_ui
[DEBUG] (f) branch = 2.2/2.2.0
[DEBUG] (f) connectionType = connection
[DEBUG] (s) connectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) developerConnectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) pushChanges = true
[DEBUG] (f) remoteBranching = false
[DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
[DEBUG] -- end configuration --
[INFO] Final Branch Name: '2.2/2.2.0'
[INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui svn
--non-interactive copy --file /tmp/maven-scm-1267210601.commit .
svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
{code}
I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
{code}
if ( !StringUtils.isEmpty( tagBase )
repository.getProvider().equals( svn ) )
{
SvnScmProviderRepository svnRepo = (SvnScmProviderRepository)
repository.getProviderRepository();
svnRepo.setTagBase( tagBase );
}{code}
Adding a parallel handling for {branchBase}} param should be trivial.
Correcting the documentation is another thing -- the {{tagBase}} parameter is
present on the base Mojo class even though it's ignored in some goals.
scm:branch ignores the tagBase parameter, there is not branchBase parameter
---
Key: SCM-798
URL: https://issues.apache.org/jira/browse/SCM-798
Project: Maven SCM
Issue Type: Bug
Components: maven-plugin, maven-scm-provider-svn
Affects Versions: 1.9.4
Reporter: Jakub Bochenski
Priority: Blocker
{code}[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic
configurator --
[DEBUG] (f) basedir = /home/acme/gotham/common_ui
[DEBUG] (f) branch = 2.2/2.2.0
[DEBUG] (f) connectionType = connection
[DEBUG] (s) connectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) developerConnectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) pushChanges = true
[DEBUG] (f) remoteBranching = false
[DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
[DEBUG] -- end configuration --
[INFO] Final Branch Name: '2.2/2.2.0'
[INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui svn
--non-interactive copy --file /tmp/maven-scm-1267210601.commit .
svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
{code}
I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
{code}
if ( !StringUtils.isEmpty( tagBase )
repository.getProvider().equals( svn ) )
{
SvnScmProviderRepository svnRepo = (SvnScmProviderRepository)
repository.getProviderRepository();
svnRepo.setTagBase( tagBase );
}{code}
Adding a parallel handling for {{branchBase}} param should be trivial.
Correcting the documentation is another thing -- the {{tagBase}} parameter is
present on the base Mojo class even
[jira] [Created] (SCM-798) scm:branch ignores the tagBase parameter, there is not branchBase parameter
Jakub Bochenski created SCM-798:
---
Summary: scm:branch ignores the tagBase parameter, there is not
branchBase parameter
Key: SCM-798
URL: https://issues.apache.org/jira/browse/SCM-798
Project: Maven SCM
Issue Type: Bug
Components: maven-plugin, maven-scm-provider-svn
Affects Versions: 1.9.4
Reporter: Jakub Bochenski
Priority: Blocker
{code}[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic
configurator --
[DEBUG] (f) basedir = /home/acme/gotham/common_ui
[DEBUG] (f) branch = 2.2/2.2.0
[DEBUG] (f) connectionType = connection
[DEBUG] (s) connectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) developerConnectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) pushChanges = true
[DEBUG] (f) remoteBranching = false
[DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
[DEBUG] -- end configuration --
[INFO] Final Branch Name: '2.2/2.2.0'
[INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui svn
--non-interactive copy --file /tmp/maven-scm-1267210601.commit .
svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
{code}
I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
{code}
if ( !StringUtils.isEmpty( tagBase )
repository.getProvider().equals( svn ) )
{
SvnScmProviderRepository svnRepo = (SvnScmProviderRepository)
repository.getProviderRepository();
svnRepo.setTagBase( tagBase );
}{code}
Adding a parallel handling for {branchBase}} param should be trivial.
Correcting the documentation is another thing -- the {{tagBase}} parameter is
present on the base Mojo class even though it's ignored in some goals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SCM-798) scm:branch ignores the tagBase parameter, there is not branchBase parameter
[
https://issues.apache.org/jira/browse/SCM-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Bochenski updated SCM-798:
Description:
{code}[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic
configurator --
[DEBUG] (f) basedir = /home/acme/gotham/common_ui
[DEBUG] (f) branch = 2.2/2.2.0
[DEBUG] (f) connectionType = connection
[DEBUG] (s) connectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) developerConnectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) pushChanges = true
[DEBUG] (f) remoteBranching = false
[DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
[DEBUG] (f) tagBase = svn+ssh://s...@svn.acme.com/repos/branches/common_ui
[DEBUG] -- end configuration --
[INFO] Final Branch Name: '2.2/2.2.0'
[INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui svn
--non-interactive copy --file /tmp/maven-scm-1267210601.commit .
svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
{code}
I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
{code}
if ( !StringUtils.isEmpty( tagBase )
repository.getProvider().equals( svn ) )
{
SvnScmProviderRepository svnRepo = (SvnScmProviderRepository)
repository.getProviderRepository();
svnRepo.setTagBase( tagBase );
}{code}
Adding a parallel handling for {{branchBase}} param should be trivial.
Correcting the documentation is another thing -- the {{tagBase}} parameter is
present on the base Mojo class even though it's ignored in some goals.
was:
{code}[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic
configurator --
[DEBUG] (f) basedir = /home/acme/gotham/common_ui
[DEBUG] (f) branch = 2.2/2.2.0
[DEBUG] (f) connectionType = connection
[DEBUG] (s) connectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) developerConnectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) pushChanges = true
[DEBUG] (f) remoteBranching = false
[DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
[DEBUG] -- end configuration --
[INFO] Final Branch Name: '2.2/2.2.0'
[INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui svn
--non-interactive copy --file /tmp/maven-scm-1267210601.commit .
svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
{code}
I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
{code}
if ( !StringUtils.isEmpty( tagBase )
repository.getProvider().equals( svn ) )
{
SvnScmProviderRepository svnRepo = (SvnScmProviderRepository)
repository.getProviderRepository();
svnRepo.setTagBase( tagBase );
}{code}
Adding a parallel handling for {{branchBase}} param should be trivial.
Correcting the documentation is another thing -- the {{tagBase}} parameter is
present on the base Mojo class even though it's ignored in some goals.
scm:branch ignores the tagBase parameter, there is not branchBase parameter
---
Key: SCM-798
URL: https://issues.apache.org/jira/browse/SCM-798
Project: Maven SCM
Issue Type: Bug
Components: maven-plugin, maven-scm-provider-svn
Affects Versions: 1.9.4
Reporter: Jakub Bochenski
Priority: Blocker
{code}[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic
configurator --
[DEBUG] (f) basedir = /home/acme/gotham/common_ui
[DEBUG] (f) branch = 2.2/2.2.0
[DEBUG] (f) connectionType = connection
[DEBUG] (s) connectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) developerConnectionUrl =
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG] (f) pushChanges = true
[DEBUG] (f) remoteBranching = false
[DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
[DEBUG] (f) tagBase = svn+ssh://s...@svn.acme.com/repos/branches/common_ui
[DEBUG] -- end configuration --
[INFO] Final Branch Name: '2.2/2.2.0'
[INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui svn
--non-interactive copy --file /tmp/maven-scm-1267210601.commit .
svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
{code}
I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
{code}
if ( !StringUtils.isEmpty( tagBase )
repository.getProvider().equals( svn ) )
{
SvnScmProviderRepository svnRepo = (SvnScmProviderRepository)
repository.getProviderRepository();
svnRepo.setTagBase( tagBase );
}{code}
Adding a parallel handling for
[jira] [Commented] (SUREFIRE-1142) Summarize at End in multimodule projects
[
https://issues.apache.org/jira/browse/SUREFIRE-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579759#comment-14579759
]
Tibor Digana commented on SUREFIRE-1142:
[~agudian]
Andreas, are you still interested in this issue. Do you have a solution?
Summarize at End in multimodule projects
Key: SUREFIRE-1142
URL: https://issues.apache.org/jira/browse/SUREFIRE-1142
Project: Maven Surefire
Issue Type: New Feature
Reporter: Andreas Gudian
In multimodule projects with {{testFailureIgnore=true}}, it is very tedious
to find out if / where there were any test failures when building on the
console. Our HTML report format is of no real help there either.
I suggest to display the test summary of failing tests at the end of the
reactor build (or after the last of the reactor projects) in case
{{testFailureIgnore=true}}.
Implementation-wise, we can do it like install / deploy do it with their
{{installAtEnd}} / {{deployAtEnd}} options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SUREFIRE-1084) Surefire-report stack traces appear on a single line.
[ https://issues.apache.org/jira/browse/SUREFIRE-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1084. -- Resolution: Fixed commit 8a2cd06aae749ed63d62541842b58f8983c71a0b Surefire-report stack traces appear on a single line. - Key: SUREFIRE-1084 URL: https://issues.apache.org/jira/browse/SUREFIRE-1084 Project: Maven Surefire Issue Type: Bug Reporter: Josh Eversmann Assignee: Tibor Digana Priority: Minor Fix For: 2.19 Attachments: Screen Shot 2014-06-30 at 6.40.32 PM.png The pre tags and line breaks used by SurefireReportGenerator .constructFailureDetails do not correctly format the stack trace in the generated page. Related PR: https://github.com/apache/maven-surefire/pull/41 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1064) Provide a way to run only failed tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1064: --- Fix Version/s: 3.0 Provide a way to run only failed tests -- Key: SUREFIRE-1064 URL: https://issues.apache.org/jira/browse/SUREFIRE-1064 Project: Maven Surefire Issue Type: New Feature Components: Maven Failsafe Plugin Reporter: Pascal Schumacher Fix For: 3.0 We use maven for end-to-end tests of a highly asynchronous system (which includes third-party software we can not modify). Sometimes only 1-3 out of hundreds of test fail. It would be nice if there were a way to rerun these failed test only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-5841) Install plugin should generate md5 in same format as
Julian Hyde created MNG-5841: Summary: Install plugin should generate md5 in same format as Key: MNG-5841 URL: https://issues.apache.org/jira/browse/MNG-5841 Project: Maven Issue Type: Bug Reporter: Julian Hyde maven-install-plugin generates md5 and sha1 files that contain just a checksum (and no newline), whereas md5sum generates a file with a checksum and the file name. It would be good to support that format. See discussion in CALCITE-747. I would rather use maven than resorting to shell scripts as the Phoenix project has (see a later comment in that thread). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MCOMPILER-244) Compiler plugin silently drops -XD flags when fork=false
Paweł Kozioł created MCOMPILER-244:
--
Summary: Compiler plugin silently drops -XD flags when fork=false
Key: MCOMPILER-244
URL: https://issues.apache.org/jira/browse/MCOMPILER-244
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.3, 3.2, 3.1, 3.0
Reporter: Paweł Kozioł
I have Java code that uses two classes from private Java API (sun.security.\*).
When i tried to compile it using jdk1.8.0_45 it failed with error saying that
package sun.security.\* does not exist. I found that i should add flag
{{-XDignore.symbol.file}} to compiler arguments.
It turns out that Maven Compiler Plugin silently ignores that flag and it does
not work unless you also specify {{forktrue/fork}} ([thanks to karmakaze
from StackOverflow for sollution|http://stackoverflow.com/a/30472473])
If you cannot fix this to work with fork=false maybe you could add printing
warning/error to stdout?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1032) Running junit tests too verbose on command line when parallel execution is false
[ https://issues.apache.org/jira/browse/SUREFIRE-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579800#comment-14579800 ] Tibor Digana commented on SUREFIRE-1032: [~tomjenkinson] Still interested in this issue? Running junit tests too verbose on command line when parallel execution is false Key: SUREFIRE-1032 URL: https://issues.apache.org/jira/browse/SUREFIRE-1032 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.16 Reporter: Tom Jenkinson http://jira.codehaus.org/browse/SUREFIRE-968 changed the output of the surefire plugin such that it is easier to identify the output from parallel executed test suites. Although this design may be appropriate for that use case, it does have negative viewability implications and as such it would be useful to minimize usage of that format where possible. Negatives include: If you are developing on a small window it increases the likelihood of wrapping of the text (if your terminal supports wrapping, or a scroll bar if not). For example, if parallel execution is not set to true, it would be better to see the old style output. I agree it is required behaviour in the context of the use case it was intended to solve. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-994) java.lang.ClassNotFoundException: org.testng.TestNG
[
https://issues.apache.org/jira/browse/SUREFIRE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579859#comment-14579859
]
Mikhail Mazurskiy commented on SUREFIRE-994:
[~tibor17], my environment is specified in the corresponding field in the
beginning of the ticket.
java.lang.ClassNotFoundException: org.testng.TestNG
---
Key: SUREFIRE-994
URL: https://issues.apache.org/jira/browse/SUREFIRE-994
Project: Maven Surefire
Issue Type: Bug
Components: classloading, Maven Surefire Plugin, TestNG support
Affects Versions: 2.14, 2.14.1
Environment: Linux mazursky-box 3.8.0-19-generic #30-Ubuntu SMP Wed
May 1 16:35:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
java version 1.7.0_21
OpenJDK Runtime Environment (IcedTea 2.3.9) (7u21-2.3.9-1ubuntu1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
Reporter: Mikhail Mazurskiy
This happens sometimes (rarely). 2.14, 14.1 are affected and earlier versions
too I think.
The setting is:
- parallel build,
- surefire and failsafe are forked always.
Is there anything more I can provide to help debug this?
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.14.1:test (default-test) on
project PROJECT: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.14.1:test failed: There was
an error in the forked process
[ERROR] java.lang.NoClassDefFoundError: org/testng/TestNG
[ERROR] at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:64)
[ERROR] at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:189)
[ERROR] at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:105)
[ERROR] at
org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:117)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[ERROR] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:601)
[ERROR] at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
[ERROR] at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159)
[ERROR] at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87)
[ERROR] at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
[ERROR] at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)
[ERROR] Caused by: java.lang.ClassNotFoundException: org.testng.TestNG
[ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
[ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
[ERROR] at java.security.AccessController.doPrivileged(Native Method)
[ERROR] at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
[ERROR] at
org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:97)
[ERROR] ... 13 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-845) Ability to specify TestNG test names in plugin configuration
[
https://issues.apache.org/jira/browse/SUREFIRE-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579862#comment-14579862
]
Tibor Digana commented on SUREFIRE-845:
---
We dont want to introduce a new parameter but this feature might be a subject
to Surefire 3.0 Extension API. Pls provide a proposal of the API.
Ability to specify TestNG test names in plugin configuration
Key: SUREFIRE-845
URL: https://issues.apache.org/jira/browse/SUREFIRE-845
Project: Maven Surefire
Issue Type: New Feature
Components: TestNG support
Affects Versions: 2.12
Reporter: Baron Roberts
TestNG provides the capability on its command line to specify the name of
tests to run when using a testng.xml suite file. This is very useful for
selectively running tests while still using a testng.xml suite file. It would
be a very useful feature to be able to specify the names of tests to run
within the surefire plugin configuration. Something like:
{noformat}
configuration
suiteXmlFiles
suiteXmlFilesrc/test/resources/testng.xml/suiteXmlFile
/suiteXmlFiles
testnamesregularTests,longTests/testnames
/configuration
{noformat}
Which would correspond to the testng.xml file:
{noformat}
!DOCTYPE suite SYSTEM http://testng.org/testng-1.0.dtd;
suite name=TestSuite verbose=2
parameter name=saveBytes value=false/
test name=regularTests
groups
run
exclude name=foo/
/run
/groups
packages
package name=com.mycompany.joe.*/
/packages
/test
test name=longTests
packages
package name=com.mycompany.joe.*/
/packages
/test
/suite
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-826) maven-surefire-plugin does not add its own plugin dependencies to the classpath
[
https://issues.apache.org/jira/browse/SUREFIRE-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579873#comment-14579873
]
Tibor Digana commented on SUREFIRE-826:
---
[~rzanner]
Is this still an issue?
maven-surefire-plugin does not add its own plugin dependencies to the
classpath
---
Key: SUREFIRE-826
URL: https://issues.apache.org/jira/browse/SUREFIRE-826
Project: Maven Surefire
Issue Type: Improvement
Components: classloading, Maven Surefire Plugin
Affects Versions: 2.11
Environment: Maven 3.0.3
Java 6
Reporter: René Zanner
Currently some JAR containing a RunListener for JUnit must be located in the
project's classpath (and pollutes the classpath with most likely unwanted
transitive dependencies).
An alternative is to use the 'additionalClasspathElements' configuration
element in the maven-surefire-plugin's configuration. Unfortunately this
cannot be used to specify another maven artifact directly - only JARs or
class folders in the file system.
It would be consistent to enable the usage of plugin dependencies
({{dependencies}} element in the {{plugin}} section of the POM) to load
such classes:
{code:xml}
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
properties
property
namelistener/name
valuesome.RunListener/value
/property
/properties
/configuration
!--
reference the JAR containing the class some.RunListener as plugin
dependency
(this is possible from the Maven point of view, but currently does
not work)
--
dependencies
dependency
groupIdsome.group.id/groupId
artifactIdsome-artifact-id/artifactId
version${some.version}/version
/dependency
/dependencies
/plugin
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1068) forkNumber in systemPropertyVariables requires prefix
[
https://issues.apache.org/jira/browse/SUREFIRE-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1068:
---
Fix Version/s: 3.0
forkNumber in systemPropertyVariables requires prefix
-
Key: SUREFIRE-1068
URL: https://issues.apache.org/jira/browse/SUREFIRE-1068
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.16
Reporter: Eric Pederson
Assignee: Tibor Digana
Priority: Minor
Fix For: 3.0
The {{$\{surefire.forkNumber\}}} placeholder cannot be used alone in a
{{systemPropertyVariable}}. The workaround is to prefix the value.
For example, this doesn't work (the {{surefire.forkNumber}} system property
does not exist when running the test).
{code:xml}
systemPropertyVariables
surefire.forkNumber${surefire.forkNumber}/surefire.forkNumber
/systemPropertyVariables
{code}
But this does:
{code:xml}
systemPropertyVariables
surefire.forkNumber0${surefire.forkNumber}/surefire.forkNumber
/systemPropertyVariables
{code}
(note the leading *0*)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SUREFIRE-923) Scanning for junit4.8 when using groups/excludedGroups does not consider transitive dependencies
[
https://issues.apache.org/jira/browse/SUREFIRE-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-923.
-
Resolution: Not A Problem
Scanning for junit4.8 when using groups/excludedGroups does not consider
transitive dependencies
Key: SUREFIRE-923
URL: https://issues.apache.org/jira/browse/SUREFIRE-923
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.12.4
Reporter: James Shaw
I've had to include junit explicitly in my pom to get groups/excludedGroups
to work. If it's included through a transitive dependency I get the error:
{code}
groups/excludedGroups require TestNG or JUunit48+ on project test classpath
{code}
Also, note the typo in JUunit48+ ;)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-921) post-integration-test phase should be executed when pre-integration-test phase fails
[ https://issues.apache.org/jira/browse/SUREFIRE-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579820#comment-14579820 ] Tibor Digana commented on SUREFIRE-921: --- [~davydewaele] [~ddewaele] I am not sure if this can be handled but you can try to fix it and open PR on GitHub. post-integration-test phase should be executed when pre-integration-test phase fails Key: SUREFIRE-921 URL: https://issues.apache.org/jira/browse/SUREFIRE-921 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Affects Versions: 2.12.4 Reporter: Davy De Waele When exceptions occur in the pre-integration-test phase no cleanup is being done (post-integration-test is not executed when pre-integration-test fails). Typically in the pre-integration-test phase servers are started or applications are deployed that can potentially be error-prone and might leave the system in a dirty state. Could this be an enhancement of the failsafe plugin or is there another way to handle this scenario ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SUREFIRE-917) [junit] category simple name matching fails throwing ClassNotFoundException
[
https://issues.apache.org/jira/browse/SUREFIRE-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-917.
-
Resolution: Not A Problem
The documentation specifies fully qualified classes as categories.
Using the category as Simple Class Name is too error prone and does not support
class inheritance with super-categories.
[junit] category simple name matching fails throwing ClassNotFoundException
---
Key: SUREFIRE-917
URL: https://issues.apache.org/jira/browse/SUREFIRE-917
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support
Affects Versions: 2.12.4
Reporter: Peter Lynch
Attachments: fix_support_for_junit_simple_group_name_matching.patch
According to a [unit test I
found|https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-grouper/src/test/java/org/apache/maven/surefire/group/parse/GroupMatcherParserTest.java;h=e92595a09de1eb706f54c70b8efe8df592e40ec5;hb=HEAD#l134]
JUnit categories/group support should allow matching groups by the category
interface simple name along with the fully qualified name.
Example , given category interfaces:
{noformat}
category.Fast
category.Slow
{noformat}
The following commands should be equivalent:
{noformat}
mvn test -Dgroups=Slow,Fast
mvn test -Dgroups=category.Slow,category.Fast
mvn test -Dgroups=category.Slow.class,category.Fast.class
{noformat}
In my testing, the first command does not work. Instead I get the following
exception:
{noformat}
org.apache.maven.surefire.util.SurefireReflectionException:
java.lang.reflect.InvocationTargetException; nested exception is
java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.RuntimeException: Unable to load category: Fast
at
org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
at
org.apache.maven.surefire.group.match.JoinGroupMatcher.loadGroupClasses(JoinGroupMatcher.java:44)
at
org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
at
org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
at
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
... 9 more
Caused by: java.lang.ClassNotFoundException: Fast
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at
org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
... 13 more
{noformat}
It seems like if a category name cannot be loaded, it should just be ignored.
I added an integration test that proves the failure and supplied a patch
which avoids the problem to allow specifying the simple class name for
matching.
It would be great to have this working to allow a developer to easily run
specific groups of tests in a concise manner.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-903) Execute tests by group as well as by class
[
https://issues.apache.org/jira/browse/SUREFIRE-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579841#comment-14579841
]
Tibor Digana commented on SUREFIRE-903:
---
[~chrisjr]
The combination of -Dtest=className and -Dgroups=... should work. Can you test
it?
Execute tests by group as well as by class
--
Key: SUREFIRE-903
URL: https://issues.apache.org/jira/browse/SUREFIRE-903
Project: Maven Surefire
Issue Type: New Feature
Components: Maven Surefire Plugin
Affects Versions: 2.12.2
Environment: Maven 3, TestNG 6.7, NetBeans 7.2
Reporter: Chris Rankin
Similar to SUREFIRE-577, only execute methods on a class if they belong to a
certain group or groups.
NetBean's Test File action invokes a particular TestNG class via
{{-Dtest=className}}. However, this completely ignores the TestNG groups and
executes _every_ {{@Test}}, including {{@BeforeClass}} methods that were
supposed to have been excluded (and mutually exclusive!).
Using {{-Dgroups=...}} respects the grouping but also executes all classes,
whereas I am trying to debug only one class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-860) additionalClasspathElement doesn't work for folders with jar filers
[ https://issues.apache.org/jira/browse/SUREFIRE-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579851#comment-14579851 ] Tibor Digana commented on SUREFIRE-860: --- [~necromantiarian] Is this still reproducible? additionalClasspathElement doesn't work for folders with jar filers --- Key: SUREFIRE-860 URL: https://issues.apache.org/jira/browse/SUREFIRE-860 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Affects Versions: 2.12 Environment: windows maven2 maven3 Reporter: necromantiarian used such config version2.12/version configuration additionalClasspathElements additionalClasspathElementC:/mycompany/lib/*.jar/additionalClasspathElement /additionalClasspathElements /configuration wanted to include a lot of *.jar files to classpath observed: surefire.test.class.path=D:\zf\workspace\test\target\test-classes;D:\zf\workspace\test\target\classes;C:\Users\myuser\.m2\repository\junit\junit\4.10\junit-4.10.jar;C:\Users\myuser\.m2\repository\org\hamcrest\hamcrest-core\1.1\hamcrest-core-1.1.jar;C:/mycompany/lib/*.jar and got ClassNotFoundException expected: the classes to be found and all the jars in classpath, just like maven libs note: tried also additionalClasspathElementC:/mycompany/lib//additionalClasspathElement tried older versions of plugin too Am i doing smth wrong ? please advise -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-526) Better support for other plugins to determine which tests are included/excluded and the order the tests get run
[ https://issues.apache.org/jira/browse/SUREFIRE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-526: -- Fix Version/s: 3.0 Better support for other plugins to determine which tests are included/excluded and the order the tests get run --- Key: SUREFIRE-526 URL: https://issues.apache.org/jira/browse/SUREFIRE-526 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Reporter: Nick Pellow Fix For: 3.0 Currently, it is possible to provide the 'test' pattern to the maven-surefire-plugin to include/exclude specific tests to be run. This can be set on the MavenProject instance of any plugin which runs prior to the surefire plugin. Since this is just a pattern of tests to include, it has the following shortcomings: * To excludes a single test, you need to add _all_ tests, minus the test to exclude * The order of the test patterns is not used when the tests get run. If there is no better means to control which tests get run and in which order from outside the surefire plugin, how do you suggest this be achieved? This may require changes to maven core to allow attributes String,Objects be set as well as Properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-526) Better support for other plugins to determine which tests are included/excluded and the order the tests get run
[ https://issues.apache.org/jira/browse/SUREFIRE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579882#comment-14579882 ] Tibor Digana commented on SUREFIRE-526: --- Custom test order is planned in 3.0. Better support for other plugins to determine which tests are included/excluded and the order the tests get run --- Key: SUREFIRE-526 URL: https://issues.apache.org/jira/browse/SUREFIRE-526 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Reporter: Nick Pellow Fix For: 3.0 Currently, it is possible to provide the 'test' pattern to the maven-surefire-plugin to include/exclude specific tests to be run. This can be set on the MavenProject instance of any plugin which runs prior to the surefire plugin. Since this is just a pattern of tests to include, it has the following shortcomings: * To excludes a single test, you need to add _all_ tests, minus the test to exclude * The order of the test patterns is not used when the tests get run. If there is no better means to control which tests get run and in which order from outside the surefire plugin, how do you suggest this be achieved? This may require changes to maven core to allow attributes String,Objects be set as well as Properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-526) Better support for other plugins to determine which tests are included/excluded and the order the tests get run
[ https://issues.apache.org/jira/browse/SUREFIRE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579881#comment-14579881 ] Tibor Digana commented on SUREFIRE-526: --- To excludes a single test just use: -Dtest=!TestToExclude available in 2.19. Better support for other plugins to determine which tests are included/excluded and the order the tests get run --- Key: SUREFIRE-526 URL: https://issues.apache.org/jira/browse/SUREFIRE-526 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Reporter: Nick Pellow Fix For: 3.0 Currently, it is possible to provide the 'test' pattern to the maven-surefire-plugin to include/exclude specific tests to be run. This can be set on the MavenProject instance of any plugin which runs prior to the surefire plugin. Since this is just a pattern of tests to include, it has the following shortcomings: * To excludes a single test, you need to add _all_ tests, minus the test to exclude * The order of the test patterns is not used when the tests get run. If there is no better means to control which tests get run and in which order from outside the surefire plugin, how do you suggest this be achieved? This may require changes to maven core to allow attributes String,Objects be set as well as Properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-895) TestNG reporter options cannot be setup using the Maven Surefire Plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579848#comment-14579848 ] Tibor Digana commented on SUREFIRE-895: --- [~b_c_t] Did you try to setup these options in system properties? TestNG reporter options cannot be setup using the Maven Surefire Plugin --- Key: SUREFIRE-895 URL: https://issues.apache.org/jira/browse/SUREFIRE-895 Project: Maven Surefire Issue Type: Improvement Components: TestNG support Reporter: Bimal TestNG reporter options cannot be setup using the Maven Surefire Plugin As per the TestNG (http://testng.org/doc/documentation-main.html#logging-reporters) Following options can be setup using Ant only outputDirectory timestampFormat fileFragmentationLevel splitClassAndPackageNames generateGroupsAttribute generateTestResultAttributes stackTraceOutputMethod generateDependsOnMethods generateDependsOnGroups In my project I'm using Maven. This cannot be achieved with Maven Surefire Plugin. Please Add this feature to Maven Surefire Plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SUREFIRE-840) Print memory usage
[
https://issues.apache.org/jira/browse/SUREFIRE-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-840.
-
Resolution: Won't Fix
Print memory usage
--
Key: SUREFIRE-840
URL: https://issues.apache.org/jira/browse/SUREFIRE-840
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Surefire Plugin
Reporter: simon.brandhof
The memory usage is helpful when the process is forked. It could look like :
* When forkMode is once :
{noformat}
Results :
Tests run: 20, Failures: 0, Errors: 0, Skipped: 0
Tests Memory: 91M/171M
{noformat}
* When forkMode is always :
{noformat}
Running org.foo.MyTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec,
Memory usage: 91M/171M
{noformat}
* When forkMode is perthread :
{noformat}
Results :
Tests run: 20, Failures: 0, Errors: 0, Skipped: 0
Tests Memory: 91M/171M, 20M/171M, 87M/200M
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://issues.apache.org/jira/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580033#comment-14580033 ] Kristian Rosenvold commented on MASSEMBLY-748: -- Use encoding parameter in http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_unpackOptions to inidcate the encoding of the file you are unpacking. problem to extract zip files including file names with umlauts -- Key: MASSEMBLY-748 URL: https://issues.apache.org/jira/browse/MASSEMBLY-748 Project: Maven Assembly Plugin Issue Type: Bug Components: maven-archiver Affects Versions: 2.5.3 Environment: Reporter: Hannes Kogler Assignee: Kristian Rosenvold Fix For: 2.5.4 Attachments: encoding_problem_on_zip_extract.7z Like in an other issue reported, you need to explicitly set the code page CP850 to create zip packages hosting file names with correct umlauts their names. (by using the following configuration) archiverConfig encodingCP850/encoding /archiverConfig After all this solution is not 100% useful, because if you extract this file with the obiously correct umlauts in the zip, wrong chars for all umlauts reappear. It's strange, because if you unzip this zip file with all other zip tools (7zip, Windows native zip support aso.) the extraction works fine. Only using the maven-assembly-plugin the umlauts get corrupted. (a try to set the archiverConfig with the CP850 also for the extracting execution process of the assembly plugin just results in a bad error calling Failed to configure archiver: org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' in class org.codehaus.plexus.archiver.dir.DirectoryArchiver ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SUREFIRE-856) Running single test in Failsafe using CLI does not override includes configuration
[
https://issues.apache.org/jira/browse/SUREFIRE-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-856.
-
Resolution: Fixed
Assignee: Tibor Digana
Fixed in SUREFIRE-1160.
Running single test in Failsafe using CLI does not override includes
configuration
Key: SUREFIRE-856
URL: https://issues.apache.org/jira/browse/SUREFIRE-856
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin
Affects Versions: 2.12
Environment: Mac OS X 10.7, Maven 3.0.3, JDK 1.7.0_04-ea
Reporter: David Drake
Assignee: Tibor Digana
Priority: Minor
Fix For: 2.19
h4. Description
If a single test is specified from using CLI parameters, but the test does
not match the includes pattern for failsafe, then the test will not run.
This is different from the behavior for the surefire plugin, which will run
any test specified using CLI parameters. If the test does match the
includes pattern for failsafe, then it will run.
h4. Reproduction steps
# Create a project with a single test named Sample.java.
# Add the following block to the failsafe configuration:
{code:xml}
includes
include**/Sample.java/include
/includes
{code}
# Run mvn clean verify -Dit.test=Sample from the command line (and verify
that test runs).
# Remove the includes block shown above from the pom.
# Run mvn clean verify -Dit.test=Sample from the command line.
h4. Expected results
Sample test is run, as before, and no other tests are run.
h4. Actual results
No tests are run.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SUREFIRE-856) Running single test in Failsafe using CLI does not override includes configuration
[
https://issues.apache.org/jira/browse/SUREFIRE-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-856:
--
Fix Version/s: 2.19
Running single test in Failsafe using CLI does not override includes
configuration
Key: SUREFIRE-856
URL: https://issues.apache.org/jira/browse/SUREFIRE-856
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin
Affects Versions: 2.12
Environment: Mac OS X 10.7, Maven 3.0.3, JDK 1.7.0_04-ea
Reporter: David Drake
Priority: Minor
Fix For: 2.19
h4. Description
If a single test is specified from using CLI parameters, but the test does
not match the includes pattern for failsafe, then the test will not run.
This is different from the behavior for the surefire plugin, which will run
any test specified using CLI parameters. If the test does match the
includes pattern for failsafe, then it will run.
h4. Reproduction steps
# Create a project with a single test named Sample.java.
# Add the following block to the failsafe configuration:
{code:xml}
includes
include**/Sample.java/include
/includes
{code}
# Run mvn clean verify -Dit.test=Sample from the command line (and verify
that test runs).
# Remove the includes block shown above from the pom.
# Run mvn clean verify -Dit.test=Sample from the command line.
h4. Expected results
Sample test is run, as before, and no other tests are run.
h4. Actual results
No tests are run.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows
[ https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-771. Resolution: Invalid Assignee: Kristian Rosenvold The thing is that tar files can also have root-relative files inside it, which means files with a name that starts from the root of the file system. I'll see if I can improve the warning message further.. Regression: Unable to create tar.gz in cross-platform build without error messages on Windows - Key: MASSEMBLY-771 URL: https://issues.apache.org/jira/browse/MASSEMBLY-771 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.5.5 Environment: Windows Reporter: Axel Fontaine Assignee: Kristian Rosenvold Recent versions of the assembly plugin started outputting a harmless, but annoying error message when creating tar.gz files from Windows: [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific root-relative-reference (starting with slash) /mypath This used to work fine with older versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MASSEMBLY-772) tar.gz contents owned by user who ran build
[ https://issues.apache.org/jira/browse/MASSEMBLY-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MASSEMBLY-772: - Issue Type: Wish (was: Bug) tar.gz contents owned by user who ran build --- Key: MASSEMBLY-772 URL: https://issues.apache.org/jira/browse/MASSEMBLY-772 Project: Maven Assembly Plugin Issue Type: Wish Components: maven-archiver Affects Versions: 2.5.5 Environment: Windows, Maven 3.3.3 Reporter: Axel Fontaine When creating a tar.gz, the files it contains have no group (OK), but do have a user (not OK). More specifically it is the user who ran the build. This should really be empty to avoid any surprises. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
