[jira] Closed: (MSUREFIRE-103) Test failures in
[ http://jira.codehaus.org/browse/MSUREFIRE-103?page=all ] fabrizio giustina closed MSUREFIRE-103. --- Assignee: fabrizio giustina Resolution: Cannot Reproduce Fix Version/s: (was: 2.3) 2.1.1 looks like an old issue that has been fixed time ago. Test failures in - Key: MSUREFIRE-103 URL: http://jira.codehaus.org/browse/MSUREFIRE-103 Project: Maven 2.x Surefire Plugin Issue Type: Bug Affects Versions: 2.1.3 Environment: j2sdk1.4.2_06 Reporter: Alexey Popov Assigned To: fabrizio giustina Fix For: 2.1.1 Original Estimate: 2 hours Remaining Estimate: 2 hours After an update the following error always occurs [INFO] [compiler:testCompile] Compiling 1 source file to ...\target\test-classes [INFO] [surefire:test] [INFO] Setting reports dir: ...\target/surefire-reports java.lang.NoSuchMethodError at org.apache.maven.surefire.SurefireBooter.createForkingClassLoader(SurefireBooter.java:291) at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:680) Exception in thread main [INFO] [ERROR] BUILD ERROR [INFO] [INFO] There are test failures. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47 2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: There are test failures. at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:389) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) ... 16 more -- 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-84) JUnit 4 integration
[ http://jira.codehaus.org/browse/MSUREFIRE-84?page=all ] fabrizio giustina updated MSUREFIRE-84: --- Fix Version/s: 2.3 Component/s: Junit 4.x support JUnit 4 integration --- Key: MSUREFIRE-84 URL: http://jira.codehaus.org/browse/MSUREFIRE-84 Project: Maven 2.x Surefire Plugin Issue Type: Wish Components: Junit 4.x support Reporter: Shinobu Kawai Priority: Minor Fix For: 2.3 It would be great if we could integrate surefire plugin with JUnit 4 -- 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: (MAVENUPLOAD-1109) ehcache-1.2.3 bundle
ehcache-1.2.3 bundle Key: MAVENUPLOAD-1109 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1109 Project: maven-upload-requests Issue Type: Task Reporter: Greg Luck Attachments: ehcache-1.2.3-bundle.jar ehcache-1.2.3 bundle. The tgz was released on sourceforge yesterday. -- 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-160) Documentation link on website does not point to surefire parameter docs
[ http://jira.codehaus.org/browse/MSUREFIRE-160?page=all ] fabrizio giustina updated MSUREFIRE-160: Assignee: fabrizio giustina Affects Version/s: 2.2 Fix Version/s: 2.3 Component/s: documentation Documentation link on website does not point to surefire parameter docs --- Key: MSUREFIRE-160 URL: http://jira.codehaus.org/browse/MSUREFIRE-160 Project: Maven 2.x Surefire Plugin Issue Type: Bug Components: documentation Affects Versions: 2.2 Environment: irrelevant Reporter: Harold Shinsato Assigned To: fabrizio giustina Priority: Minor Fix For: 2.3 On page http://maven.apache.org/plugins/maven-surefire-plugin/howto.html, and the very end, there is a promise that There are other parameters that you can configure like testFailureIgnore, reportsDirectory, and so on. For full documentation, click here. Clicking here only leads back to the empty index page. Where are the docs for the parameters? -- 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] Closed: (MSUREFIRE-160) Documentation link on website does not point to surefire parameter docs
[ http://jira.codehaus.org/browse/MSUREFIRE-160?page=all ] fabrizio giustina closed MSUREFIRE-160. --- Resolution: Fixed documentation has been improved Documentation link on website does not point to surefire parameter docs --- Key: MSUREFIRE-160 URL: http://jira.codehaus.org/browse/MSUREFIRE-160 Project: Maven 2.x Surefire Plugin Issue Type: Bug Components: documentation Affects Versions: 2.2 Environment: irrelevant Reporter: Harold Shinsato Assigned To: fabrizio giustina Priority: Minor Fix For: 2.3 On page http://maven.apache.org/plugins/maven-surefire-plugin/howto.html, and the very end, there is a promise that There are other parameters that you can configure like testFailureIgnore, reportsDirectory, and so on. For full documentation, click here. Clicking here only leads back to the empty index page. Where are the docs for the parameters? -- 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-161) VM Forking manifests itself behind HTTP proxy
[ http://jira.codehaus.org/browse/MSUREFIRE-161?page=all ] fabrizio giustina updated MSUREFIRE-161: Fix Version/s: 2.3 Component/s: classloading VM Forking manifests itself behind HTTP proxy - Key: MSUREFIRE-161 URL: http://jira.codehaus.org/browse/MSUREFIRE-161 Project: Maven 2.x Surefire Plugin Issue Type: Bug Components: classloading Affects Versions: 2.3 Environment: win2k, java 1.5 Reporter: Ben Hood Fix For: 2.3 Attachments: mvn_trace.txt I have reason to believe that the forking behaviour of the surefire execution has adverse effects when executed behind an HTTP proxy in combination with DTD resolution (e.g. the loading of Spring beans). Whilst using surefire to test a project (the acegi module from the mule project, svn respo : http://svn.codehaus.org/mule/trunk/mule/modules/acegi , revision 2859) I was getting DTD resolution errors (see attached trace). I orginally posted this over at Spring: http://opensource.atlassian.com/projects/spring/browse/SPR-2466. Trying to get Eclipse to attach to the Maven debug process I set up (i.e. running maven with MAVEN_OPTS=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8787), I found out that this won't work because the plugin executing the code forks a new VM. After telling the maven surefire-plugin not to fork with this setting: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration forkModenever/forkMode /configuration /plugin /plugins /build the problem with the DTD resolution from Spring went away. Under normal circumstances, the DTD should get resolved from within the classpath, as it is bundled in the jar. So therefore I conclude that it is indeed a maven classloading / VM issue and not a Spring issue as first thought. -- 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] Closed: (MSUREFIRE-43) Surefire fails to start when the local repository and the project (pom.xml) lives in different window drives
[ http://jira.codehaus.org/browse/MSUREFIRE-43?page=all ]
fabrizio giustina closed MSUREFIRE-43.
--
Assignee: fabrizio giustina
Resolution: Fixed
Fix Version/s: 2.2
fixed by SUREFIRE-36
Surefire fails to start when the local repository and the project (pom.xml)
lives in different window drives
Key: MSUREFIRE-43
URL: http://jira.codehaus.org/browse/MSUREFIRE-43
Project: Maven 2.x Surefire Plugin
Issue Type: Bug
Affects Versions: 2.1.2
Environment: Windows XP
Java 1.5.0_06
Maven 2.0.1
Surefire fork mode: once
Reporter: Martin Desruisseaux
Assigned To: fabrizio giustina
Fix For: 2.2
We have the following situation:
- Local repository in {{C:\Documents and Settings\user\.m2}}
- A Maven 2 project in {{P:\MyProject}}.
- Surefire fork mode set to once.
In this configuration, surefire fails with this (somewhat misleading) error
message:
{quote}
Setting reports dir: {{P:\MyProject\target/surefire-reports}}
BUILD ERROR
There are some test failure.
{quote}
This message is misleading because it suggests that some user's tests failed,
while actually Surefile didn't executed a single one. It even failed before
to create the {{surefire-reports}} directory! So we have no indication about
the cause, and printing the stack trace with the {{-e}} option doesn't help
much (I suspect that this is because the stack trace was actually produced by
a different virtual machine instance, and was not passed to the JVM running
Maven). Running Maven with the {{-X}} option provides more hints however. We
can see that Maven try to executes the following command:
{{java -Xmx512M -enableassertions -classpath
C:\...snip...\.m2\repository\org\apache\maven\surefire\surefire-booter\1.5.2\surefire-booter-1.5.2.jar;
C:\Java\Apache\Maven2\bin\..\core\plexus-utils-1.0.5.jar
org.apache.maven.surefire.SurefireBooter P:\MyProject}}
Running this command manually gives the following output:
{code}
ClassLoader: typeclass sun.misc.Launcher$ExtClassLoader, value=...snip...
: file:/C:/Java/1.5/jre/lib/ext/sunjce_provider.jar
: file:/C:/Java/1.5/jre/lib/ext/sunpkcs11.jar
(...snip...)
ClassLoader: typeclass sun.misc.Launcher$AppClassLoader, value=...snip...
: file:/C:/Documents ...snip... /.m2/repository/ ...snip..
./surefire-booter-1.5.2.jar
: file:/C:/Java/Apache/Maven2/core/plexus-utils-1.0.5.jar
ClassLoader: typeclass org.apache.maven.surefire.IsolatedClassLoader,
value=...snip...
: file:/P:/MyProjects/
(...snip...)
: file:/P:/Documents and
Settings/user/.m2/repository/...snip.../surefire-1.5.2.jar
Exception in thread main java.lang.ClassNotFoundException:
org.apache.maven.surefire.Surefire
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
(...snip...)
{code}
As you can see, the path for {{surefire-1.5.2.jar}} wrongly refer to the
drive letter {{P:}}. It should be {{C:}} instead.
--
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-58) Cannot override read-only parameter: classpathElements
[ http://jira.codehaus.org/browse/MSUREFIRE-58?page=all ] fabrizio giustina updated MSUREFIRE-58: --- Fix Version/s: 2.3 Cannot override read-only parameter: classpathElements -- Key: MSUREFIRE-58 URL: http://jira.codehaus.org/browse/MSUREFIRE-58 Project: Maven 2.x Surefire Plugin Issue Type: Bug Affects Versions: 2.1.2 Reporter: Jesper Zedlitz Priority: Minor Fix For: 2.3 When calling mvn site on a multi-module project the goal surefire:test fails for the second project: Error configuring: org.apache.maven.plugins:maven-surefire-plugin. Reason: ERROR: Cannot override read-only parameter: classpathElements in goal: surefire:test mvn test works and runs the tests on all modules. -- 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-47) Add Distributed testing ability
[ http://jira.codehaus.org/browse/MSUREFIRE-47?page=all ] fabrizio giustina updated MSUREFIRE-47: --- Fix Version/s: 2.4 Component/s: TestNG support Add Distributed testing ability --- Key: MSUREFIRE-47 URL: http://jira.codehaus.org/browse/MSUREFIRE-47 Project: Maven 2.x Surefire Plugin Issue Type: Sub-task Components: TestNG support Environment: any Reporter: Jesse Kuhnert Priority: Minor Fix For: 2.4 TestNG now supports running distributed tests, determine feasability of integrating this into surefire. -- 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-68) Implement getTestCount for TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-68?page=all ] fabrizio giustina updated MSUREFIRE-68: --- Affects Version/s: 2.2 Fix Version/s: 2.3 Implement getTestCount for TestNG - Key: MSUREFIRE-68 URL: http://jira.codehaus.org/browse/MSUREFIRE-68 Project: Maven 2.x Surefire Plugin Issue Type: Sub-task Components: TestNG support Affects Versions: 2.2 Reporter: Brett Porter Fix For: 2.3 this isn't required for correct operation of the tests, but may be if a reporter relies on the correct number in the runStarting method (currently, it is unused). -- 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-146) Wishing for a gui flag to run the junit swing testrunner like in maven 1
[ http://jira.codehaus.org/browse/MSUREFIRE-146?page=all ] fabrizio giustina updated MSUREFIRE-146: Affects Version/s: 2.2 Fix Version/s: 2.4 Wishing for a gui flag to run the junit swing testrunner like in maven 1 - Key: MSUREFIRE-146 URL: http://jira.codehaus.org/browse/MSUREFIRE-146 Project: Maven 2.x Surefire Plugin Issue Type: Wish Affects Versions: 2.2 Reporter: Meghan Claire Pike Fix For: 2.4 Wishing for a gui flag to run the junit swing testrunner like in maven 1 test:ui in maven 2.0 would be sweet. -- 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-107) Running tests in JAR files
[ http://jira.codehaus.org/browse/MSUREFIRE-107?page=all ] fabrizio giustina updated MSUREFIRE-107: Affects Version/s: 2.2 Fix Version/s: 2.3 Please check http://maven.apache.org/guides/mini/guide-attached-tests.html Is this what you were looking for? Running tests in JAR files -- Key: MSUREFIRE-107 URL: http://jira.codehaus.org/browse/MSUREFIRE-107 Project: Maven 2.x Surefire Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Hugo Palma Priority: Minor Fix For: 2.3 AFAIK it's not possible to run tests that are in a dependency jar and not in the tested module source files. It would be great if this was possible. -- 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-122) Support tests written in Jython
[ http://jira.codehaus.org/browse/MSUREFIRE-122?page=all ] fabrizio giustina updated MSUREFIRE-122: Assignee: fabrizio giustina Fix Version/s: 2.3 Support tests written in Jython --- Key: MSUREFIRE-122 URL: http://jira.codehaus.org/browse/MSUREFIRE-122 Project: Maven 2.x Surefire Plugin Issue Type: New Feature Reporter: Charlie Groves Assigned To: fabrizio giustina Fix For: 2.3 Attachments: jythonProvider.tar.gz I've written a first pass at a surefire-provider for JUnit and Python unittest TestCases written in Jython. Before I continue any further I'd like to make sure that the provider is wanted and that I'm heading in the right direction. To do the minimum to get it up and running, I've hooked into the maven-surefire-plugin to hook my provider into the system somewhat like the TestNG provider did. maven-surefire-plugin passes a path(defaults to src/test/jython) to the provider. The provider searches the path for files matching include patterns and loads those as Python modules. For every class in the matching modules that extends junit or unittest TestCase, it makes a SurefireTestSuite and exposes them for running. Sound like a decent approach? To give it a spin, apply maven-surefire-plugin.patch, mvn install on the surefire-jython project and run mvn test in jythonProviderTest. It's just contains a single Junit testcase with a failing and passing test. I haven't even checked what happens when the jython tests throw exceptions, and I know there's alot to be done as far as making it a usable plugin, but I felt like getting some feedback before continuing. -- 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-135) Excluding tests with command line pattern
[ http://jira.codehaus.org/browse/MSUREFIRE-135?page=all ]
fabrizio giustina updated MSUREFIRE-135:
Fix Version/s: 2.3
Excluding tests with command line pattern
-
Key: MSUREFIRE-135
URL: http://jira.codehaus.org/browse/MSUREFIRE-135
Project: Maven 2.x Surefire Plugin
Issue Type: New Feature
Affects Versions: 2.2
Environment: All environments running JUnit tests
Reporter: Johannes Carlén
Fix For: 2.3
I'd like to be able to exclude certain tests from being run. An example of
this could be a scenario where I'd like just the unit tests and not the
integration tests to run. In our case, we name all integration test with the
postfix IntTest instead of just Test.
This is now possible through configuring the plugin in the pom, however it is
not possible to decide at the command line if I just like to run some tests
and not all.
Example of use with this implementation would be:
mvn -Dexclude=*IntTest test
which would run all tests - excluding those that ends with IntTest
The amount of code needed for implementation is minimal. In
SurefirePlugin.java:
Just add a property - something like:
/**
* Specify this parameter to exclude test by their name. It follows
* the same conventions as the codetest/code parameter.
*
* @parameter expression=${exclude}
*
*/
private String exclude;
Add this code at line 527
if ( this.exclude != null )
{
String exclude = **/ + this.exclude + .java;
excludes.add(exclude);
getLog().debug( Excluding test with pattern : + exclude
);
}
...and that's all.
--
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-143) provide option to list all of the test cases which failed when running a build
[ http://jira.codehaus.org/browse/MSUREFIRE-143?page=all ] fabrizio giustina updated MSUREFIRE-143: Fix Version/s: 2.3 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 Issue Type: Improvement Reporter: james strachan Fix For: 2.3 Attachments: MSUREFIRE-143-maven-surefire-plugin.patch, MSUREFIRE-143-surefire-api.patch 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] Updated: (MSUREFIRE-159) Surefire should provide a pluggable means to specify a custom provider
[ http://jira.codehaus.org/browse/MSUREFIRE-159?page=all ] fabrizio giustina updated MSUREFIRE-159: Priority: Critical (was: Major) Fix Version/s: 2.4 Issue Type: New Feature (was: Bug) Surefire should provide a pluggable means to specify a custom provider -- Key: MSUREFIRE-159 URL: http://jira.codehaus.org/browse/MSUREFIRE-159 Project: Maven 2.x Surefire Plugin Issue Type: New Feature Affects Versions: 2.3 Reporter: Micah Whitacre Priority: Critical Fix For: 2.4 The current way that surefire determines which provider to use is hard coded and based on a project's dependencies. I would like to write a custom surefire-provider and be able to specify to use that provider without having to patch the surefire plugin. In my case I want to write a surefire-provider that will run Eclipse PDE Junits which wouldn't neccessarily have a specific dependency listed -- 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-66) Fix classloader separation of Test NG
[ http://jira.codehaus.org/browse/MSUREFIRE-66?page=all ] fabrizio giustina updated MSUREFIRE-66: --- Affects Version/s: 2.2 Fix Version/s: 2.3 Fix classloader separation of Test NG - Key: MSUREFIRE-66 URL: http://jira.codehaus.org/browse/MSUREFIRE-66 Project: Maven 2.x Surefire Plugin Issue Type: Sub-task Components: TestNG support Affects Versions: 2.2 Reporter: Brett Porter Fix For: 2.3 Currently, all of the test classes go into the surefire classloader (as before) so that TestNG can find them. Using the context classloader might be the key to avoiding 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] Closed: (MSUREFIRE-153) Ability to add additions to classpath
[ http://jira.codehaus.org/browse/MSUREFIRE-153?page=all ] fabrizio giustina closed MSUREFIRE-153. --- Assignee: fabrizio giustina Resolution: Cannot Reproduce There should be a possibility to add arbritary resources to the classpath while executing the tests what about using build/testResources (default directory is /src/test/resources) in pom.xml? Ability to add additions to classpath - Key: MSUREFIRE-153 URL: http://jira.codehaus.org/browse/MSUREFIRE-153 Project: Maven 2.x Surefire Plugin Issue Type: Improvement Environment: N/A Reporter: David J. M. Karlsen Assigned To: fabrizio giustina Attachments: MSUREFIRE-153-maven-surefire-plugin.patch, SurefirePlugin.java-diff There should be a possibility to add arbritary resources to the classpath while executing the tests. These resources would only be available while executing the tests, so they won't be added in the archive. i suggest a configuration element extendedClasspaths extendedClasspathsome/path/extendedClasspath extendedClasspath/some/other/path/extendedClasspath /extendedClasspaths This issue somewhat related to http://jira.codehaus.org/browse/MJAR-13 / ability to exclude/include filtering in archiver/jar-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] Updated: (SUREFIRE-52) XML Reports include testcases from previous tests
[ http://jira.codehaus.org/browse/SUREFIRE-52?page=all ]
fabrizio giustina updated SUREFIRE-52:
--
Fix Version/s: 2.1
XML Reports include testcases from previous tests
-
Key: SUREFIRE-52
URL: http://jira.codehaus.org/browse/SUREFIRE-52
Project: surefire
Issue Type: Bug
Affects Versions: 2.0
Reporter: bin zhu
Priority: Minor
Fix For: 2.1
Attachments: patch.txt
to reproduce
1. create the following JUnit tests:
public class TestA extends TestCase {
public void test1() {
}
}
public class TestB extends TestCase {
public void test2() {
}
2. run 'mvn clean install'
note that in TEST-TestB.xml includes testcase results from test1 and test2,
even though TestB only has test2()
testsuite errors=0 skipped=0 tests=1 time=0 failures=0
name=TestB
...
testcase time=0 name=test1/
testcase time=0 name=test2/
/testsuite
--
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-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=all ] fabrizio giustina updated SUREFIRE-31: -- Fix Version/s: 2.1 support junit 4.0 - Key: SUREFIRE-31 URL: http://jira.codehaus.org/browse/SUREFIRE-31 Project: surefire Issue Type: Improvement Components: Junit 4.x support Reporter: John Didion Fix For: 2.1 Attachments: SUREFIRE-31-maven-surefire-plugin.patch, SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip I know this is a pretty sizable task. I just wanted to get it in the system now that 4.0 has officially been released. Hopefully this will generate some discussion about how 4.0 will be handled - mainly if it will require a completely seperate implemenation of surefire (keeping the same API so it can easily be used by the maven plugin), or if use of 4.0 will be made a configurable option of the current surefire. Here's some additional features I'd like to see: 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an @Category annotation, or make category a parameter of @Test. However, the filtering mechanism provided by 4.0 is sufficent to support categories given the presense of such an annotation. I recommend putting the @Category annotation in a seperate module (surefire-annotations?) and build support for it into surefire. Hopefully the junit guys could be convinced to incorporate it in a later version. 2. Similarly, support repeated tests via an @Repeated annotation. I'm not sure how easy this would be to do external to junit. -- 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-45) Include/Exclude by class name, not file name
[ http://jira.codehaus.org/browse/SUREFIRE-45?page=all ] fabrizio giustina updated SUREFIRE-45: -- Fix Version/s: 2.2 Include/Exclude by class name, not file name Key: SUREFIRE-45 URL: http://jira.codehaus.org/browse/SUREFIRE-45 Project: surefire Issue Type: New Feature Reporter: Ken Arnold Fix For: 2.2 Right now I include/exclude based on file names. But file names are not class names -- see nested classes or non-public classes. (A class file can contain only one public class, and its name must match its file name, but it can have any number of package-accessible top-level classes.) I would like to be able to specify by class name, not file name. Possibly this a new pair of tags (e.g., excludeClass). -- 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-34) Using security manager in a fork mode causes an AccessControlException
[ http://jira.codehaus.org/browse/SUREFIRE-34?page=all ] fabrizio giustina updated SUREFIRE-34: -- Fix Version/s: 2.1 Using security manager in a fork mode causes an AccessControlException -- Key: SUREFIRE-34 URL: http://jira.codehaus.org/browse/SUREFIRE-34 Project: surefire Issue Type: Bug Affects Versions: 1.5.3 Reporter: Vincent Siveton Priority: Critical Fix For: 2.1 Attachments: SUREFIRE-34.diff Using securityManager in a forkmode causes java.security.AccessControlException in the createClassLoader() method Same things with setSystemProperties() Example: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration forkModepertest/forkMode argLine-Djava.security.manager/argLine /configuration /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] Commented: (MEAR-36) Add classifier fonctionnality to Maven EAR Plugin
[ http://jira.codehaus.org/browse/MEAR-36?page=comments#action_73989 ]
Stephane Nicoll commented on MEAR-36:
-
Eric, the issue is in progress because I started the implementation before
going on holiday. It's implemented in my local sandbox, sorry for not
menitionning it. I am not resolving it because I am busy writing test cases for
the EAR plugin (namely this classifier fonctionnality) and I am stuck on some
major points.
I will make sure that the changes does not break your patch if possible.
Add classifier fonctionnality to Maven EAR Plugin
-
Key: MEAR-36
URL: http://jira.codehaus.org/browse/MEAR-36
Project: Maven 2.x Ear Plugin
Issue Type: Improvement
Affects Versions: 2.2
Environment: Any
Reporter: Mathieu Rozieres
Assigned To: Stephane Nicoll
Fix For: 2.3
Attachments: MEAR-36-maven-ear-plugin.patch
The classifier tag is not implemented into Maven EAR Plugin.
For example, while using this configuration :
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
classifierdev/classifier
/configuration
/plugin
The artefact produced is still named ${pom.artifactId}-${pom.version} ...
--
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: (MSUREFIREREP-27) number of skipped test no shown in html report
[ http://jira.codehaus.org/browse/MSUREFIREREP-27?page=all ] fabrizio giustina updated MSUREFIREREP-27: -- Affects Version/s: 2.0 Fix Version/s: 2.1 Issue Type: Improvement (was: Bug) number of skipped test no shown in html report -- Key: MSUREFIREREP-27 URL: http://jira.codehaus.org/browse/MSUREFIREREP-27 Project: Maven 2.x Surefire report Plugin Issue Type: Improvement Affects Versions: 2.0 Reporter: Bernd Fix For: 2.1 JUnit4 support skipping of tests (@Ignore). Even if they are in the xml report, e.g. testsuite errors=0 skipped=1 tests=2 time=1.141 failures=1 they do not show up in the html report -- 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: (MSUREFIREREP-28) Unable to generate the surefire report if the project is not a java project, but tests are written in JAVA
[ http://jira.codehaus.org/browse/MSUREFIREREP-28?page=all ] fabrizio giustina updated MSUREFIREREP-28: -- Affects Version/s: (was: 2.1) 2.0 Fix Version/s: 2.1 Unable to generate the surefire report if the project is not a java project, but tests are written in JAVA -- Key: MSUREFIREREP-28 URL: http://jira.codehaus.org/browse/MSUREFIREREP-28 Project: Maven 2.x Surefire report Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Christophe DENEUX Fix For: 2.1 Attachments: MSUREFIREREP-28.patch I have a maven project with a POM packaging in which I run test with the maven-surefire-plugin. All works fine, but I am not able to generate the surefire report. After investigations in the source code of the maven-surefire-report-plugin, it seems to me that the implementation of the method SurefireReportMojo.canGenerateReport is not correct. The condition is too restrictive. It seems to me that the condition should be something like Does a surefire execution report exist?. -- 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-122) Support tests written in Jython
[ http://jira.codehaus.org/browse/MSUREFIRE-122?page=comments#action_73990 ] fabrizio giustina commented on MSUREFIRE-122: - Hi Charlie, I tried to integrate your patches, but looks like that tests on the jythonProviderTest don't work properly. After adding the surefire-jython provider and applying your patch to the maven surefire plugin this is what I get when I try running tests: [INFO] Surefire report directory: \jythonProvider.tar\jythonProvider\jythonProviderTest\target\surefire-reports *sys-package-mgr*: processing new jar, 'C:\repository\m2\jython\jython\2.2-alpha1\jython-2.2-alpha1.jar' org.apache.maven.surefire.booter.SurefireExecutionException: Problem reflecting on class org.python.core.PySystemState; nested exception is java.lang.reflect.InvocationTargetException: null; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: Problem reflecting on class org.python.core.PySystemState; nested exception is java.lang.reflect.InvocationTargetException: null org.apache.maven.surefire.testset.TestSetFailedException: Problem reflecting on class org.python.core.PySystemState; nested exception is java.lang.reflect.InvocationTargetException: null java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.maven.surefire.jython.JythonDirectoryTestSuite.setupInterpreter(JythonDirectoryTestSuite.java:130) at org.apache.maven.surefire.jython.JythonDirectoryTestSuite.locateTestSets(JythonDirectoryTestSuite.java:102) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:147) at org.apache.maven.surefire.Surefire.run(Surefire.java:108) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:265) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:792) Caused by: Traceback (innermost last): File string, line 7, in ? ImportError: cannot import name SurefireTestSet at org.python.core.Py.ImportError(Py.java:193) at org.python.core.imp.importFromAs(imp.java:694) at org.python.core.imp.importFrom(imp.java:667) at org.python.pycode._pyx0.f$0(string:7) at org.python.pycode._pyx0.call_function(string) at org.python.core.PyTableCode.call(PyTableCode.java:213) at org.python.core.PyCode.call(PyCode.java:14) at org.python.core.Py.runCode(Py.java:1182) at org.python.core.Py.exec(Py.java:1204) at org.python.util.PythonInterpreter.exec(PythonInterpreter.java:137) ... 14 more [INFO] [ERROR] BUILD FAILURE The problem may be caused by recent changes on the surefire classloader... let me know if you can have a look at it. Support tests written in Jython --- Key: MSUREFIRE-122 URL: http://jira.codehaus.org/browse/MSUREFIRE-122 Project: Maven 2.x Surefire Plugin Issue Type: New Feature Reporter: Charlie Groves Assigned To: fabrizio giustina Fix For: 2.3 Attachments: jythonProvider.tar.gz I've written a first pass at a surefire-provider for JUnit and Python unittest TestCases written in Jython. Before I continue any further I'd like to make sure that the provider is wanted and that I'm heading in the right direction. To do the minimum to get it up and running, I've hooked into the maven-surefire-plugin to hook my provider into the system somewhat like the TestNG provider did. maven-surefire-plugin passes a path(defaults to src/test/jython) to the provider. The provider searches the path for files matching include patterns and loads those as Python modules. For every class in the matching modules that extends junit or unittest TestCase, it makes a SurefireTestSuite and exposes them for running. Sound like a decent approach? To give it a spin, apply maven-surefire-plugin.patch, mvn install on the surefire-jython project and run mvn test in jythonProviderTest. It's just contains a single Junit testcase with a failing and passing test. I haven't even checked what happens when the jython tests throw exceptions, and I know there's alot to be done as far as making it a usable plugin, but I felt like getting some feedback before
[jira] Created: (MAVENUPLOAD-1110) jython-2.2-alpha1
jython-2.2-alpha1 - Key: MAVENUPLOAD-1110 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1110 Project: maven-upload-requests Issue Type: Task Reporter: fabrizio giustina -- 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] Closed: (MSUREFIREREP-27) number of skipped test no shown in html report
[ http://jira.codehaus.org/browse/MSUREFIREREP-27?page=all ] fabrizio giustina closed MSUREFIREREP-27. - Assignee: fabrizio giustina Resolution: Fixed skipped tests are shown in version 2.1 (at the moment for TestNG tests, since Junit 4 support is not available yet) number of skipped test no shown in html report -- Key: MSUREFIREREP-27 URL: http://jira.codehaus.org/browse/MSUREFIREREP-27 Project: Maven 2.x Surefire report Plugin Issue Type: Improvement Affects Versions: 2.0 Reporter: Bernd Assigned To: fabrizio giustina Fix For: 2.1 JUnit4 support skipping of tests (@Ignore). Even if they are in the xml report, e.g. testsuite errors=0 skipped=1 tests=2 time=1.141 failures=1 they do not show up in the html report -- 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: (MEAR-36) Add classifier fonctionnality to Maven EAR Plugin
[ http://jira.codehaus.org/browse/MEAR-36?page=comments#action_73993 ]
Eric Bernstein commented on MEAR-36:
Sorrry Stephane, I didn't mean to step on any toes, but since I was writing it
anyway so I could build my project, I figured I'd hand it back in case it could
be of use.
Don't worry about keeping compatibility with what I submitted, I'm happy to
update my poms when the next ear plugin is released - I hard coded the
dependencies in my projects to my own internal version of the plugin for now,
so I'll have to update eventually.
Just for my own curiosity, are you keeping classified ears as attachments or
making it so that the classified ear could be the only artifact. I was torn,
and as mentioned, ended up just stealing what the jar plugin was doing. Not
sure which way I think is right.
Add classifier fonctionnality to Maven EAR Plugin
-
Key: MEAR-36
URL: http://jira.codehaus.org/browse/MEAR-36
Project: Maven 2.x Ear Plugin
Issue Type: Improvement
Affects Versions: 2.2
Environment: Any
Reporter: Mathieu Rozieres
Assigned To: Stephane Nicoll
Fix For: 2.3
Attachments: MEAR-36-maven-ear-plugin.patch
The classifier tag is not implemented into Maven EAR Plugin.
For example, while using this configuration :
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
classifierdev/classifier
/configuration
/plugin
The artefact produced is still named ${pom.artifactId}-${pom.version} ...
--
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: (SUREFIRE-54) Remove use of parent classloader in surefirebooter but keep TestNG support working
Remove use of parent classloader in surefirebooter but keep TestNG support working -- Key: SUREFIRE-54 URL: http://jira.codehaus.org/browse/SUREFIRE-54 Project: surefire Issue Type: Bug Affects Versions: 2.1 Reporter: fabrizio giustina Priority: Critical The removal of the parent system classloader while running tests in surefire booter totally broke testNG support. I am going to revert the commit: http://svn.apache.org/viewvc/maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SurefireBooter.java?r1=427040r2=438999diff_format=h ... in order to keep testng working for now, but we should find a way to solve both problems soon. The removal of the parent classloader is needed, according to Kenney for the following reason: If this is not done, the System classloader is added, in this case an AppClassloader containing everything in the root classpath. For instance, in maven, everything in core/ is available.This can cause clashes with the plexus-utils used in maven itself. -- 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-153) Ability to add additions to classpath
[ http://jira.codehaus.org/browse/MSUREFIRE-153?page=comments#action_73996 ] fabrizio giustina commented on MSUREFIRE-153: - Test resources are NOT added to the main jar. Are you talking about test-jar artifacts maybe? Ability to add additions to classpath - Key: MSUREFIRE-153 URL: http://jira.codehaus.org/browse/MSUREFIRE-153 Project: Maven 2.x Surefire Plugin Issue Type: Improvement Environment: N/A Reporter: David J. M. Karlsen Assigned To: fabrizio giustina Attachments: MSUREFIRE-153-maven-surefire-plugin.patch, SurefirePlugin.java-diff There should be a possibility to add arbritary resources to the classpath while executing the tests. These resources would only be available while executing the tests, so they won't be added in the archive. i suggest a configuration element extendedClasspaths extendedClasspathsome/path/extendedClasspath extendedClasspath/some/other/path/extendedClasspath /extendedClasspaths This issue somewhat related to http://jira.codehaus.org/browse/MJAR-13 / ability to exclude/include filtering in archiver/jar-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] Commented: (SUREFIRE-54) Remove use of parent classloader in surefirebooter but keep TestNG support working
[ http://jira.codehaus.org/browse/SUREFIRE-54?page=comments#action_73997 ] Milos Kleint commented on SUREFIRE-54: -- when maven is embedded in another application, the System classloader can contain also other stuff from the embedding application. Remove use of parent classloader in surefirebooter but keep TestNG support working -- Key: SUREFIRE-54 URL: http://jira.codehaus.org/browse/SUREFIRE-54 Project: surefire Issue Type: Bug Affects Versions: 2.1 Reporter: fabrizio giustina Priority: Critical The removal of the parent system classloader while running tests in surefire booter totally broke testNG support. I am going to revert the commit: http://svn.apache.org/viewvc/maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SurefireBooter.java?r1=427040r2=438999diff_format=h ... in order to keep testng working for now, but we should find a way to solve both problems soon. The removal of the parent classloader is needed, according to Kenney for the following reason: If this is not done, the System classloader is added, in this case an AppClassloader containing everything in the root classpath. For instance, in maven, everything in core/ is available.This can cause clashes with the plexus-utils used in maven itself. -- 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-153) Ability to add additions to classpath
[ http://jira.codehaus.org/browse/MSUREFIRE-153?page=comments#action_73998 ] David J. M. Karlsen commented on MSUREFIRE-153: --- Testresources would end up in test-jar, likewise resources would end up in main artifact jar. Often you want config to be delivered in a separate directory along with you application, so that operations dept. easily can edit this in the runtime environment. By using the steps proposed in the patch, configuration can be available on cp while executing test, but separated from the jars. Ability to add additions to classpath - Key: MSUREFIRE-153 URL: http://jira.codehaus.org/browse/MSUREFIRE-153 Project: Maven 2.x Surefire Plugin Issue Type: Improvement Environment: N/A Reporter: David J. M. Karlsen Assigned To: fabrizio giustina Attachments: MSUREFIRE-153-maven-surefire-plugin.patch, SurefirePlugin.java-diff There should be a possibility to add arbritary resources to the classpath while executing the tests. These resources would only be available while executing the tests, so they won't be added in the archive. i suggest a configuration element extendedClasspaths extendedClasspathsome/path/extendedClasspath extendedClasspath/some/other/path/extendedClasspath /extendedClasspaths This issue somewhat related to http://jira.codehaus.org/browse/MJAR-13 / ability to exclude/include filtering in archiver/jar-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] Commented: (MEAR-36) Add classifier fonctionnality to Maven EAR Plugin
[ http://jira.codehaus.org/browse/MEAR-36?page=comments#action_73999 ]
Stephane Nicoll commented on MEAR-36:
-
there's no harm Eric :)
Actually, I am doing it the Jar's way but I could change it if necessary.
Add classifier fonctionnality to Maven EAR Plugin
-
Key: MEAR-36
URL: http://jira.codehaus.org/browse/MEAR-36
Project: Maven 2.x Ear Plugin
Issue Type: Improvement
Affects Versions: 2.2
Environment: Any
Reporter: Mathieu Rozieres
Assigned To: Stephane Nicoll
Fix For: 2.3
Attachments: MEAR-36-maven-ear-plugin.patch
The classifier tag is not implemented into Maven EAR Plugin.
For example, while using this configuration :
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
classifierdev/classifier
/configuration
/plugin
The artefact produced is still named ${pom.artifactId}-${pom.version} ...
--
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: (MSITE-141) Possible security hole when deploying site
[ http://jira.codehaus.org/browse/MSITE-141?page=comments#action_74000 ] Christopher McIntosh commented on MSITE-141: When will this issue be addressed? My web host provider, refuses to serve pages whose group mod is 'w'. I tried using the filePermissions and directoryPermissions in settings.xml; but even that does not work... Possible security hole when deploying site -- Key: MSITE-141 URL: http://jira.codehaus.org/browse/MSITE-141 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: Linux gentoo 2.6.16 64bit, maven 2.0.2 Reporter: Martin Vysny Priority: Critical When the site is deployed into a directory /foo/bar, the following command is issued over a ssh: chmod -Rf g+w /foo/bar/ it was intended to use g+r I presume? :-) -- 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-162) NoClassDefFoundError for UrlUtils
NoClassDefFoundError for UrlUtils - Key: MSUREFIRE-162 URL: http://jira.codehaus.org/browse/MSUREFIRE-162 Project: Maven 2.x Surefire Plugin Issue Type: Bug Components: classloading Environment: Win XP/Cygwin Reporter: Rory Winston Surefire starting playing up today - I believe it may be due to some classloader changes that were committed earlier today. The symptoms were java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/UrlUtils at org.apache.maven.surefire.booter.SurefireBooter.createClassLoader(SurefireBoote r.java:599) at org.apache.maven.surefire.booter.SurefireBooter.getTestClassLoader(SurefireBoot er.java:569) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBoot er.java:250) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:807) When trying to run tests. To fix it, I edited the version tag for Surefire in my pom.xml and changed it to 2.2. -- 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: (MSITE-179) Maven-site-plugin ignores the encoding specified in XML file (e.g. site.xml or xdoc/x.xml).
[ http://jira.codehaus.org/browse/MSITE-179?page=comments#action_74001 ] Jochen Wiedmann commented on MSITE-179: --- A small sample project demonstrating the problem would be helpful. Maven-site-plugin ignores the encoding specified in XML file (e.g. site.xml or xdoc/x.xml). --- Key: MSITE-179 URL: http://jira.codehaus.org/browse/MSITE-179 Project: Maven 2.x Site Plugin Issue Type: Bug Reporter: Bernhard Wellhöfer Each XML document defines the used encoding. The maven-site-plugin ignores this encoding and always uses the value of the inputEncoding configuration value. The inputEncoding value should only be used for the non XML site files. -- 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: (MAVEN-1788) maven war reports unsatisfied dependency with some jars even though those jars are in the local repository.
maven war reports unsatisfied dependency with some jars even though those jars are in the local repository. --- Key: MAVEN-1788 URL: http://jira.codehaus.org/browse/MAVEN-1788 Project: Maven Issue Type: Bug Components: core Affects Versions: 1.0.2 Environment: Solaris 10 Reporter: Charles Richard I was trying to get scarab to build and it's probably something i did but there was like 7 jar files that were given in a list of unsatisfied dependencies when i ran maven war -Dmaven.test.skip. I copied those jar files in the local repository and i'm still getting the same error. I get a download error with mode=online because those jars don't exist in ibiblio and i get the same error with mode.online=false which truely baffles me and leaves me wanting to bang my head on something :) My understanding is that Maven should be checking the local repository first to see if those jars are there, isn't this correct? The kicker is it doesn't seem to complain about other jars in the project.xml file. Thanks, Charles -- 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: (MNG-2546) Allow plugin executions in the super-init phase before reactor sorting of modules build order
Allow plugin executions in the super-init phase before reactor sorting of modules build order --- Key: MNG-2546 URL: http://jira.codehaus.org/browse/MNG-2546 Project: Maven 2 Issue Type: Improvement Components: Reactor and workspace Affects Versions: 2.0.4 Reporter: Binyan As seen here, http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. I also have the need to bind my maven-pde-plugin to a phase before the reactor sorting of project build order happens. My plugin is being developed to build eclipse plugins, features, fragments, update sites and products. Right now I can build plugins and features. However the order has to constantly be managed by the user taking information from the eclipse descriptors and adding it to the pom file. For plugin projects I can bind to a phase before the compile phase and dynamically analyze the eclipse plugin descriptors and add the necessary dependencies/resources to the MavenProject instance and all is well. For feature projects, I also can dynamically analyze the eclipse feature descriptor and add the necessary resources to the MavenProject instance. However, features depend on other plugins, fragments and features. While I can dynamicaly add the plugins, fragments and features to the MavenProject as dependencies they are not taken into context as the reactor has already computed the sorting order. What would be perfect is if there was a super-init phase that plugins could bind to and be executed in before the normal declared lifecycle happened. Therefore no matter what the lifecycle was, the super-init phase would be available. Then plugins could do things like augmenting the super-pom with build #'s/identifiers, dependencies, dynamic projects, etc all before maven gets going. That would solve the problem myself and others have as well as be 100% backwards compatible. This super-init phase (please pick a better name) would e available to reactor and non-reactor builds. A more specific fix would be to allow plugins to ask the reactor to reevaluate the build order. -- 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: (MSUREFIREREP-6) surefire-report reruns tests
[ http://jira.codehaus.org/browse/MSUREFIREREP-6?page=comments#action_74002 ] Peter Anning commented on MSUREFIREREP-6: - This is a big issue for us. We are migrating a large ant based project to Maven and have 1200 unit tests. If a test fails the only way to find which test has failed is to run the surefire-report:report goal this then re-runs all the tests, which takes a long time. Need a way to get this report plugin to only rerun tests if explicityly asked to. It should just compile a report on the results that are already there, if there are no individual test reports then exit without error. Also is there a way to get the surefire plugin to only create reports for tests that have failed. surefire-report reruns tests Key: MSUREFIREREP-6 URL: http://jira.codehaus.org/browse/MSUREFIREREP-6 Project: Maven 2.x Surefire report Plugin Issue Type: Bug Environment: maven 2.0 Reporter: Dirk Sturzebecher surefire-report reruns the tests. In my case this is not just annoying, but leads to a failure, as the VM (probably) is reused and leftovers from the first tests are (definitly) still present. I run maven with: clean package site -- 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] Closed: (MRM-129) flush the index periodically during rebuild
[ http://jira.codehaus.org/browse/MRM-129?page=all ] Brett Porter closed MRM-129. Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: 1.0-beta-1) this isn't necessary after the refactoring, and a better solution will be to allow some parallelism in the indexing process, which a new issue will be opened for. flush the index periodically during rebuild --- Key: MRM-129 URL: http://jira.codehaus.org/browse/MRM-129 Project: Archiva Issue Type: Improvement Components: indexing Reporter: Brett Porter Assigned To: Brett Porter currently, the indexing can take some time when it is done from scratch on a large repository, and requires a large amount of memory. It would be good to periodically checkpoint the index with a set of artifacts already completed. How this affects the timestamp used needs to be interpreted, as if the indexing is stopped it may want to avoid reindexing those already done. Perhaps an alternative is to sort the discovered artifacts by timestamp, and setting it to the most recent one done - this can be considered in conjunction with the current issue that synced artifacts sometimes are new but have a timestamp older than the last indexing time and so are not indexed. -- 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] Closed: (MRM-134) ability to update an existing index without relying on timestamp
[ http://jira.codehaus.org/browse/MRM-134?page=all ] Brett Porter closed MRM-134. Assignee: Brett Porter Resolution: Fixed done, though: - no timestamp checking at present (can be added in a later iteration, but should be unnecessary for basic purposes as indexed files shouldn't be updated) - no deletion (this will be addressed by the separate JIRA issue for it) ability to update an existing index without relying on timestamp Key: MRM-134 URL: http://jira.codehaus.org/browse/MRM-134 Project: Archiva Issue Type: Improvement Components: indexing Reporter: Brett Porter Assigned To: Brett Porter Fix For: 1.0-beta-1 due to the possibility that timestamps can get out of sync, it should be possible to update an index without relying on these in a performant way (ie, not rebuilding from scratch). for example, compare the artifact timestamp to the target location before deciding if an addition/update is needed and reading the JAR (possibly the slowest part of indexing - should confirm what % it takes) this will also need to process deletions (which may not be handled in the normal indexing, depending on how that is implemented for discovery) -- 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] Closed: (MRM-133) discovery might not find artifacts added as a result of rsync
[ http://jira.codehaus.org/browse/MRM-133?page=all ] Brett Porter closed MRM-133. Resolution: Duplicate Fix Version/s: (was: 1.0-beta-1) discovery might not find artifacts added as a result of rsync - Key: MRM-133 URL: http://jira.codehaus.org/browse/MRM-133 Project: Archiva Issue Type: Bug Components: discovery Reporter: Brett Porter Assigned To: Brett Porter currently, the last discovered timestamp for an operation is set to the current time. There are two problems with that: - artifacts added in the last minute are not discovered, and because of this setting never will be - artifacts added with timestamps in the past (eg, using rsync) will never be discovered. For the first, the time recorded can simply be set in the past. However, for the second another alternative needs to be found (whether it be querying the target to check if it already exists or not rather than a single timestamp, or some other solution) -- 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: (ARCHETYPE-53) No longer possible to place non-Java resources into package structure
No longer possible to place non-Java resources into package structure - Key: ARCHETYPE-53 URL: http://jira.codehaus.org/browse/ARCHETYPE-53 Project: Maven Archetype Issue Type: Bug Reporter: Wendy Smoak From a thread on [EMAIL PROTECTED] This used to work, and I could put (for example) .properties files into src/main/resources/org/example/myapp/Bundle.properties . On 9/3/06, tm jee [EMAIL PROTECTED] wrote: Is there a way allow resource generated by maven archetype to change dynamically. ... The files under the generated resources directory seems to be static. It doesn't seems to change accordingly with the -DgroupId argument passed in. Is there a way to configured it to change according to the groupId? Apparently not. In a prior version of Maven Archetype, you could put non-Java files in the sources section, and it would put them in the proper package structure. There are some notes in the Shale Blank archetype.xml file [1]. !-- The next line causes an error with 'mvn archetype:create': Embedded error: Template 'src/main/resources/Bundle.properties' not in directory 'src/main/java' -- !--sourcesrc/main/resources/Bundle.properties/source-- ... !-- See above, but here, Bundle.properties does not get placed in the package structure -- resourcesrc/main/resources/Bundle.properties/resource [1] http://svn.apache.org/repos/asf/shale/maven/trunk/archetypes/shale-archetype-blank/src/main/resources/META-INF/archetype.xml -- 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: (ARCHETYPE-54) Dynamic archetype resource
Dynamic archetype resource -- Key: ARCHETYPE-54 URL: http://jira.codehaus.org/browse/ARCHETYPE-54 Project: Maven Archetype Issue Type: Improvement Components: Archetypes Reporter: tm_jee It would be nice if the following could be done eg. mvn archetype:create -DgroupId=com.myComp -DartifactId=myApp -DarchetypeGroupId= -DarchetypeArtifactId= with META-INF/archetype.xml sources sourcesrc/main/java/HelloWorldAction.java/source /sources resources resourcesrc/main/resources/someProperty.properties/resource /resources The generated template will have src/main/java/com/myComp/HelloWorldAction.java src/main/resources/someProperty.properties A nice improvement would be to be able to allow (selectively) eg. someProperty.properties to be package aware as well, maybe with resources resource packageAware=truesrc/main/resources/someProperty.properties/resource /resources someProperty.properties coudl be generated at src/main/resources/com/myComp/someProperty.properties -- 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
