[jira] (SUREFIRE-1062) TestNG listeners on separate lines in pom.xml
Kirill Kozlov created SUREFIRE-1062:
---
Summary: TestNG listeners on separate lines in pom.xml
Key: SUREFIRE-1062
URL: https://jira.codehaus.org/browse/SUREFIRE-1062
Project: Maven Surefire
Issue Type: Improvement
Components: TestNG support
Affects Versions: 2.16
Reporter: Kirill Kozlov
Priority: Minor
Currently, maven-surefire-plugin doesn't support setting TestNG listeners on
the separate lines in pom.xml. User must put all listeners at the same line, so
the line becomes very long.
For example, for the following configuration the plugin throws unclear
exception. It's very hard to determine the reason, cause the first idea is that
something wrong with your classpath.
{code}
...
listener
com.company1.testng.listeners.Listener1,
com.company2.testng.listeners.Listener2
...
{code}
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on
project allure-testng-example: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.16:test failed: There was an
error in the forked process
[ERROR] org.apache.maven.surefire.testset.TestSetFailedException: Cannot find
listener class
[ERROR] com.company2.testng.listeners.Listener2; nested exception is
java.lang.ClassNotFoundException:
[ERROR] com.company2.testng.listeners.Listener2
[ERROR] java.lang.ClassNotFoundException:
[ERROR] ru.befree.qa.tools.testng.listeners.LoggerListener
[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:425)
[ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
[ERROR] at java.lang.Class.forName0(Native Method)
[ERROR] at java.lang.Class.forName(Class.java:190)
[ERROR] at
org.apache.maven.surefire.testng.conf.AbstractDirectConfigurator.loadClass(AbstractDirectConfigurator.java:139)
[ERROR] at
org.apache.maven.surefire.testng.conf.AbstractDirectConfigurator.loadListenerClasses(AbstractDirectConfigurator.java:127)
[ERROR] at
org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.getConvertedOptions(TestNGMapConfigurator.java:81)
[ERROR] at
org.apache.maven.surefire.testng.conf.TestNG652Configurator.getConvertedOptions(TestNG652Configurator.java:40)
[ERROR] at
org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:52)
[ERROR] at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:214)
[ERROR] at
org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:84)
[ERROR] at
org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:92)
[ERROR] at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
[ERROR] at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
[ERROR] at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
[ERROR] -> [Help 1]
{code}
Is it a problem to fix AbstractDirectConfigurator class to split the value of
*listener* property using new line symbols too?
Current implementation is:
{code}
String[] classNames = listenerClasses.split( " *, *" );
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5587) When the build fails emit any errors without the user having to specify -e or -X
[
https://jira.codehaus.org/browse/MNG-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341569#comment-341569
]
Michael Osipov commented on MNG-5587:
-
Sometimes, the stacktrace consists of the very same information as
{{e.getMessage()}} and has no benefit. E.g., failed to deleted a file, or
upload failed 401, etc.
> When the build fails emit any errors without the user having to specify -e or
> -X
>
>
> Key: MNG-5587
> URL: https://jira.codehaus.org/browse/MNG-5587
> Project: Maven 2 & 3
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Jason van Zyl
>Assignee: Jason van Zyl
> Fix For: 3.2.2
>
>
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5207) [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers
[
https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341576#comment-341576
]
Jörg Schaible commented on MNG-5207:
Hi Jason,
I have no permission to push, therefore here the diff:
{noformat}
$ git diff
diff --git a/build.sh b/build.sh
index 91be103..9e69a23 100755
--- a/build.sh
+++ b/build.sh
@@ -5,4 +5,4 @@ mvn -v
( cd prepare ; ./prepare.sh )
-mvn clean package
+mvn clean install
{noformat}
> [Regression] Maven 3 fails to calculate proper build order with dependencies
> with classifiers
> -
>
> Key: MNG-5207
> URL: https://jira.codehaus.org/browse/MNG-5207
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Reactor and workspace
>Affects Versions: 3.0.3
>Reporter: Jörg Schaible
>Assignee: Jason van Zyl
>Priority: Critical
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: mng5207-it.tgz, MNG-5207.tgz
>
>
> Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in
> proper order, if a transitive dependency (that is part of the reactor build)
> is overruled in the dependencyManagement section with the current SNAPSHOT
> version. Build order is perfectly calculated with Maven 2.2.1.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (DOXIATOOLS-44) maven-site plugin leaks file descriptord
James Nord created DOXIATOOLS-44: Summary: maven-site plugin leaks file descriptord Key: DOXIATOOLS-44 URL: https://jira.codehaus.org/browse/DOXIATOOLS-44 Project: Maven Doxia Tools Issue Type: Bug Components: Doxia Integration Tools Affects Versions: doxia-integration-tools-1.6 Reporter: James Nord Priority: Critical the Maven site plugin leaks file descriptor - due to a bug in doxia-integration-tools. in getDecorationModel() the DefaultSiteTool creates a reader to load the site.xml file, however it is never closed - causing a handle leak for each module in a multimodule project. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (DOXIATOOLS-44) maven-site plugin leaks file descriptord
[ https://jira.codehaus.org/browse/DOXIATOOLS-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Nord updated DOXIATOOLS-44: - Attachment: DOXIATOOLS-44_PATCH_V1.txt Patch to close the Reader and not wait for GC to kick in (that may never happen) > maven-site plugin leaks file descriptord > > > Key: DOXIATOOLS-44 > URL: https://jira.codehaus.org/browse/DOXIATOOLS-44 > Project: Maven Doxia Tools > Issue Type: Bug > Components: Doxia Integration Tools >Affects Versions: doxia-integration-tools-1.6 >Reporter: James Nord >Priority: Critical > Attachments: DOXIATOOLS-44_PATCH_V1.txt > > > the Maven site plugin leaks file descriptor - due to a bug in > doxia-integration-tools. > in getDecorationModel() the DefaultSiteTool creates a reader to load the > site.xml file, however it is never closed - causing a handle leak for each > module in a multimodule project. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5587) When the build fails emit any errors without the user having to specify -e or -X
[ https://jira.codehaus.org/browse/MNG-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341608#comment-341608 ] Jason van Zyl commented on MNG-5587: It's not usually the case that you can provide too much information when something goes wrong. Any user that I have asked would prefer this and in the event that something goes wrong provide as much information as possible. If you have a transport error it happens in the connector and you're not going to see much without the stack trace. > When the build fails emit any errors without the user having to specify -e or > -X > > > Key: MNG-5587 > URL: https://jira.codehaus.org/browse/MNG-5587 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.2.2 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5587) When the build fails emit any errors without the user having to specify -e or -X
[ https://jira.codehaus.org/browse/MNG-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341611#comment-341611 ] Jason van Zyl commented on MNG-5587: The ideal case is we deterministically know exactly what wrong and can tell the user exactly how to fix it. This is not really possible right now though we've made steps in this direction. In the absence of being able to do this, in the event something goes wrong I want to provide as much information, and am not really concerned in the few cases where the information is extraneous. I believe this is preferrable to having to run a long build again with the -e flag to get more information. I don't think it would ever make sense to run a flag that gives you less information. > When the build fails emit any errors without the user having to specify -e or > -X > > > Key: MNG-5587 > URL: https://jira.codehaus.org/browse/MNG-5587 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.2.2 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5587) When the build fails emit any errors without the user having to specify -e or -X
[
https://jira.codehaus.org/browse/MNG-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341622#comment-341622
]
Michael Osipov commented on MNG-5587:
-
Jason, fully agree. I had this situtuation several times, I personally agree
but would leave {{-X}} as-is and turn {{-e}} on by default and make {{-e}} a
no-op.
> When the build fails emit any errors without the user having to specify -e or
> -X
>
>
> Key: MNG-5587
> URL: https://jira.codehaus.org/browse/MNG-5587
> Project: Maven 2 & 3
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Jason van Zyl
>Assignee: Jason van Zyl
> Fix For: 3.2.2
>
>
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2570) Maven needs to support multiple logging levels
[
https://jira.codehaus.org/browse/MNG-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341623#comment-341623
]
Michael Osipov commented on MNG-2570:
-
I second Jason's comment, we do now have SLF4J and a dev has full control over
logging. Can this ticket be resolved with {{INCOMPLETE}}?
> Maven needs to support multiple logging levels
> --
>
> Key: MNG-2570
> URL: https://jira.codehaus.org/browse/MNG-2570
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 2.0.4
>Reporter: Brian Fox
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-2570-maven-embedder.patch
>
>
> The current logging levels are essentially verbose (default) and debug (-X).
> We need a slightly less verbose output so that things like compiler warnings
> and other output is actually visable to the developer. Currently it gets
> buried in all the noise.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1062) TestNG listeners on separate lines in pom.xml
[
https://jira.codehaus.org/browse/SUREFIRE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341624#comment-341624
]
Andreas Gudian commented on SUREFIRE-1062:
--
As you already found the spot: would you like to give it a try and submit a
patch? The easiest way is to create a fork on GitHub and send us a pull-request
:-)
What do you think?
> TestNG listeners on separate lines in pom.xml
> -
>
> Key: SUREFIRE-1062
> URL: https://jira.codehaus.org/browse/SUREFIRE-1062
> Project: Maven Surefire
> Issue Type: Improvement
> Components: TestNG support
>Affects Versions: 2.16
>Reporter: Kirill Kozlov
>Priority: Minor
>
> Currently, maven-surefire-plugin doesn't support setting TestNG listeners on
> the separate lines in pom.xml. User must put all listeners at the same line,
> so the line becomes very long.
> For example, for the following configuration the plugin throws unclear
> exception. It's very hard to determine the reason, cause the first idea is
> that something wrong with your classpath.
> {code}
> ...
>
> listener
>
> com.company1.testng.listeners.Listener1,
> com.company2.testng.listeners.Listener2
>
>
> ...
> {code}
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on
> project allure-testng-example: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.16:test failed: There was an
> error in the forked process
> [ERROR] org.apache.maven.surefire.testset.TestSetFailedException: Cannot find
> listener class
> [ERROR] com.company2.testng.listeners.Listener2; nested exception is
> java.lang.ClassNotFoundException:
> [ERROR] com.company2.testng.listeners.Listener2
> [ERROR] java.lang.ClassNotFoundException:
> [ERROR] ru.befree.qa.tools.testng.listeners.LoggerListener
> [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:425)
> [ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> [ERROR] at java.lang.Class.forName0(Native Method)
> [ERROR] at java.lang.Class.forName(Class.java:190)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.AbstractDirectConfigurator.loadClass(AbstractDirectConfigurator.java:139)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.AbstractDirectConfigurator.loadListenerClasses(AbstractDirectConfigurator.java:127)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.getConvertedOptions(TestNGMapConfigurator.java:81)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.TestNG652Configurator.getConvertedOptions(TestNG652Configurator.java:40)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:52)
> [ERROR] at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:214)
> [ERROR] at
> org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:84)
> [ERROR] at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:92)
> [ERROR] at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> [ERROR] at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> [ERROR] at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> [ERROR] -> [Help 1]
> {code}
> Is it a problem to fix AbstractDirectConfigurator class to split the value of
> *listener* property using new line symbols too?
> Current implementation is:
> {code}
> String[] classNames = listenerClasses.split( " *, *" );
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2570) Maven needs to support multiple logging levels
[
https://jira.codehaus.org/browse/MNG-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341627#comment-341627
]
Robert Scholte commented on MNG-2570:
-
In my opinion this shouldn't be closed yet. If something goes wrong and you
don't get enough info, you'd like to activate debug logging, but only for the
failing plugin.
My idea is to add an optional argument to the {{-X}} specifying the plugin or
plugin+goal.
This would give you fast and accurate logging. You could probably get the same
result by changing the logging.properties, but that's far from user friendly.
> Maven needs to support multiple logging levels
> --
>
> Key: MNG-2570
> URL: https://jira.codehaus.org/browse/MNG-2570
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 2.0.4
>Reporter: Brian Fox
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-2570-maven-embedder.patch
>
>
> The current logging levels are essentially verbose (default) and debug (-X).
> We need a slightly less verbose output so that things like compiler warnings
> and other output is actually visable to the developer. Currently it gets
> buried in all the noise.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-143) Nested variables are not filtered
[
https://jira.codehaus.org/browse/MSHARED-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSHARED-143.
--
Resolution: Won't Fix
Assignee: Robert Scholte
> Nested variables are not filtered
> -
>
> Key: MSHARED-143
> URL: https://jira.codehaus.org/browse/MSHARED-143
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
> Java version: 1.5.0_12
> Java home: /usr/java/jdk1.5.0_12/jre
> Default locale: en_US, platform encoding: ANSI_X3.4-1968
> OS name: "linux" version: "2.6.18-92.1.22.el5xen" arch: "i386" Family: "unix"
>Reporter: Michael Cronin
>Assignee: Robert Scholte
>
> I am trying to filter my log4j.properties file in WEB-INF. One line is
> troublesome. The resulting line should be
> log4j.appender.mine.File=$\{myProject.root}/WEB-INF/logs/mine.log
> where myProject is the value of the property project.artifactId.
> I try
> log4j.appender.mine.File=$\{$\{project.artifactId}.root}/WEB-INF/logs/mine.log
> but no substitution is done.
> After much trial and error, I use
> log4j.appender.mine.File=!#!$$\{log4j.root}/WEB-INF/logs/mine.log
> and the following in my pom.xml
> {code:xml}
>
> {$project.artifactId}.root}
>
> ...
>
>
>
> maven-war-plugin
> 2.1-beta-1
>
> !#!
> ...
>
>
>
>
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5102) Mixin POM fragments
[ https://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341631#comment-341631 ] Roman Arkadijovych Muntyanu commented on MNG-5102: -- If I'm not mistaken, dependencies mix-ins are implemented as "Grouping Dependencies" ( see http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html ). Is it possible to extend "pom" packaging behaviour beyond dependencies-only? (so that properties, plugin and dependency management sections also became part of the pom depending on mix-in) > Mixin POM fragments > --- > > Key: MNG-5102 > URL: https://jira.codehaus.org/browse/MNG-5102 > Project: Maven 2 & 3 > Issue Type: Wish > Components: POM >Affects Versions: 2.2.1 >Reporter: Anthony Whitford > Fix For: Issues to be reviewed for 4.x > > Attachments: daddy3.zip, maven-tiles.zip > > > I am looking for a way to _mixin_ POM fragments into POMs. Note that this > idea is beyond parent pom inheritance because all projects inherit from a > corporate parent pom. The problem that I am running into is that the > corporate parent pom is turning into an _"everything but the kitchen sink"_ > POM and I'd like to dissect it into POM fragments relevant for individual > modules. > For example, I would like to have mixins for: > * Java projects (that include static code analysis plugins, javadoc, etc.) > * JPA projects (that include DDL generation) > * Flex projects (that include flexmojos, asdoc, etc.) > * Scala projects (that include the maven-scala-compiler plugin, scaladoc, > etc.) > * JavaScript projects (that include build plugins like > maven-yuicompressor-plugin with jslint and compress goals) > Hopefully, you get the idea. Without the ability to factor pom logic, we are > left with two symptoms: > # copy/paste duplication > # complex _"it does it all"_ parent poms (which slow down builds because more > plugins are loaded even though they might not do anything material) > Note that a project may include multiple mixins as I could have a project > that contains Java code, Scala code, and JavaScript. > Another idea is that the mixins could be parameterized, so that the ultimate > pom can be customized based on the parameters (like tokens). > I recall reading about Mixins coming in Maven 3.1, but could not find any > such issue to watch, so am creating one. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
