[jira] Commented: (SUREFIRE-290) [PATCH] Forking to java 1.3 not working when using relative paths in modules.
[
http://jira.codehaus.org/browse/SUREFIRE-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115006
]
Mark Holster commented on SUREFIRE-290:
---
Confirmed, after downloading maven 2.0.7 the problem disappeared.
[PATCH] Forking to java 1.3 not working when using relative paths in modules.
-
Key: SUREFIRE-290
URL: http://jira.codehaus.org/browse/SUREFIRE-290
Project: Maven Surefire
Issue Type: Bug
Environment: WinXp + Java 1.3
Reporter: Mark Holster
Attachments: no-relative-classpath-urls-without-typo.patch,
no-relative-classpath-urls.patch
For a java 1.3 multi-module project we use a construction like
{code:xml}
modules
module..\mymodule1/module
module..\..\mymodule2/module
/modules
{code}
The testcases work fine if maven is started in the modules, but when running
from the aggegator pom a ClassNotFoundException on any testcase will occur.
The attached patch add canonnical paths to the classpath if a given path is
absolute.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-290) [PATCH] Forking to java 1.3 not working when using relative paths in modules.
[
http://jira.codehaus.org/browse/SUREFIRE-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Holster updated SUREFIRE-290:
--
Attachment: no-relative-classpath-urls-without-typo.patch
I noticed a typo in the patch. This patch should do the trick
[PATCH] Forking to java 1.3 not working when using relative paths in modules.
-
Key: SUREFIRE-290
URL: http://jira.codehaus.org/browse/SUREFIRE-290
Project: Maven Surefire
Issue Type: Bug
Environment: WinXp + Java 1.3
Reporter: Mark Holster
Fix For: 2.4
Attachments: no-relative-classpath-urls-without-typo.patch,
no-relative-classpath-urls.patch
For a java 1.3 multi-module project we use a construction like
{code:xml}
modules
module..\mymodule1/module
module..\..\mymodule2/module
/modules
{code}
The testcases work fine if maven is started in the modules, but when running
from the aggegator pom a ClassNotFoundException on any testcase will occur.
The attached patch add canonnical paths to the classpath if a given path is
absolute.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPIR-61) [PATCH] Updated CI Systems
[PATCH] Updated CI Systems -- Key: MPIR-61 URL: http://jira.codehaus.org/browse/MPIR-61 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Reporter: Mark Holster Priority: Minor Attachments: ci-systems.patch Added cruisecontrol, luntbuild, hudson buildforge as recognized CI Systems. Removed bugzilla as it is a bug trackings system, not a ci system. If appreciated I could translate the english resource file to the dutch (nl) locale... just let me know. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-116) scm:update doesn't iterate through multi-projects
[ http://jira.codehaus.org/browse/SCM-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_87564 ] Mark Holster commented on SCM-116: -- Please keep in mind that for the ClearCase SCM (and maby others?) the scm:update goal should NOT iterate over modules/subdirectories. Even not when a construction like modules module../Module1/module module../../../Module2/model /modules is specified. At any point in a clearcase view (= a directory structure) the scm:update command will result in an update of the entire directory hierarchy, so iterating over all modules will slow down the update process dramatically. scm:update doesn't iterate through multi-projects - Key: SCM-116 URL: http://jira.codehaus.org/browse/SCM-116 Project: Maven SCM Issue Type: Bug Components: maven-plugin Affects Versions: 1.0-beta-2 Reporter: David Boden Fix For: 1.0 Attachments: UpdateSubprojectsMojo.java scm:update doesn't iterate through projects C:\dev\CDSSSmvn scm:update [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] SalesStation ss_base_shared [INFO] SalesStation cds_ss_shared [INFO] SalesStation ss_offering_shared [INFO] SalesStation ss_base_applet [INFO] SalesStation sales_station_lib [INFO] SalesStation ss_offering_lib [INFO] SalesStation sales_station_applet [INFO] SalesStation cds_ss_applet [INFO] SalesStation cds_ss_lib [INFO] SalesStation SS webapp [INFO] SalesStation FET_S webapp (contains images) [INFO] SalesStation CDSSS webapp [INFO] Searching repository for plugin with prefix: 'scm'. [INFO] [INFO] Building SalesStation CDSSS webapp [INFO]task-segment: [scm:update] (aggregator-style) [INFO] [INFO] [scm:update] [INFO] Executing: cvs -f -q update -d [INFO] Working directory: C:\dev\CDSSS [WARNING] Unknown status: '? '. [WARNING] Unknown status: 'M '. [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 5 seconds [INFO] Finished at: Thu Dec 15 10:38:24 GMT 2005 [INFO] Final Memory: 3M/7M [INFO] C:\dev\CDSSS Any reason why it doesn't iterate? I'm using Maven 2.0.1 and SCM version 1.0-beta-2. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-279) Clearcase scm:update Hangs After Stream Configuration Has Changed (patch included)
[ http://jira.codehaus.org/browse/SCM-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Holster updated SCM-279: - Attachment: scm-clearcase-update.patch Attatched path covers the test-cases as well. Clearcase scm:update Hangs After Stream Configuration Has Changed (patch included) -- Key: SCM-279 URL: http://jira.codehaus.org/browse/SCM-279 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-clearcase Affects Versions: 1.0-beta-4 Environment: Windows XP, Maven 2.0.4, JDK 1.4.2_10 ClearCase version 2003.06.00 (Fri Apr 18 13:06:18 2003) @(#) MVFS version 2003.06.00 (Mar 24 2003 16:39:07) cleartool 2003.06.00 (Wed Apr 2 21:00:48 2003) db_server 2003.06.00 (Fri Mar 28 09:00:29 2003) VOB database schema version: 54 Reporter: Dave Blumenfeld Priority: Critical Attachments: ClearCaseUpdateCommand.java, DebugOutput.txt, scm-clearcase-update.patch Maven hangs when running scm:update goal on a Clearcase snapshot view for a stream that has been rebased (see attached debug output). The same goal works fine once the view is manually updated to the new configuration. Using a custom config spec seems to make no difference (though I'm no expert on config specs). The project POM includes the following lines: scm connectionscm:clearcase:no_spec/connection /scm The hang is caused by the 'cleartool update' command, which requires an extra argument (-force) to prevent it from displaying the following message and waiting for input: The stream's configuration has changed. This update operation will make the view show the new configuration. Do you want to update the view now? [yes] Note that this issue has caused our CruiseControl server to hang, as there does not seem to be any timeout on the scm:update operation. A patch is attached, which fixes the problem by adding the -force argument to the cleartool command. I'll let you guys decide whether there are any other unwanted side-effects of doing this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-110) JUnit test case fails with Maven 2 when looking up an Object in the JBoss using JNDI
[ http://jira.codehaus.org/browse/MSUREFIRE-110?page=comments#action_72961
]
Mark Holster commented on MSUREFIRE-110:
I noticed MSUREFIRE-148 duplicates this issue. That issue is solved so I think
this one can be closed too. Only difference is that in MSUREFIRE-148 is patched
for jdk 1.3, but the documentation
(http://maven.apache.org/download.html#Requirements) says maven needs jdk 1.4.
JUnit test case fails with Maven 2 when looking up an Object in the JBoss
using JNDI
Key: MSUREFIRE-110
URL: http://jira.codehaus.org/browse/MSUREFIRE-110
Project: Maven 2.x Surefire Plugin
Issue Type: Bug
Environment: JBoss 4.0.1
JDK 1.5
Reporter: Snehal Maniar
Priority: Critical
Attachments: booter-url-patch.txt
For a sample JUnit test case trying to lookup an Object in the JBoss registry
using JNDI as shown below
import java.util.Properties;
import javax.naming.Context;
import javax.naming.InitialContext;
import junit.framework.TestCase;
public class TestJBossJNDI extends TestCase {
public void testBindingCtx() throws Exception {
Properties p = new Properties();
p.setProperty(Context.INITIAL_CONTEXT_FACTORY,
org.jnp.interfaces.NamingContextFactory);
p.setProperty(Context.URL_PKG_PREFIXES,
org.jboss.naming:org.jnp.interfaces);
p.setProperty(Context.PROVIDER_URL, jnp://sdv01:1399);
try {
InitialContext ctx = new InitialContext(p);
Object o = ctx.lookup(ConnectionFactory);
System.out.println(Found Object = +
o.getClass().getName());
} catch (Exception e) {
e.printStackTrace();
fail();
}
}
}
I get following exception/error
[INFO]
[INFO] Building Unnamed - middleware:TestMVN:jar:0.0.1
[INFO]task-segment: [test]
[INFO]
[INFO] resources:resources
[INFO] Using default encoding to copy filtered resources.
[INFO] compiler:compile
[INFO] Nothing to compile - all classes are up to date
[INFO] resources:testResources
[INFO] Using default encoding to copy filtered resources.
[INFO] compiler:testCompile
Compiling 1 source file to
C:\dev_corner\eclipse\workspaceII\TestMVN\target\test-classes
[INFO] surefire:test
[INFO] Setting reports dir:
C:\dev_corner\eclipse\workspaceII\TestMVN\target/surefire-reports
---
T E S T S
---
javax.naming.CommunicationException [Root exception is
java.rmi.ServerException: RemoteException occurred in server thread; nested
exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested
exception is:
java.net.MalformedURLException: no protocol: and]
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:663)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:520)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at TestJBossJNDI.testBindingCtx(TestJBossJNDI.java:21)
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:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
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:585)
at
org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:230)
at
org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:204)
at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:217)
at
[jira] Updated: (MSUREFIRE-151) Surefire plugin fails if JUnit is not available
[ http://jira.codehaus.org/browse/MSUREFIRE-151?page=all ] Mark Holster updated MSUREFIRE-151: --- Attachment: no-test-framework-patch.txt The attached patch logs a warning if no test framework could be found and stops executing surefire. Surefire plugin fails if JUnit is not available --- Key: MSUREFIRE-151 URL: http://jira.codehaus.org/browse/MSUREFIRE-151 Project: Maven 2.x Surefire Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Simon Kepp Nielsen Priority: Critical Fix For: 2.3 Attachments: error.txt, no-test-framework-patch.txt The Surefire Plugin fails with the following message, if JUnit is not available on the test classpath: [INFO] No Java test frameworks found This means, that you have to include JUnit in the classpath, even for projects that do not have any unit-tests (e.g. ressource projects or your first Hello World project). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-143) provide option to list all of the test cases which failed when running a build
[ http://jira.codehaus.org/browse/MSUREFIRE-143?page=comments#action_69371 ] Mark Holster commented on MSUREFIRE-143: I had the same problem. I've patched surefire to list the failures/errors location, and provided a diff in MSUREFIRE-141. Maby this patch will work for you too. provide option to list all of the test cases which failed when running a build -- Key: MSUREFIRE-143 URL: http://jira.codehaus.org/browse/MSUREFIRE-143 Project: Maven 2.x Surefire Plugin Type: Improvement Reporter: james strachan Lots of projects I work on have large numbers of test cases; the execution of the tests takes up many screens. We are often see the output... Results : Tests run: 1496, Failures: 0, Errors: 5, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] Then we have to page up manually grepping for FAILURE which can take a while. It would be good to just list the failed test cases in the output -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSUREFIRE-141) Display location of test failures/errors on summary
Display location of test failures/errors on summary --- Key: MSUREFIRE-141 URL: http://jira.codehaus.org/browse/MSUREFIRE-141 Project: Maven 2.x Surefire Plugin Type: Improvement Reporter: Mark Holster Priority: Minor Attachments: error-failure-location.txt Currently the surefire summary only indicates wheather or not there are test failures/errors. On large projects with alot of tests, finding the test that fails can be difficult. The attached patch add the locations (source and test method) that causes the test failures/errors to the summary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-115) Classloading problem for getting a resource
[ http://jira.codehaus.org/browse/MSUREFIRE-115?page=comments#action_66519 ] Mark Holster commented on MSUREFIRE-115: While browsing through the issue's I noticed MSUREFIRE-123 and MSUREFIRE-121 are describing the same problem, and maby MSUREFIRE-109 too. The workaround works for MSUREFIRE-123, and I guess for the others too (no test case attached/uploaded). Classloading problem for getting a resource --- Key: MSUREFIRE-115 URL: http://jira.codehaus.org/browse/MSUREFIRE-115 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.3, 2.2 Environment: Maven 2.0.4 Windows XP Reporter: Wim Deblauwe Priority: Blocker Attachments: surefire-test.zip, workaround-for-fork.zip We are using Betwixt and some of our unit tests fail when run using surefire, but run fine in IntelliJ or Maven 1. Betwixt looks for descriptors with the name of the class + .betwixt to control how something is written out in XML. It uses the construct: myClass.getResource() to find the .betwixt file. E.g. com.mycomp.MyClass - com/mycomp/MyClass.betwixt We have a betwixt file for the java.util.Date class. However, betwixt seems to be unable to pick it up when using surefire. I have created a small test that shows the problem and have attached it. I tried with version 2.2 using different configurations (never, once, pertest) and with version 2.1.3 (default configuration) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-115) Classloading problem for getting a resource
[ http://jira.codehaus.org/browse/MSUREFIRE-115?page=comments#action_66342 ] Mark Holster commented on MSUREFIRE-115: As far as I can see that option only chances the delegation order for loading the classes, but still uses the isolated classloader. Or am I missing something here??? Classloading problem for getting a resource --- Key: MSUREFIRE-115 URL: http://jira.codehaus.org/browse/MSUREFIRE-115 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.3, 2.2 Environment: Maven 2.0.4 Windows XP Reporter: Wim Deblauwe Priority: Blocker Attachments: surefire-test.zip, workaround-for-fork.zip We are using Betwixt and some of our unit tests fail when run using surefire, but run fine in IntelliJ or Maven 1. Betwixt looks for descriptors with the name of the class + .betwixt to control how something is written out in XML. It uses the construct: myClass.getResource() to find the .betwixt file. E.g. com.mycomp.MyClass - com/mycomp/MyClass.betwixt We have a betwixt file for the java.util.Date class. However, betwixt seems to be unable to pick it up when using surefire. I have created a small test that shows the problem and have attached it. I tried with version 2.2 using different configurations (never, once, pertest) and with version 2.1.3 (default configuration) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-115) Classloading problem for getting a resource
[ http://jira.codehaus.org/browse/MSUREFIRE-115?page=comments#action_65715 ] Mark Holster commented on MSUREFIRE-115: I've tried to provide a patch for this issue, but after debugging for a while i'm not sure if this is a bug: The java.util.Date class is loaded by the system classloader while the resource is on the URLClasspath of the isolated classloader that surefire provides. Trying to find a resource in the isolated classloader from the system classloader will never work because of the classloading hierarchy. As documented the surefire plugin runs the tests in the isolated classloader, and therefore (I think) this issue isn't a bug but a consequence of the classloading hiererchy. As far as I can see the only solution to this issue is not loading the tests in the isolated classloader but in the app- or system classloader. Can a surefire guru confirm this :)? Should I try to provide a patch that runs the tests outside the isolated classloader? Classloading problem for getting a resource --- Key: MSUREFIRE-115 URL: http://jira.codehaus.org/browse/MSUREFIRE-115 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.3, 2.2 Environment: Maven 2.0.4 Windows XP Reporter: Wim Deblauwe Priority: Blocker Attachments: surefire-test.zip We are using Betwixt and some of our unit tests fail when run using surefire, but run fine in IntelliJ or Maven 1. Betwixt looks for descriptors with the name of the class + .betwixt to control how something is written out in XML. It uses the construct: myClass.getResource() to find the .betwixt file. E.g. com.mycomp.MyClass - com/mycomp/MyClass.betwixt We have a betwixt file for the java.util.Date class. However, betwixt seems to be unable to pick it up when using surefire. I have created a small test that shows the problem and have attached it. I tried with version 2.2 using different configurations (never, once, pertest) and with version 2.1.3 (default configuration) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSUREFIRE-110) JUnit test case fails with Maven 2 when looking up an Object in the JBoss using JNDI
[ http://jira.codehaus.org/browse/MSUREFIRE-110?page=all ]
Mark Holster updated MSUREFIRE-110:
---
Attachment: booter-url-patch.txt
JUnit test case fails with Maven 2 when looking up an Object in the JBoss
using JNDI
Key: MSUREFIRE-110
URL: http://jira.codehaus.org/browse/MSUREFIRE-110
Project: Maven 2.x Surefire Plugin
Type: Bug
Environment: JBoss 4.0.1
JDK 1.5
Reporter: Snehal Maniar
Priority: Critical
Attachments: booter-url-patch.txt
For a sample JUnit test case trying to lookup an Object in the JBoss registry
using JNDI as shown below
import java.util.Properties;
import javax.naming.Context;
import javax.naming.InitialContext;
import junit.framework.TestCase;
public class TestJBossJNDI extends TestCase {
public void testBindingCtx() throws Exception {
Properties p = new Properties();
p.setProperty(Context.INITIAL_CONTEXT_FACTORY,
org.jnp.interfaces.NamingContextFactory);
p.setProperty(Context.URL_PKG_PREFIXES,
org.jboss.naming:org.jnp.interfaces);
p.setProperty(Context.PROVIDER_URL, jnp://sdv01:1399);
try {
InitialContext ctx = new InitialContext(p);
Object o = ctx.lookup(ConnectionFactory);
System.out.println(Found Object = +
o.getClass().getName());
} catch (Exception e) {
e.printStackTrace();
fail();
}
}
}
I get following exception/error
[INFO]
[INFO] Building Unnamed - middleware:TestMVN:jar:0.0.1
[INFO]task-segment: [test]
[INFO]
[INFO] resources:resources
[INFO] Using default encoding to copy filtered resources.
[INFO] compiler:compile
[INFO] Nothing to compile - all classes are up to date
[INFO] resources:testResources
[INFO] Using default encoding to copy filtered resources.
[INFO] compiler:testCompile
Compiling 1 source file to
C:\dev_corner\eclipse\workspaceII\TestMVN\target\test-classes
[INFO] surefire:test
[INFO] Setting reports dir:
C:\dev_corner\eclipse\workspaceII\TestMVN\target/surefire-reports
---
T E S T S
---
javax.naming.CommunicationException [Root exception is
java.rmi.ServerException: RemoteException occurred in server thread; nested
exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested
exception is:
java.net.MalformedURLException: no protocol: and]
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:663)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:520)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at TestJBossJNDI.testBindingCtx(TestJBossJNDI.java:21)
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:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
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:585)
at
org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:230)
at
org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:204)
at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:217)
at org.apache.maven.surefire.Surefire.run(Surefire.java:165)
at org.apache.maven.surefire.Surefire.run(Surefire.java:89)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
[jira] Created: (MWAR-39) Excludes configuration parameter not working for WEB-INF/lib
Excludes configuration parameter not working for WEB-INF/lib Key: MWAR-39 URL: http://jira.codehaus.org/browse/MWAR-39 Project: Maven 2.x War Plugin Type: Bug Versions: 2.0 Reporter: Mark Holster Attachments: excludes-patch.txt For a project I need to build a war without the dependencies in the WEB-INF/lib, but with the runtime jar's named in the manifest. Before the 2.0 release (2.0-beta-2) I managed this by adding **/lib/*.jar to the excludes configuration parameter. The 2.0 release breaks this functionality, which i think should just work fine according the documentation. Diff taken from /maven/plugins/trunk/maven-war-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-199) Parameter startDate for scm:changelog does not work for Clearcase LT
Parameter startDate for scm:changelog does not work for Clearcase LT Key: SCM-199 URL: http://jira.codehaus.org/browse/SCM-199 Project: Maven SCM Type: Improvement Components: maven-scm-provider-clearcase Environment: Clearcase LT 2003.06.14 Reporter: Mark Holster Priority: Minor Attachments: changelog-patch.txt The startDate configuration parameter for the scm:changelog goal does not pass the -since parameter to the clearcase command. According to SCM-135 this is because Clearcase LT does not support this option. As far as I can see this isn't correct. According to the Clearcase LT Documentation the -since parameter does not work when the -g- raphical parameter is used as well (which isn't the case) (mutual exclusive). I'm not familiar with svn. The included patch is a svn diff taken from /maven/scm/trunk with the subversion plugin in eclipse. The patch is tested locally with Clearcase LT 2003.06.14. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
