[jira] (SUREFIRE-979) Wrong classloader used in SmartStackTraceParser when test-class fails to instantiate
Kristian Rosenvold created SUREFIRE-979: --- Summary: Wrong classloader used in SmartStackTraceParser when test-class fails to instantiate Key: SUREFIRE-979 URL: https://jira.codehaus.org/browse/SUREFIRE-979 Project: Maven Surefire Issue Type: Bug Reporter: Kristian Rosenvold If the test class is missing a dependency (like failing in a static initializer), the SmartStackTraceParser will use the wrong classloader when attempting to load the class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-106) Remember the Dry Run Status
[ https://jira.codehaus.org/browse/MRELEASE-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Roberge updated MRELEASE-106: -- Attachment: 0001-MRELEASE-106-Remember-the-dry-run-status.patch Hi, I took a first pass at this issue. I was also going to attempt to implement a better failure message if user tries to perform release. Remember the Dry Run Status --- Key: MRELEASE-106 URL: https://jira.codehaus.org/browse/MRELEASE-106 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0-beta-4 Environment: Release plugin snapshot 20060509.101136-3, Subversion Reporter: Bob Allison Priority: Minor Labels: contributers-welcome Fix For: Backlog Attachments: 0001-MRELEASE-106-Remember-the-dry-run-status.patch When doing a dry run of a release, make note of that in the release.properties file so that a reasonable failure can occur if the user tries to perform the release. Also, this flag might be used to allow a non-dry-run prepare to occur without needing to do a clean in between (maybe also not need to prompt but reuse the same answers as in the dry run). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-111) Transitive dependencies of optional dependencies are included in WEB-INF/lib
[ https://jira.codehaus.org/browse/MWAR-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322676#comment-322676 ] Adrian commented on MWAR-111: - Same thing here, this correction would be usefull even in 2013 : * Eclipse m2e-wtp doesn't handle packagingExcludes with regex (as adviced by maven skinny wars instructions http://maven.apache.org/plugins/maven-war-plugin/examples/including-excluding-files-from-war.html). * for pure Java EE 6 applicatins : Java EE 6 doesn't say anything on CDI classloading rules for EAR. For some appServers - i.e. JBoss 7.1, we need to package any archive containing CDI beans in EAR, never in war file otherwise we'll get AmiguousException when using n wars. So we'll need to : ** package CDI bean archives in EAR. ** JSF related archives in WARs (otherwise faces-config.xml are not loaded). So we're stuck with using scope provided in war pom.xml for now if we want to use Eclipse and JBoss 7.1 with a Java EE 6 EAR. Transitive dependencies of optional dependencies are included in WEB-INF/lib Key: MWAR-111 URL: https://jira.codehaus.org/browse/MWAR-111 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.0.2 Environment: Maven 2.0.7, JDK 1.6.0_01-b06, JavaEE 5 Reporter: Chris Lance Attachments: AbstractWarMojo.java, MWAR-111.patch, TestProject.zip I have an EAR project (TestEAR) which contains two modules: 1. A JAR module (TestJAR) which has one dependency: commons-lang 2.3 2. A WAR module (TestWAR) which uses [these instructions|http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html] to declare a dependency on TestJAR so that TestJAR is included in TestWAR's manifest classpath, but not copied into WEB-INF/lib (i.e. declares the dependency optional). This works fine for TestJAR itself, but its transitive dependency (commons-lang 2.3) is still copied into WEB-INF/lib. I don't believe this is the correct behavior since all dependencies of a JAR packaged in the EAR must also be packaged in the EAR. So, all a WAR should have to do is put the transitive dependencies in its manifest classpath to inherit them. Basically: in a WAR, transitive dependencies of optional dependencies should inherit the optional flag. I have included a simple test project as an example. Unzip, cd TestProject, and mvn install. Look in TestEAR's target dir and you will see that commons-lang is included in the EAR. Then look in TestWAR's target dir and you will see that commons-lang is also included in both the manifest classpath and the WEB-INF/lib dir. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-979) Wrong classloader used in SmartStackTraceParser when test-class fails to instantiate
[ https://jira.codehaus.org/browse/SUREFIRE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-979. --- Resolution: Fixed Fix Version/s: 2.15 Assignee: Kristian Rosenvold Fixed with IT in 15ad61f56ebe215e84db892256361a51cac68d7d Wrong classloader used in SmartStackTraceParser when test-class fails to instantiate Key: SUREFIRE-979 URL: https://jira.codehaus.org/browse/SUREFIRE-979 Project: Maven Surefire Issue Type: Bug Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: 2.15 If the test class is missing a dependency (like failing in a static initializer), the SmartStackTraceParser will use the wrong classloader when attempting to load the class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-141) keepDependenciesWithProvidedScope does not work
Steve Tynor created MSHADE-141: -- Summary: keepDependenciesWithProvidedScope does not work Key: MSHADE-141 URL: https://jira.codehaus.org/browse/MSHADE-141 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Steve Tynor keepDependenciesWithProvidedScope option does not seem to work. Expected behavior from both poms is to create an uber jar from the following transitive dependencies: [INFO] Including org.apache.activemq:activemq-client:jar:5.8.0 in the shaded jar. [INFO] Including org.slf4j:slf4j-api:jar:1.6.6 in the shaded jar. [INFO] Including org.apache.geronimo.specs:geronimo-jms_1.1_spec:jar:1.1.1 in the shaded jar. [INFO] Including org.fusesource.hawtbuf:hawtbuf:jar:1.9 in the shaded jar. [INFO] Including org.apache.geronimo.specs:geronimo-j2ee-management_1.1_spec:jar:1.0.1 in the shaded jar. I've attached two test cases mvn -f pom-direct.xml clean install will create an empty jar. mvn -f pom-indirect.xml clean install will not include the slf4j-api which is a dependency of activemq-client, but is marked provided in the pom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-141) keepDependenciesWithProvidedScope does not work
[ https://jira.codehaus.org/browse/MSHADE-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Tynor updated MSHADE-141: --- Attachment: pom-indirect.xml pom-direct.xml test cases keepDependenciesWithProvidedScope does not work --- Key: MSHADE-141 URL: https://jira.codehaus.org/browse/MSHADE-141 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Steve Tynor Attachments: pom-direct.xml, pom-indirect.xml keepDependenciesWithProvidedScope option does not seem to work. Expected behavior from both poms is to create an uber jar from the following transitive dependencies: [INFO] Including org.apache.activemq:activemq-client:jar:5.8.0 in the shaded jar. [INFO] Including org.slf4j:slf4j-api:jar:1.6.6 in the shaded jar. [INFO] Including org.apache.geronimo.specs:geronimo-jms_1.1_spec:jar:1.1.1 in the shaded jar. [INFO] Including org.fusesource.hawtbuf:hawtbuf:jar:1.9 in the shaded jar. [INFO] Including org.apache.geronimo.specs:geronimo-j2ee-management_1.1_spec:jar:1.0.1 in the shaded jar. I've attached two test cases mvn -f pom-direct.xml clean install will create an empty jar. mvn -f pom-indirect.xml clean install will not include the slf4j-api which is a dependency of activemq-client, but is marked provided in the pom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-83) Table header are not highlighted enough
Christophe Lallement created MSKINS-83: -- Summary: Table header are not highlighted enough Key: MSKINS-83 URL: https://jira.codehaus.org/browse/MSKINS-83 Project: Maven Skins Issue Type: Improvement Components: Fluido Skin Affects Versions: fluido-1.3.0 Reporter: Christophe Lallement When you draw table (with xdoc for example) The row header has the same background color as other row, meaning it's very difficult to see there is a header. Trying to add bgcolor to xdoc element doesn't change anything. Regards Christophe -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MAVENUPLOAD-2824) Please reactivate - http://jira.codehaus.org/browse/MAVENUPLOAD-2349
Stuart Turton created MAVENUPLOAD-2824: -- Summary: Please reactivate - http://jira.codehaus.org/browse/MAVENUPLOAD-2349 Key: MAVENUPLOAD-2824 URL: https://jira.codehaus.org/browse/MAVENUPLOAD-2824 Project: Maven Upload Requests Issue Type: Wish Reporter: Stuart Turton pldoc.sourceforge.net and associated projects were synchronised with the Maven Central repository using the old rsync method (http://jira.codehaus.org/browse/MAVENUPLOAD-2349) Synchronisation has failed since August 2012 (https://sourceforge.net/p/forge/site-support/3291/) Old Bundle JAR: net.sourceforge.pldoc,mavens...@web.sourceforge.net:/home/groups/p/pl/pldoc/htdocs/m2/,rsync_ssh,Zoltan Farkas,zolyfar...@users.sourceforge.net,, Please reactivate automatic synchronisation under http://pldoc.sourceforge.net/m2/net/sourceforge/pldoc/ Example artefact locations:- http://pldoc.sourceforge.net/m2/net/sourceforge/pldoc/pldoc/1.3.7/pldoc-1.3.7.jar http://pldoc.sourceforge.net/m2/net/sourceforge/pldoc/maven-pldoc-plugin/2.17/maven-pldoc-plugin-2.17.jar http://pldoc.sourceforge.net/m2/net/sourceforge/pldoc/pldoc-cpd/0.0.2/pldoc-cpd-0.0.2.jar http://pldoc.sourceforge.net/m2/net/sourceforge/pldoc/maven-cpd-plugin/0.0.4/maven-cpd-plugin-0.0.4.jar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-634) projectNameTemplate not applied to project references
[
https://jira.codehaus.org/browse/MECLIPSE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322703#comment-322703
]
Patrik Martinovský commented on MECLIPSE-634:
-
isn't it a duplicate of http://jira.codehaus.org/browse/MECLIPSE-586 ?
projectNameTemplate not applied to project references
-
Key: MECLIPSE-634
URL: https://jira.codehaus.org/browse/MECLIPSE-634
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : .project
Affects Versions: 2.7
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
Java version: 1.6.0_16
Java home: C:\Program Files\Java\jdk1.6.0_16\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows vista version: 6.0 arch: amd64 Family: windows
Reporter: Gary Gregory
When I run the command:
mvn -Psetup.eclipse -Declipse.projectNameTemplate=[artifactId]-2.2.x
I get .project files like this one:
{code:xml}
projectDescription
namecxf-api-2.2.x/name
comment/
projects
projectcxf-common-schemas/project
projectcxf-common-utilities/project
projectcxf-xjc-dv/project
/projects
buildSpec
buildCommand
nameorg.eclipse.jdt.core.javabuilder/name
/buildCommand
buildCommand
namenet.sourceforge.pmd.eclipse.plugin.pmdBuilder/name
/buildCommand
buildCommand
namenet.sf.eclipsecs.core.CheckstyleBuilder/name
/buildCommand
buildCommand
namecom.atlassw.tools.eclipse.checkstyle.CheckstyleBuilder/name
/buildCommand
/buildSpec
natures
natureorg.eclipse.jdt.core.javanature/nature
naturenet.sourceforge.pmd.eclipse.plugin.pmdNature/nature
naturenet.sf.eclipsecs.core.CheckstyleNature/nature
naturecom.atlassw.tools.eclipse.checkstyle.CheckstyleNature/nature
/natures
/projectDescription
{code}
You will notice the name has been correctly written:
{code:xml}
namecxf-api-2.2.x/name
{code}
BUT, the references do not have the correct names:
{code:xml}
projects
projectcxf-common-schemas/project
projectcxf-common-utilities/project
projectcxf-xjc-dv/project
/projects
{code}
They should be:
{code:xml}
projects
projectcxf-common-schemas-2.2.x/project
projectcxf-common-utilities-2.2.x/project
projectcxf-xjc-dv-2.2.x/project
/projects
{code}
Which cause the projects to be marked with errors in Eclipse and the
workspace build cannot complete.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-599) Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests
[ https://jira.codehaus.org/browse/SUREFIRE-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322704#comment-322704 ] Dan Tran commented on SUREFIRE-599: --- strange, I am still seeing leak for my test which uses System.out.println() Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests Key: SUREFIRE-599 URL: https://jira.codehaus.org/browse/SUREFIRE-599 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Affects Versions: 2.5 Environment: Ubuntu 9.04 Apache Maven 2.1.0 (r755702; 2009-03-18 19:10:27+) Java version: 1.6.0_16 OS name: linux version: 2.6.31-17-generic arch: i386 Family: unix JUnit 3.8.2 Log4j 1.2.14 Reporter: Mahender Didwania Assignee: Kristian Rosenvold Fix For: 2.7 I have a test class (named ATest) written by extending the JUnit TestCase class. This class has a few test methods which all call the same method on a class (named A) with different parameters, exactly once each. Now the class A which is being tested logs to console using Apache log4j's ConsoleAppender, at INFO level. In the first test method, a message is logged once (which is how it should be). In the second test method, every log message is repeated once (so gets logged twice instead of once). In the third test method, every log message is logged thrice. ... and so on. Please note that the method in class A is invoked only once by the written source-code in each of the test methods and logs only once. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-586) Using -Declipse.projectNameTemplate is broken on multi module projects
[ https://jira.codehaus.org/browse/MECLIPSE-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrik Martinovský updated MECLIPSE-586: Attachment: MNG-586,634-maven-eclipse-plugin.patch if eclipse.projectNameTemplate is specified on the command line it takes precedence over xml plugin configuration for dependent maven projects... Using -Declipse.projectNameTemplate is broken on multi module projects -- Key: MECLIPSE-586 URL: https://jira.codehaus.org/browse/MECLIPSE-586 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : .project, Core : Dependencies resolution and build path (.classpath), Core : Multi-projects Affects Versions: 2.6, 2.7 Environment: Maven version: 2.0.9 Java version: 1.6.0_10-rc OS name: linux version: 2.6.27-14-generic arch: amd64 Family: unix Reporter: Baard Johansen Attachments: MNG-586,634-maven-eclipse-plugin.patch In version 2.5.1 when specifying projectNameTemplate on the commandline, the .project file and references are generated correcly. In 2.6 and 2.7 the project has the correct name, but referenced projects is not using the specified pattern. This renderes the .project-file and .classpath useless. Example (using mvn eclipse:eclipse -Declipse.projectNameTemplate=trunk-[artifactId]) where moduleA depends on moduleB: moduleA/.project projectDescription nametrunk-moduleA/name projects projectmoduleB/project /projects [..] /projectDescription moduleA/.classpath classpath [..] classpathentry kind=src path=/moduleB/ /classpath moduleB/.project projectDescription nametrunk-moduleB/name [..] /projectDescription -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-586) Using -Declipse.projectNameTemplate is broken on multi module projects
[ https://jira.codehaus.org/browse/MECLIPSE-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322705#comment-322705 ] Patrik Martinovský edited comment on MECLIPSE-586 at 3/26/13 3:25 PM: -- MNG-586,634-maven-eclipse-plugin.patch: if eclipse.projectNameTemplate is specified on the command line it takes precedence over xml plugin configuration for dependent maven projects... was (Author: martinovsky): if eclipse.projectNameTemplate is specified on the command line it takes precedence over xml plugin configuration for dependent maven projects... Using -Declipse.projectNameTemplate is broken on multi module projects -- Key: MECLIPSE-586 URL: https://jira.codehaus.org/browse/MECLIPSE-586 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : .project, Core : Dependencies resolution and build path (.classpath), Core : Multi-projects Affects Versions: 2.6, 2.7 Environment: Maven version: 2.0.9 Java version: 1.6.0_10-rc OS name: linux version: 2.6.27-14-generic arch: amd64 Family: unix Reporter: Baard Johansen Attachments: MNG-586,634-maven-eclipse-plugin.patch In version 2.5.1 when specifying projectNameTemplate on the commandline, the .project file and references are generated correcly. In 2.6 and 2.7 the project has the correct name, but referenced projects is not using the specified pattern. This renderes the .project-file and .classpath useless. Example (using mvn eclipse:eclipse -Declipse.projectNameTemplate=trunk-[artifactId]) where moduleA depends on moduleB: moduleA/.project projectDescription nametrunk-moduleA/name projects projectmoduleB/project /projects [..] /projectDescription moduleA/.classpath classpath [..] classpathentry kind=src path=/moduleB/ /classpath moduleB/.project projectDescription nametrunk-moduleB/name [..] /projectDescription -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-599) Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests
[ https://jira.codehaus.org/browse/SUREFIRE-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322706#comment-322706 ] Kristian Rosenvold commented on SUREFIRE-599: - Can you make a small test project to reproduce this ? Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests Key: SUREFIRE-599 URL: https://jira.codehaus.org/browse/SUREFIRE-599 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Affects Versions: 2.5 Environment: Ubuntu 9.04 Apache Maven 2.1.0 (r755702; 2009-03-18 19:10:27+) Java version: 1.6.0_16 OS name: linux version: 2.6.31-17-generic arch: i386 Family: unix JUnit 3.8.2 Log4j 1.2.14 Reporter: Mahender Didwania Assignee: Kristian Rosenvold Fix For: 2.7 I have a test class (named ATest) written by extending the JUnit TestCase class. This class has a few test methods which all call the same method on a class (named A) with different parameters, exactly once each. Now the class A which is being tested logs to console using Apache log4j's ConsoleAppender, at INFO level. In the first test method, a message is logged once (which is how it should be). In the second test method, every log message is repeated once (so gets logged twice instead of once). In the third test method, every log message is logged thrice. ... and so on. Please note that the method in class A is invoked only once by the written source-code in each of the test methods and logs only once. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-599) Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests
[
https://jira.codehaus.org/browse/SUREFIRE-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322711#comment-322711
]
Dan Tran commented on SUREFIRE-599:
---
here is the test
@Test
public void testConsoleLeak()
throws Exception {
while ( true ) {
System.out.println( why is it leaking? );
Thread.sleep( 1 );
}
}
I dont mean to crash surefire, i was using similar code to trouble shoot my
problem
Logs console output multiple times (no. of times log output = the no. of test
being run) for JUnit/XMLUnit tests
Key: SUREFIRE-599
URL: https://jira.codehaus.org/browse/SUREFIRE-599
Project: Maven Surefire
Issue Type: Bug
Components: JUnit 3.x support
Affects Versions: 2.5
Environment: Ubuntu 9.04
Apache Maven 2.1.0 (r755702; 2009-03-18 19:10:27+)
Java version: 1.6.0_16
OS name: linux version: 2.6.31-17-generic arch: i386 Family: unix
JUnit 3.8.2
Log4j 1.2.14
Reporter: Mahender Didwania
Assignee: Kristian Rosenvold
Fix For: 2.7
I have a test class (named ATest) written by extending the JUnit TestCase
class. This class has a few test methods which all call the same method on a
class (named A) with different parameters, exactly once each.
Now the class A which is being tested logs to console using Apache log4j's
ConsoleAppender, at INFO level.
In the first test method, a message is logged once (which is how it should
be).
In the second test method, every log message is repeated once (so gets logged
twice instead of once).
In the third test method, every log message is logged thrice.
...
and so on. Please note that the method in class A is invoked only once by
the written source-code in each of the test methods and logs only once.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
