[jira] (SUREFIRE-514) Provide a way to skip a project's tests if nothing has changed
[ https://jira.codehaus.org/browse/SUREFIRE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356173#comment-356173 ] Dan Fabulich commented on SUREFIRE-514: --- I don't think I understand your comment. 1) I agree that it's not necessarily safe to run tests incrementally; I mentioned this myself when I filed the bug. So I guess it's OK not to make it the default (though we would probably opt-in to this behavior in our projects). 2) It's better for us not to introduce a new configuration parameter at the moment. Do you mean that it would be better to fix this bug later? It's been open for six years. Or do you mean that this is a bad feature that should never be done? 3) So if you don't necessarily require this feature in SUREFIRE 2.x and 3.0 anymore, we can close it. This is a performance feature. When does anyone require a performance feature? You can always live without it; it's just slower. But my point stands: just because it isn't guaranteed to be safe doesn't mean that it's a bad feature; it could substantially improve performance on developer boxes when/where we turn it on. If this feature shipped tomorrow, we would want it and would use it. Provide a way to skip a project's tests if nothing has changed -- Key: SUREFIRE-514 URL: https://jira.codehaus.org/browse/SUREFIRE-514 Project: Maven Surefire Issue Type: New Feature Components: Maven Surefire Plugin Reporter: Dan Fabulich Surefire should have an incremental mode, perhaps enabled by default. We should check the timestamps of every element of the classpath (and every class in any classpath folder) and touch a file in target with that timestamp. If none of those files have been updated, skip tests for the current project. It definitely needs to be possible to turn this feature off, though, because sometimes you need to re-run tests based on external resources not on the classpath: deployed web servers, database schema changes, etc. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1041) JUnit47 provider: Exception in JUnit Runner can crash test run without visible stack trace
[
https://jira.codehaus.org/browse/SUREFIRE-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich updated SUREFIRE-1041:
---
Attachment: SUREFIRE-1041.patch
JUnit47 provider: Exception in JUnit Runner can crash test run without
visible stack trace
--
Key: SUREFIRE-1041
URL: https://jira.codehaus.org/browse/SUREFIRE-1041
Project: Maven Surefire
Issue Type: Bug
Reporter: Dan Fabulich
Attachments: SUREFIRE-1041.patch
Run the attached Maven project. Surefire is configured to use the JUnit47
provider. There's one test, marked with @RunWith(BadRunner.class); the
BadRunner class throws a NullPointerException in its run method.
Expected: The tests should fail with a visible stacktrace; that's what
happens when you don't use the JUnit47 provider.
Actual: The tests fail with this unhelpful error:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on
project test: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.16:test failed:
java.lang.RuntimeException: null,null,null,null,null: source is null - [Help
1]
{code}
I'm also attaching a patch that fixes this problem: SimpleReportEntry should
not throw a NPE with a null source/name, but should instead just accept them
and convert them to the string null. This allows the test to fail naturally
and render the stacktrace in the console output and in surefire reports.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1041) JUnit47 provider: Exception in JUnit Runner can crash test run without visible stack trace
Dan Fabulich created SUREFIRE-1041:
--
Summary: JUnit47 provider: Exception in JUnit Runner can crash
test run without visible stack trace
Key: SUREFIRE-1041
URL: https://jira.codehaus.org/browse/SUREFIRE-1041
Project: Maven Surefire
Issue Type: Bug
Reporter: Dan Fabulich
Attachments: SUREFIRE-1041.patch
Run the attached Maven project. Surefire is configured to use the JUnit47
provider. There's one test, marked with @RunWith(BadRunner.class); the
BadRunner class throws a NullPointerException in its run method.
Expected: The tests should fail with a visible stacktrace; that's what happens
when you don't use the JUnit47 provider.
Actual: The tests fail with this unhelpful error:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on
project test: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.16:test failed:
java.lang.RuntimeException: null,null,null,null,null: source is null - [Help 1]
{code}
I'm also attaching a patch that fixes this problem: SimpleReportEntry should
not throw a NPE with a null source/name, but should instead just accept them
and convert them to the string null. This allows the test to fail naturally
and render the stacktrace in the console output and in surefire reports.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1041) JUnit47 provider: Exception in JUnit Runner can crash test run without visible stack trace
[
https://jira.codehaus.org/browse/SUREFIRE-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich updated SUREFIRE-1041:
---
Attachment: SUREFIRE-1041-testcase.zip
JUnit47 provider: Exception in JUnit Runner can crash test run without
visible stack trace
--
Key: SUREFIRE-1041
URL: https://jira.codehaus.org/browse/SUREFIRE-1041
Project: Maven Surefire
Issue Type: Bug
Reporter: Dan Fabulich
Attachments: SUREFIRE-1041.patch, SUREFIRE-1041-testcase.zip
Run the attached Maven project. Surefire is configured to use the JUnit47
provider. There's one test, marked with @RunWith(BadRunner.class); the
BadRunner class throws a NullPointerException in its run method.
Expected: The tests should fail with a visible stacktrace; that's what
happens when you don't use the JUnit47 provider.
Actual: The tests fail with this unhelpful error:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on
project test: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.16:test failed:
java.lang.RuntimeException: null,null,null,null,null: source is null - [Help
1]
{code}
I'm also attaching a patch that fixes this problem: SimpleReportEntry should
not throw a NPE with a null source/name, but should instead just accept them
and convert them to the string null. This allows the test to fail naturally
and render the stacktrace in the console output and in surefire reports.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1041) JUnit47 provider: Exception in JUnit Runner can crash test run without visible stack trace
[
https://jira.codehaus.org/browse/SUREFIRE-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=335641#comment-335641
]
Dan Fabulich commented on SUREFIRE-1041:
This came up when we encountered this PowerMock bug
https://code.google.com/p/powermock/issues/detail?id=414 It should have just
failed, but instead it crashed the Surefire test reporter.
JUnit47 provider: Exception in JUnit Runner can crash test run without
visible stack trace
--
Key: SUREFIRE-1041
URL: https://jira.codehaus.org/browse/SUREFIRE-1041
Project: Maven Surefire
Issue Type: Bug
Reporter: Dan Fabulich
Attachments: SUREFIRE-1041.patch, SUREFIRE-1041-testcase.zip
Run the attached Maven project. Surefire is configured to use the JUnit47
provider. There's one test, marked with @RunWith(BadRunner.class); the
BadRunner class throws a NullPointerException in its run method.
Expected: The tests should fail with a visible stacktrace; that's what
happens when you don't use the JUnit47 provider.
Actual: The tests fail with this unhelpful error:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on
project test: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.16:test failed:
java.lang.RuntimeException: null,null,null,null,null: source is null - [Help
1]
{code}
I'm also attaching a patch that fixes this problem: SimpleReportEntry should
not throw a NPE with a null source/name, but should instead just accept them
and convert them to the string null. This allows the test to fail naturally
and render the stacktrace in the console output and in surefire reports.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-8) Shade plugin will cheerfully relocate your own classes
[ https://jira.codehaus.org/browse/MSHADE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272199#comment-272199 ] Dan Fabulich commented on MSHADE-8: --- I filed this issue and I agree that it's an enhancement, but I don't think it should just be closed out. Relocation patterns are very difficult to debug properly; a little more sanity checking would make Shade a lot more useable. Shade plugin will cheerfully relocate your own classes -- Key: MSHADE-8 URL: https://jira.codehaus.org/browse/MSHADE-8 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.0-alpha-15 Reporter: Dan Fabulich My relocation patterns were initially too relaxed, and so they wound up relocating my own classes, rather than just the classes I depend on. I could imagine somebody wanting to do this, but I think there should probably be a safety check or something to try to help you not do it by accident; it's probably not what you want. (After all, if you wanted your code to be in a different package, wouldn't you have just written it that way to begin with?) In my case I was working on a Maven plugin; when its classes got relocated, it broke the plugin metadata... definitely not what I wanted. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-595) Add surefire:force-test mojo to postpone tests
[ http://jira.codehaus.org/browse/SUREFIRE-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=205848#action_205848 ] Dan Fabulich commented on SUREFIRE-595: --- Note that this is also useful in single-threaded builds; in many cases running the build like this will help the build to discover compile failures faster than the standard lifecycle. (Of course, in single-threaded mode it discovers test failures slower, so there's a trade-off there.) Add surefire:force-test mojo to postpone tests -- Key: SUREFIRE-595 URL: http://jira.codehaus.org/browse/SUREFIRE-595 Project: Maven Surefire Issue Type: New Feature Reporter: Dan Fabulich The standard lifecycle does all testing before installing artifacts in the local repository. When running our experimental concurrent Maven, we find that doing compiling/packaging/installing before testing can promote better concurrency. It would be helpful to have a surefire:force-test mojo, which simply extends the standard mojo but ignores the -DskipTests and -Dmaven.test.skip properties. That way, you could run the build like this: mvn install -DskipTests surefire:force-test The tests would be skipped during the install lifecycle, and then run separately at the end of the build. -- 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-595) Add surefire:force-test mojo to postpone tests
[ http://jira.codehaus.org/browse/SUREFIRE-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-595: -- Comment: was deleted (was: Note that this is also useful in single-threaded builds; in many cases running the build like this will help the build to discover compile failures faster than the standard lifecycle. (Of course, in single-threaded mode it discovers test failures slower, so there's a trade-off there.)) Add surefire:force-test mojo to postpone tests -- Key: SUREFIRE-595 URL: http://jira.codehaus.org/browse/SUREFIRE-595 Project: Maven Surefire Issue Type: New Feature Reporter: Dan Fabulich The standard lifecycle does all testing before installing artifacts in the local repository. When running our experimental concurrent Maven, we find that doing compiling/packaging/installing before testing can promote better concurrency. It would be helpful to have a surefire:force-test mojo, which simply extends the standard mojo but ignores the -DskipTests and -Dmaven.test.skip properties. That way, you could run the build like this: mvn install -DskipTests surefire:force-test The tests would be skipped during the install lifecycle, and then run separately at the end of the build. -- 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: (MARTIFACT-19) DefaultArtifactInstaller should only overwrite files if timestamp has changed
[ http://jira.codehaus.org/browse/MARTIFACT-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MARTIFACT-19. - Resolution: Fixed Fix Version/s: 3.0 Fixed in r808537 in 3.0 trunk and r808535 in 2.2.x. DefaultArtifactInstaller should only overwrite files if timestamp has changed - Key: MARTIFACT-19 URL: http://jira.codehaus.org/browse/MARTIFACT-19 Project: Maven Artifact Issue Type: Improvement Environment: Linux, JDK 1.5 Reporter: Johannes Martin Fix For: 3.0 install:install (from maven-install-plugin) by default uses DefaultArtifactInstaller to install artifacts. DefaultArtifactInstaller in turn uses FileUtils.copyFile(), thereby overwriting destination files even if they are unchanged. It would be helpful if DefaultArtifactInstaller used FileUtils.copyFileIfModified() instead, at least as an option, to speed up the build process. -- 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-2502) TestNG 5.9
TestNG 5.9 -- Key: MAVENUPLOAD-2502 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2502 Project: Maven Upload Requests Issue Type: Wish Reporter: Dan Fabulich Attachments: testng-5.9-bundle.jar TestNG 5.9. I'm a developer of TestNG (DanFabulich) -- 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: (MNG-2576) Make Like Reactor Mode
[
http://jira.codehaus.org/browse/MNG-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=176980#action_176980
]
Dan Fabulich commented on MNG-2576:
---
Joerg,
A , is not a /.
foo,bar is for directory structures that look like this:
{code}
myroot
|
+-- foo
+-- bar
+-- quz
{code}
Normally mvn install from myroot would build all three subdirectories
(foo bar quz). But mvn -pl foo,quz would build just foo and quz.
So you ask what am I missing? You're missing the --also-make directive.
If you want to build foo and everything foo depends on, you'd write: mvn
-pl foo -am. If you want to build foo and quz and everything they depend on,
then you'd write mvn -pl foo,quz -am. If bar were a subdirectory of foo, you
could write mvn -pl foo/bar -am.
I hope that helps. I'll try to put together a blog article about this in the
hope that anyone could actually figure it out. :-)
Make Like Reactor Mode
--
Key: MNG-2576
URL: http://jira.codehaus.org/browse/MNG-2576
Project: Maven 2
Issue Type: New Feature
Components: Command Line, Reactor and workspace
Reporter: Kenney Westerhof
Assignee: Dan Fabulich
Fix For: 2.1.0-M1
Add a commandline option to enable maven to expand the reactor scope to find
projects that are dependencies
of the projects currently in the reactor, and add them.
Currently only the current project and child projects are included in the
reactor search. I'm proposing
to add a commandline switch that lets maven check parent directories to find
the root of the project tree,
and then do a normal reactor scan, only adding projects that would normally
not be added if they're needed
as dependencies of the projects that would normally be built.
Here's a sample project tree:
* root
** p1
*** c1 (depends on p2)
** p2 (depends on c2)
** p3
*** c2
And a sample algorithm:
- When building c1, the reactor would contain [c1].
- Maven would check p1, then root, etc, using the parent tags (without the
versions!)
to see if the project is still in the current reactor.
- It would then create a second list of projects (reactor2) containing ALL
projects, using the newly discovered root: [root, p1, c2, p2].
- remove all projects from reactor2 contained in reactor: reactor2 = [root,
p1, p2]
- resolve all direct dependencies for all projects in reactor in reactor2 and
add them to reactor, taking versions into account: reactor = [p2, c1]
- repeat previous step until all projects have their dependencies resolved
from reactor 2. first iteration would yield reactor = [c2, p2, c1],
next iteration would stop since c1 doesn't have any dependencies present in
reactor2.
This would ensure that when some local project's sources have changed,
they'll be incorporated
in the build, regardless of where you build. So you don't have to do a
reactor build each time you change more
than 1 project, and you don't have to remember which projects you changed and
build them in the correct order
yourself, manually.
--
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: (MNG-2576) Make Like Reactor Mode
[ http://jira.codehaus.org/browse/MNG-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=176805#action_176805 ] Dan Fabulich commented on MNG-2576: --- It's not -r you want. -r is when you have a directory full of subdirectories, each of which is a project. I won't explain -r, because it makes very little sense. :-) Instead, I'm going to compare the new feature to an old feature. This may confuse you, because it may make you accidentally use the old feature instead of the new feature. Before this bug MNG-2576 was fixed, you had to use the Maven Reactor Plugin. http://maven.apache.org/plugins/maven-reactor-plugin/ Now, you can use --project-list, --also-make, --also-make-dependents, and --resume-from to get a similar effect. Here's a table of old commands and their new Maven 2.1 commands. 1) mvn reactor:resume -Dfrom=bar is now mvn --resume-from bar 2) mvn reactor:make -Dmake.folders=foo,bar is now mvn --project-list foo,bar --also-make 3) mvn reactor:make-dependents -Dmake.folders=foo,bar is now mvn --project-list foo,bar --also-make-dependents Make-like functionality is complicated; read the documentation for maven-reactor-plugin for more details. Make Like Reactor Mode -- Key: MNG-2576 URL: http://jira.codehaus.org/browse/MNG-2576 Project: Maven 2 Issue Type: New Feature Components: Command Line, Reactor and workspace Reporter: Kenney Westerhof Assignee: Dan Fabulich Fix For: 2.1.0-M1 Add a commandline option to enable maven to expand the reactor scope to find projects that are dependencies of the projects currently in the reactor, and add them. Currently only the current project and child projects are included in the reactor search. I'm proposing to add a commandline switch that lets maven check parent directories to find the root of the project tree, and then do a normal reactor scan, only adding projects that would normally not be added if they're needed as dependencies of the projects that would normally be built. Here's a sample project tree: * root ** p1 *** c1 (depends on p2) ** p2 (depends on c2) ** p3 *** c2 And a sample algorithm: - When building c1, the reactor would contain [c1]. - Maven would check p1, then root, etc, using the parent tags (without the versions!) to see if the project is still in the current reactor. - It would then create a second list of projects (reactor2) containing ALL projects, using the newly discovered root: [root, p1, c2, p2]. - remove all projects from reactor2 contained in reactor: reactor2 = [root, p1, p2] - resolve all direct dependencies for all projects in reactor in reactor2 and add them to reactor, taking versions into account: reactor = [p2, c1] - repeat previous step until all projects have their dependencies resolved from reactor 2. first iteration would yield reactor = [c2, p2, c1], next iteration would stop since c1 doesn't have any dependencies present in reactor2. This would ensure that when some local project's sources have changed, they'll be incorporated in the build, regardless of where you build. So you don't have to do a reactor build each time you change more than 1 project, and you don't have to remember which projects you changed and build them in the correct order yourself, manually. -- 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: (MNG-4100) Add maven-help-plugin to super pom
[ http://jira.codehaus.org/browse/MNG-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MNG-4100. - Resolution: Won't Fix ok, you've convinced me. (for the record I tried -cpu instead of -U, which may have been the cause of some evil) Add maven-help-plugin to super pom -- Key: MNG-4100 URL: http://jira.codehaus.org/browse/MNG-4100 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Dan Fabulich A number of users where I work have recently upgraded to Maven 2.1, but when they try to run the maven help plugin they're still on the old 2.0.2 version. Some local repo weirdness, clearing stuff out takes care of it, but it's not what you want when people are trying to get help. We should add the maven-help-plugin to the super pom, and update it when new versions of the help plugin are released. -- 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-4100) Add maven-help-plugin to super pom
Add maven-help-plugin to super pom -- Key: MNG-4100 URL: http://jira.codehaus.org/browse/MNG-4100 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Dan Fabulich A number of users where I work have recently upgraded to Maven 2.1, but when they try to run the maven help plugin they're still on the old 2.0.2 version. Some local repo weirdness, clearing stuff out takes care of it, but it's not what you want when people are trying to get help. We should add the maven-help-plugin to the super pom, and update it when new versions of the help plugin are released. -- 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: (MENFORCER-64) Fail the build if children in a reactor don't declare a parent
[ http://jira.codehaus.org/browse/MENFORCER-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=166757#action_166757 ] Dan Fabulich commented on MENFORCER-64: --- I'd pay that price of consistency. In the project I was working on last week, one of the reactor projects failed to declare its parent properly, and so it dodged around the enforcer entirely. The fact that it *consistently* avoided all rules (both when run independently and when run in a reactor) was no comfort! It might help to phrase it this way: normally enforcer rules apply directly to the individual leaf projects in a reactor, but this rule would probably apply to the reactor root itself. The *parent* would assert that its reactor modules were children. Hence it makes sense that the children themselves can run independently: they're not asserting anything. Fail the build if children in a reactor don't declare a parent -- Key: MENFORCER-64 URL: http://jira.codehaus.org/browse/MENFORCER-64 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Reporter: Dan Fabulich Children in a reactor build are allowed to declare any parent POM they like, or no POM at all. It should be possible to fail the build if a child declares the wrong parent pom (which should normally be the root of the reactor, but may be configured to be something else). -- 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: (MENFORCER-65) Fail the build if children declare dependency versions
[ http://jira.codehaus.org/browse/MENFORCER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=166815#action_166815 ] Dan Fabulich commented on MENFORCER-65: --- What you described, if the parent has a version, don't allow a child to override it is MENFORCER-19. I really do want the draconian version. FWIW, I don't see it as particularly draconian, we just want all of our version numbers to be in one file; developers who put version numbers in child nodes are typically just ignorant of the policy. By failing the build we can be sure that developers don't violate the policy by accident. It's sort of an automated educational tool. :-) Fail the build if children declare dependency versions -- Key: MENFORCER-65 URL: http://jira.codehaus.org/browse/MENFORCER-65 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Reporter: Dan Fabulich The opposite side of MENFORCER-19, it should be possible to require that children in a reactor NEVER declare any versions, but inherit all dependency versions from the parent's dependencyManagement. That is, if the parent fails to declare a certain dependency X, the child shouldn't be free to choose just any version; the child should have to add the dependency to the parent and then use the version declared there. -- 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: (MENFORCER-63) Fail the build on reactor dependency divergence
Fail the build on reactor dependency divergence --- Key: MENFORCER-63 URL: http://jira.codehaus.org/browse/MENFORCER-63 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Reporter: Dan Fabulich The maven-project-info-reports-plugin provides a dependency convergence report that guarantees that siblings under a reactor use the same versions. Maven enforcer should be able to fail the build if the dependencies don't converge. This is different from MENFORCER-19, which is tracked by analyze-dep-mgt, because it will only track differences between a parent's dependencyManagement section and the child's dependency section, not between siblings. So if the parent neglects to declare a dependency X in dependencyManagement, but one child uses X 1.0 and another child uses X 2.0, the dependency convergence report will catch it, but analyze-dep-mgt will not. -- 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: (MENFORCER-64) Fail the build if children in a reactor don't declare a parent
Fail the build if children in a reactor don't declare a parent -- Key: MENFORCER-64 URL: http://jira.codehaus.org/browse/MENFORCER-64 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Reporter: Dan Fabulich Children in a reactor build are allowed to declare any parent POM they like, or no POM at all. It should be possible to fail the build if a child declares the wrong parent pom (which should normally be the root of the reactor, but may be configured to be something else). -- 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: (MENFORCER-65) Fail the build if children declare dependency versions
Fail the build if children declare dependency versions -- Key: MENFORCER-65 URL: http://jira.codehaus.org/browse/MENFORCER-65 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Reporter: Dan Fabulich The opposite side of MENFORCER-19, it should be possible to require that children in a reactor NEVER declare any versions, but inherit all dependency versions from the parent's dependencyManagement. That is, if the parent fails to declare a certain dependency X, the child shouldn't be free to choose just any version; the child should have to add the dependency to the parent and then use the version declared there. -- 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: (MREACTOR-10) Parameters are not passed through
[
http://jira.codehaus.org/browse/MREACTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed MREACTOR-10.
Resolution: Not A Bug
This is documented. You have to do this:
-Dmake.goals=-Dmaven.test.skip.true,install. As far as I know there's nothing
else we can do here. :-(
Parameters are not passed through
-
Key: MREACTOR-10
URL: http://jira.codehaus.org/browse/MREACTOR-10
Project: Maven 2.x Reactor Plugin
Issue Type: Bug
Affects Versions: 1.0
Environment: Windows XP. Maven 2.1.0-M1
Reporter: Henri Tremblay
Priority: Blocker
Parameters passed to maven in the -M form are not propogated to the inner
call to maven.
For instance:
{{mvn.bat reactor:make -Dmaven.test.skip=true
-Dmake.folders=java/utils/commons -Pjava,deploy}}
will launch the following call:
{{mvn.bat -B -N -r -D
maven.reactor.includes=java\pom.xml,java\tests\ut\pom.xml,java\utils\commons\pom.xml
install}}
As you can see, the maven.test.skip has disappear and so the tests are ran...
Which in this case prevents me from using the 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: (MREACTOR-9) Embedded error: roots differ error on simple project
[
http://jira.codehaus.org/browse/MREACTOR-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=149413#action_149413
]
Dan Fabulich commented on MREACTOR-9:
-
Yes, it seems very likely that cygwin is causing the problem. The plain DOS
results (Cannot execute mojo: resources) are what I see on my machine also,
and is what I would expect due to MREACTOR-1. I'll try to repro the problem on
cygwin.
Embedded error: roots differ error on simple project
Key: MREACTOR-9
URL: http://jira.codehaus.org/browse/MREACTOR-9
Project: Maven 2.x Reactor Plugin
Issue Type: Bug
Affects Versions: 1.0
Environment: cygwin
Reporter: Jorg Heymans
Attachments: reactor-bug.tar.gz
Unpack the attached project, go to the root-pom directory and do mvn
reactor:make -Dmake.artifacts=B-api :
{code}
$ mvn reactor:make -Dmake.artifacts=B-api
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] myProject
[INFO] A api
[INFO] A impl
[INFO] A-modules
[INFO] B api
[INFO] B impl
[INFO] B-modules
[INFO] myProject-modules
[INFO] Searching repository for plugin with prefix: 'reactor'.
[INFO]
[INFO] Building myProject
[INFO]task-segment: [reactor:make] (aggregator-style)
[INFO]
[INFO] [reactor:make]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Problem generating dependency tree
Embedded error: Roots differ
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 3 seconds
[INFO] Finished at: Tue Sep 30 09:18:16 CEST 2008
[INFO] Final Memory: 7M/13M
[INFO]
{code}
or go to the modules directory and do make.folders=B/api :
{code}
$ mvn reactor:make -Dmake.folders=B/api
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] A api
[INFO] A impl
[INFO] A-modules
[INFO] B api
[INFO] B impl
[INFO] B-modules
[INFO] myProject-modules
[INFO] Searching repository for plugin with prefix: 'reactor'.
[INFO]
[INFO] Building myProject-modules
[INFO]task-segment: [reactor:make] (aggregator-style)
[INFO]
[INFO] [reactor:make]
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] No folders matched: B/api
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 4 seconds
[INFO] Finished at: Tue Sep 30 09:16:14 CEST 2008
[INFO] Final Memory: 7M/14M
[INFO]
{code}
--
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: (MREACTOR-1) Reactor plugin doesn't work with sibling aggregated modules
[
http://jira.codehaus.org/browse/MREACTOR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=149295#action_149295
]
Dan Fabulich commented on MREACTOR-1:
-
Alternately, we could just try to launch Maven from the highest common
directory...? There may or may not be any POM in that location, but it should
still work, I think...?
Reactor plugin doesn't work with sibling aggregated modules
---
Key: MREACTOR-1
URL: http://jira.codehaus.org/browse/MREACTOR-1
Project: Maven 2.x Reactor Plugin
Issue Type: Bug
Affects Versions: Future
Reporter: Dan Fabulich
Fix For: Future
Normally when you have an aggregator POM with a list of modules, the
element lists out subdirectories of the aggregator, like this:
{code}
modules
modulefoo/module
modulebar/module
/modules
{code}
But modules can be anywhere; the module list can declare relative paths to
anywhere, like this:
{code}
modules
module../foo/module
module../../bar/module
/modules
{code}
Since the reactor plugin currently works by using mvn --reactor, which only
accepts subdirectories, it will silently fail to run these sibling modules.
Ultimately we should fix this by using the new command line switches
available in 2.1.
http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode In the
meantime, we'll have to live with it. (Possibly include a warning? error?)
--
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: (MREACTOR-8) reactor:resume -DfromArtifact fails
[
http://jira.codehaus.org/browse/MREACTOR-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich updated MREACTOR-8:
Affects Version/s: 1.0
Fix Version/s: 1.1
reactor:resume -DfromArtifact fails
---
Key: MREACTOR-8
URL: http://jira.codehaus.org/browse/MREACTOR-8
Project: Maven 2.x Reactor Plugin
Issue Type: Bug
Affects Versions: 1.0
Reporter: Dan Fabulich
Fix For: 1.1
Run mvn reactor:resume -DfromArtifact=foo. The build will fail:
{code}
You can't specify both a folder (/home/dfabulich/svn/myproj/trunk/null) and
an artifact (foo)
{code}
--
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: (MREACTOR-8) reactor:resume -DfromArtifact fails
reactor:resume -DfromArtifact fails
---
Key: MREACTOR-8
URL: http://jira.codehaus.org/browse/MREACTOR-8
Project: Maven 2.x Reactor Plugin
Issue Type: Bug
Reporter: Dan Fabulich
Fix For: 1.1
Run mvn reactor:resume -DfromArtifact=foo. The build will fail:
{code}
You can't specify both a folder (/home/dfabulich/svn/myproj/trunk/null) and an
artifact (foo)
{code}
--
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: (MREACTOR-8) reactor:resume -DfromArtifact fails
[
http://jira.codehaus.org/browse/MREACTOR-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed MREACTOR-8.
---
Resolution: Fixed
Fixed in revision 700257.
reactor:resume -DfromArtifact fails
---
Key: MREACTOR-8
URL: http://jira.codehaus.org/browse/MREACTOR-8
Project: Maven 2.x Reactor Plugin
Issue Type: Bug
Affects Versions: 1.0
Reporter: Dan Fabulich
Fix For: 1.1
Run mvn reactor:resume -DfromArtifact=foo. The build will fail:
{code}
You can't specify both a folder (/home/dfabulich/svn/myproj/trunk/null) and
an artifact (foo)
{code}
--
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: (MREACTOR-7) reactor:resume can run projects in the wrong order
[
http://jira.codehaus.org/browse/MREACTOR-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich updated MREACTOR-7:
Fix Version/s: Future
reactor:resume can run projects in the wrong order
--
Key: MREACTOR-7
URL: http://jira.codehaus.org/browse/MREACTOR-7
Project: Maven 2.x Reactor Plugin
Issue Type: Bug
Affects Versions: 1.0
Reporter: Dan Fabulich
Fix For: Future
reactor:resume works by passing a list of includes to mvn, like this: mvn
--reactor -D maven.reactor.includes=foo/pom.xml,bar/pom.xml,baz/pom.xml.
However, unlike a temporary POM file which guarantees a stable ordering,
reactor.includes is just an include list; Maven can run the projects in any
order it likes. By default, this is the order in which directories are
discovered on the filesystem; this is typically alphabetically ordered.
So if you've got three independent modules in your POM like this:
{code}
modules
moduleOne/module
moduleTwo/module
moduleThree/module
/modules
{code}
and you try to resume from Two (skipping One), we'll run mvn -reactor -D
maven.reactor.includes=Two/pom.xml,Three/pom.xml. But when Maven discovers
these directories in alphabetical order, it will run Three first and then Two
(because Three comes before Two in alphabetical ordering).
The workaround is to make sure that your module list in your POM is the same
order that Maven will discover the files on the filesystem, i.e. in
alphabetical 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] Closed: (MREACTOR-6) Be able to build a given project
[
http://jira.codehaus.org/browse/MREACTOR-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed MREACTOR-6.
---
Resolution: Won't Fix
Actually, it's even easier than that... Maven already has a way to do what you
want:
{code}
mvn -f my/project/pom.xml
{code}
I use it all the time; it's pretty handy!
Be able to build a given project
Key: MREACTOR-6
URL: http://jira.codehaus.org/browse/MREACTOR-6
Project: Maven 2.x Reactor Plugin
Issue Type: New Feature
Affects Versions: 1.0
Reporter: Henri Tremblay
A lots of times, I found myself doing all over the directory tree of my
project to build a given project. It would be really useful to be able to
build it from my parent directory.
I'm not aware of a way to do so right now and I think the reactor plugin
could be the right place.
Something like:
mvn reactor:build -Dproject=my/project
Which would do a little bit like reactor:resume but building only one 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] Created: (MREACTOR-5) Can't resume a make build
Can't resume a make build - Key: MREACTOR-5 URL: http://jira.codehaus.org/browse/MREACTOR-5 Project: Maven 2.x Reactor Plugin Issue Type: New Feature Reporter: Dan Fabulich If you run reactor:make, it will launch mvn with -r, using a specific set of include files. If you want to resume a reactor:make from the middle, you can't, even with -Dmake.goals=reactor:resume, because that would just run reactor:resume on every sub-project. Instead, reactor:make should accept -Dfrom and -DfromArtifact just like reactor:resume. -- 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: (MREACTOR-5) Can't resume a make build
[ http://jira.codehaus.org/browse/MREACTOR-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MREACTOR-5. --- Resolution: Fixed Fix Version/s: 1.0 Fixed revision 698326 Can't resume a make build - Key: MREACTOR-5 URL: http://jira.codehaus.org/browse/MREACTOR-5 Project: Maven 2.x Reactor Plugin Issue Type: New Feature Reporter: Dan Fabulich Fix For: 1.0 If you run reactor:make, it will launch mvn with -r, using a specific set of include files. If you want to resume a reactor:make from the middle, you can't, even with -Dmake.goals=reactor:resume, because that would just run reactor:resume on every sub-project. Instead, reactor:make should accept -Dfrom and -DfromArtifact just like reactor:resume. -- 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: (MREACTOR-1) Reactor plugin doesn't work with sibling aggregated modules
Reactor plugin doesn't work with sibling aggregated modules
---
Key: MREACTOR-1
URL: http://jira.codehaus.org/browse/MREACTOR-1
Project: Maven 2.x Reactor Plugin
Issue Type: Bug
Affects Versions: Future
Reporter: Dan Fabulich
Normally when you have an aggregator POM with a list of modules, the element
lists out subdirectories of the aggregator, like this:
{code}
modules
modulefoo/module
modulebar/module
/modules
{code}
But modules can be anywhere; the module list can declare relative paths to
anywhere, like this:
{code}
modules
module../foo/module
module../../bar/module
/modules
{code}
Since the reactor plugin currently works by using mvn --reactor, which only
accepts subdirectories, it will silently fail to run these sibling modules.
Ultimately we should fix this by using the new command line switches available
in 2.1. http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode In the
meantime, we'll have to live with it. (Possibly include a warning? error?)
--
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: (MREACTOR-1) Reactor plugin doesn't work with sibling aggregated modules
[
http://jira.codehaus.org/browse/MREACTOR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148117#action_148117
]
Dan Fabulich commented on MREACTOR-1:
-
Alternately we could construct a temporary POM file with a list of modules in
it, execute the POM file and mark it to be deleted on exit...?
Reactor plugin doesn't work with sibling aggregated modules
---
Key: MREACTOR-1
URL: http://jira.codehaus.org/browse/MREACTOR-1
Project: Maven 2.x Reactor Plugin
Issue Type: Bug
Affects Versions: Future
Reporter: Dan Fabulich
Normally when you have an aggregator POM with a list of modules, the
element lists out subdirectories of the aggregator, like this:
{code}
modules
modulefoo/module
modulebar/module
/modules
{code}
But modules can be anywhere; the module list can declare relative paths to
anywhere, like this:
{code}
modules
module../foo/module
module../../bar/module
/modules
{code}
Since the reactor plugin currently works by using mvn --reactor, which only
accepts subdirectories, it will silently fail to run these sibling modules.
Ultimately we should fix this by using the new command line switches
available in 2.1.
http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode In the
meantime, we'll have to live with it. (Possibly include a warning? error?)
--
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: (MREACTOR-2) Make a reverse dependency tree
Make a reverse dependency tree -- Key: MREACTOR-2 URL: http://jira.codehaus.org/browse/MREACTOR-2 Project: Maven 2.x Reactor Plugin Issue Type: New Feature Reporter: Dan Fabulich mvn dependency:tree shows you all of the projects that the current project depends on, even if they aren't in the current reactor. This plugin (or the dependency plugin?) should generate a tree of projects that depend on you (within the current reactor). (Note that in 2.1 the ProjectSorter will expose its DAG, so at that point maybe the dependency plugin will be a better place for 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] Created: (MREACTOR-3) Integration tests
Integration tests - Key: MREACTOR-3 URL: http://jira.codehaus.org/browse/MREACTOR-3 Project: Maven 2.x Reactor Plugin Issue Type: Task Reporter: Dan Fabulich There should be integration tests for this 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: (MREACTOR-4) Basic unit test of make goal
Basic unit test of make goal Key: MREACTOR-4 URL: http://jira.codehaus.org/browse/MREACTOR-4 Project: Maven 2.x Reactor Plugin Issue Type: Task Reporter: Dan Fabulich Fix For: 1.0 There should be a basic unit test of the make goal. (This will require the ProjectSorter to be injected, I think... But how do I set that up?) -- 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: (MREACTOR-2) Make a reverse dependency tree
[ http://jira.codehaus.org/browse/MREACTOR-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated MREACTOR-2: Fix Version/s: Future Make a reverse dependency tree -- Key: MREACTOR-2 URL: http://jira.codehaus.org/browse/MREACTOR-2 Project: Maven 2.x Reactor Plugin Issue Type: New Feature Reporter: Dan Fabulich Fix For: Future mvn dependency:tree shows you all of the projects that the current project depends on, even if they aren't in the current reactor. This plugin (or the dependency plugin?) should generate a tree of projects that depend on you (within the current reactor). (Note that in 2.1 the ProjectSorter will expose its DAG, so at that point maybe the dependency plugin will be a better place for 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] Updated: (MREACTOR-1) Reactor plugin doesn't work with sibling aggregated modules
[
http://jira.codehaus.org/browse/MREACTOR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich updated MREACTOR-1:
Fix Version/s: Future
Reactor plugin doesn't work with sibling aggregated modules
---
Key: MREACTOR-1
URL: http://jira.codehaus.org/browse/MREACTOR-1
Project: Maven 2.x Reactor Plugin
Issue Type: Bug
Affects Versions: Future
Reporter: Dan Fabulich
Fix For: Future
Normally when you have an aggregator POM with a list of modules, the
element lists out subdirectories of the aggregator, like this:
{code}
modules
modulefoo/module
modulebar/module
/modules
{code}
But modules can be anywhere; the module list can declare relative paths to
anywhere, like this:
{code}
modules
module../foo/module
module../../bar/module
/modules
{code}
Since the reactor plugin currently works by using mvn --reactor, which only
accepts subdirectories, it will silently fail to run these sibling modules.
Ultimately we should fix this by using the new command line switches
available in 2.1.
http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode In the
meantime, we'll have to live with it. (Possibly include a warning? error?)
--
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: (MREACTOR-4) Basic unit test of make goal
[ http://jira.codehaus.org/browse/MREACTOR-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated MREACTOR-4: Fix Version/s: 1.0 Basic unit test of make goal Key: MREACTOR-4 URL: http://jira.codehaus.org/browse/MREACTOR-4 Project: Maven 2.x Reactor Plugin Issue Type: Task Reporter: Dan Fabulich Fix For: 1.0 There should be a basic unit test of the make goal. (This will require the ProjectSorter to be injected, I think... But how do I set that up?) -- 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: (MREACTOR-3) Integration tests
[ http://jira.codehaus.org/browse/MREACTOR-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated MREACTOR-3: Fix Version/s: Future Integration tests - Key: MREACTOR-3 URL: http://jira.codehaus.org/browse/MREACTOR-3 Project: Maven 2.x Reactor Plugin Issue Type: Task Reporter: Dan Fabulich Fix For: Future There should be integration tests for this 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] Closed: (MREACTOR-4) Basic unit test of make goal
[ http://jira.codehaus.org/browse/MREACTOR-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MREACTOR-4. --- Resolution: Fixed Basic unit test of make goal Key: MREACTOR-4 URL: http://jira.codehaus.org/browse/MREACTOR-4 Project: Maven 2.x Reactor Plugin Issue Type: Task Reporter: Dan Fabulich Fix For: 1.0 There should be a basic unit test of the make goal. (This will require the ProjectSorter to be injected, I think... But how do I set that up?) -- 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-459) Integration test using Jetty and JSP 2.1 fails after update to maven-surefire-plugin 2.4
[ http://jira.codehaus.org/browse/SUREFIRE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=146924#action_146924 ] Dan Fabulich commented on SUREFIRE-459: --- Yes, file a separate issue. But before you do, be sure to read this: http://maven.apache.org/plugins/maven-surefire-plugin/examples/class-loading.html Integration test using Jetty and JSP 2.1 fails after update to maven-surefire-plugin 2.4 Key: SUREFIRE-459 URL: http://jira.codehaus.org/browse/SUREFIRE-459 Project: Maven Surefire Issue Type: Bug Components: classloading, plugin Affects Versions: 2.4, 2.4.1 Environment: Maven 2.0.8, Windows XP Reporter: Nils-Helge Garli Assignee: Dan Fabulich Fix For: 2.4.3 We have an integration test running in a Struts 2 sample application, and after the maven-surefire-plugin was updated from 2.3 to 2.4, the test is failing. There's an issue registered in the Struts 2 JIRA explaining the error: https://issues.apache.org/struts/browse/WW-2494 I have no idea what's causing the error, but I suspect it has something to do witn classloader configuration, as aparently no tld files are found inside the jar files on the classpath. It should be pretty easy to reproduce. Just checkout the Struts 2 code and run 'mvn test' on the portlet example application. -- 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: (MPH-51) help:help -Ddetail looks better than help:describe -Dplugin=help -Dfull
[ http://jira.codehaus.org/browse/MPH-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MPH-51. --- Resolution: Fixed Fix Version/s: 2.1 fixed in revision 690124. help:help -Ddetail looks better than help:describe -Dplugin=help -Dfull --- Key: MPH-51 URL: http://jira.codehaus.org/browse/MPH-51 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Dan Fabulich Assignee: Dan Fabulich Fix For: 2.1 Run help:help -Ddetail. Looks nice, doesn't it? Run help:describe -Dplugin=help -Dfull. It's way uglier, and contains lots of irrelevant parameters that the user isn't allowed to specify from the command line. Ideally help:describe and help:help would share code so we wouldn't have to worry about 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: (MPH-52) help:describe never shows Default Value
[ http://jira.codehaus.org/browse/MPH-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MPH-52. --- Resolution: Fixed Fix Version/s: 2.1 fixed in revision 690124. help:describe never shows Default Value - Key: MPH-52 URL: http://jira.codehaus.org/browse/MPH-52 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Dan Fabulich Assignee: Dan Fabulich Fix For: 2.1 Run mvn help:describe -Dcmd=help:describe -Dfull. The output should include some default values (e.g. medium's default value is true), but no default values are specified. There's code in help:describe to display default values, but strangely the code never activates because the MojoDescriptor's parameters always claim to have a null default value. -- 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: (MPH-51) help:help -Ddetail looks better than help:describe -Dplugin=help -Dfull
[ http://jira.codehaus.org/browse/MPH-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=146428#action_146428 ] Dan Fabulich commented on MPH-51: - +1, filed MPH-54. Not assigning to me (at least for now); you can take it. help:help -Ddetail looks better than help:describe -Dplugin=help -Dfull --- Key: MPH-51 URL: http://jira.codehaus.org/browse/MPH-51 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Dan Fabulich Assignee: Dan Fabulich Fix For: 2.1 Run help:help -Ddetail. Looks nice, doesn't it? Run help:describe -Dplugin=help -Dfull. It's way uglier, and contains lots of irrelevant parameters that the user isn't allowed to specify from the command line. Ideally help:describe and help:help would share code so we wouldn't have to worry about 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: (MDEP-178) Create a goal to download single artifact transitively
[ http://jira.codehaus.org/browse/MDEP-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=146429#action_146429 ] Dan Fabulich commented on MDEP-178: --- Hmm, you raise a good point but I don't really have time to tinker with it right away; file a separate bug...? Create a goal to download single artifact transitively -- Key: MDEP-178 URL: http://jira.codehaus.org/browse/MDEP-178 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Reporter: Dan Fabulich Assignee: Dan Fabulich Fix For: 2.1 I've always found it to be a hassle to test plugins that don't need to be wired up in POM files, e.g. the archetype, dependency, scm plugins. I find that to test them I have to create a dummy POM file with a pluginRepositories section, as described in our guide to testing staged releases. http://maven.apache.org/guides/development/guide-testing-releases.html I thought it would be cool to have a downloader goal that let you do this: mvn dependency:get -Dartifact=org.apache.maven.plugins:maven-scm-plugin:1.1 -DrepoUrl=http://people.apache.org/~olamy/staging-repo That would retrieve the plugin into your local repository, so you could immediately start using it. mvn org.apache.maven.plugins:maven-scm-plugin:1.1:checkin -Dmessage=foo -- 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: (MDEP-178) Create a goal to download single artifact transitively
Create a goal to download single artifact transitively -- Key: MDEP-178 URL: http://jira.codehaus.org/browse/MDEP-178 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Reporter: Dan Fabulich Assignee: Brian Fox I've always found it to be a hassle to test plugins that don't need to be wired up in POM files, e.g. the archetype, dependency, scm plugins. I find that to test them I have to create a dummy POM file with a pluginRepositories section, as described in our guide to testing staged releases. http://maven.apache.org/guides/development/guide-testing-releases.html I thought it would be cool to have a downloader goal that let you do this: mvn dependency:get -Dartifact=org.apache.maven.plugins:maven-scm-plugin:1.1 -DrepoUrl=http://people.apache.org/~olamy/staging-repo That would retrieve the plugin into your local repository, so you could immediately start using it. mvn org.apache.maven.plugins:maven-scm-plugin:1.1:checkin -Dmessage=foo -- 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: (MDEP-178) Create a goal to download single artifact transitively
[ http://jira.codehaus.org/browse/MDEP-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MDEP-178. - Resolution: Fixed Fix Version/s: 2.1 Committed revision 689779. Create a goal to download single artifact transitively -- Key: MDEP-178 URL: http://jira.codehaus.org/browse/MDEP-178 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Reporter: Dan Fabulich Assignee: Dan Fabulich Fix For: 2.1 I've always found it to be a hassle to test plugins that don't need to be wired up in POM files, e.g. the archetype, dependency, scm plugins. I find that to test them I have to create a dummy POM file with a pluginRepositories section, as described in our guide to testing staged releases. http://maven.apache.org/guides/development/guide-testing-releases.html I thought it would be cool to have a downloader goal that let you do this: mvn dependency:get -Dartifact=org.apache.maven.plugins:maven-scm-plugin:1.1 -DrepoUrl=http://people.apache.org/~olamy/staging-repo That would retrieve the plugin into your local repository, so you could immediately start using it. mvn org.apache.maven.plugins:maven-scm-plugin:1.1:checkin -Dmessage=foo -- 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: (MDEP-178) Create a goal to download single artifact transitively
[ http://jira.codehaus.org/browse/MDEP-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=146311#action_146311 ] Dan Fabulich commented on MDEP-178: --- I added a transitive option. -Dtransitive=false will do what you want. You can always change the localRepository for Maven globally with -Dmaven.repo.local=/home/blah/myRepo. (If you just want to put a jar in your target directory and not in any local repository at all, you probably want dependency:copy instead.) Create a goal to download single artifact transitively -- Key: MDEP-178 URL: http://jira.codehaus.org/browse/MDEP-178 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Reporter: Dan Fabulich Assignee: Dan Fabulich Fix For: 2.1 I've always found it to be a hassle to test plugins that don't need to be wired up in POM files, e.g. the archetype, dependency, scm plugins. I find that to test them I have to create a dummy POM file with a pluginRepositories section, as described in our guide to testing staged releases. http://maven.apache.org/guides/development/guide-testing-releases.html I thought it would be cool to have a downloader goal that let you do this: mvn dependency:get -Dartifact=org.apache.maven.plugins:maven-scm-plugin:1.1 -DrepoUrl=http://people.apache.org/~olamy/staging-repo That would retrieve the plugin into your local repository, so you could immediately start using it. mvn org.apache.maven.plugins:maven-scm-plugin:1.1:checkin -Dmessage=foo -- 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: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=146361#action_146361 ] Dan Fabulich commented on MNG-624: -- I agree, I think I need to see integration tests that act as examples. automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.0 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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: (MPH-49) help:describe no-arg error doesn't mention cmd
help:describe no-arg error doesn't mention cmd Key: MPH-49 URL: http://jira.codehaus.org/browse/MPH-49 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Dan Fabulich Run mvn help:describe with no other arguments with help-plugin 2.1. It instructs you to pass in a plugin, or a groupId/artifactId. It doesn't mention that you can pass in a cmd -- 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: (MPH-50) mvn help:describe -Dcmd=compiler:compile describes entire plugin, not the specific mojo
mvn help:describe -Dcmd=compiler:compile describes entire plugin, not the specific mojo - Key: MPH-50 URL: http://jira.codehaus.org/browse/MPH-50 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Dan Fabulich On 2.1, run mvn help:describe -Dcmd=compiler:compile. It describes the compiler plugin, rather than describing the compile mojo as it should. mvn help:describe -Dcmd=compiler:compile should do exactly the same thing as mvn help:describe -Dplugin=compiler -Dmojo=compile -- 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: (MPH-51) help:help -Ddetail looks better than help:describe -Dplugin=help -Dfull
help:help -Ddetail looks better than help:describe -Dplugin=help -Dfull --- Key: MPH-51 URL: http://jira.codehaus.org/browse/MPH-51 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Dan Fabulich Run help:help -Ddetail. Looks nice, doesn't it? Run help:describe -Dplugin=help -Dfull. It's way uglier, and contains lots of irrelevant parameters that the user isn't allowed to specify from the command line. Ideally help:describe and help:help would share code so we wouldn't have to worry about 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] Reopened: (MPH-33) Help plugin should refer to goal not mojo
[ http://jira.codehaus.org/browse/MPH-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich reopened MPH-33: - Nobody's going to find that FAQ! :-) We should just call it a goal to match the behavior of help:help. Help plugin should refer to goal not mojo - Key: MPH-33 URL: http://jira.codehaus.org/browse/MPH-33 Project: Maven 2.x Help Plugin Issue Type: Improvement Reporter: Dan Fabulich Priority: Minor The help plugin makes a lot of references to mojos which I think is confusing to people who don't do Maven development. We should be consistent in referring to these things as goals rather than mojos in the help documentation, which we expect to be primarily used by newbies. -- 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: (MPH-50) mvn help:describe -Dcmd=compiler:compile describes entire plugin, not the specific mojo
[ http://jira.codehaus.org/browse/MPH-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MPH-50. --- Resolution: Fixed Fix Version/s: 2.1 fixed revision 690097 mvn help:describe -Dcmd=compiler:compile describes entire plugin, not the specific mojo - Key: MPH-50 URL: http://jira.codehaus.org/browse/MPH-50 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Dan Fabulich Fix For: 2.1 On 2.1, run mvn help:describe -Dcmd=compiler:compile. It describes the compiler plugin, rather than describing the compile mojo as it should. mvn help:describe -Dcmd=compiler:compile should do exactly the same thing as mvn help:describe -Dplugin=compiler -Dmojo=compile -- 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: (MPH-33) Help plugin should refer to goal not mojo
[ http://jira.codehaus.org/browse/MPH-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MPH-33. --- Resolution: Fixed Fix Version/s: 2.1 Fixed revision 690098. Added backwards compatibility for mojo. Also added support for help:help parameter -Ddetail instead of -Dfull. Help plugin should refer to goal not mojo - Key: MPH-33 URL: http://jira.codehaus.org/browse/MPH-33 Project: Maven 2.x Help Plugin Issue Type: Improvement Reporter: Dan Fabulich Priority: Minor Fix For: 2.1 The help plugin makes a lot of references to mojos which I think is confusing to people who don't do Maven development. We should be consistent in referring to these things as goals rather than mojos in the help documentation, which we expect to be primarily used by newbies. -- 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: (MPH-49) help:describe no-arg error doesn't mention cmd
[ http://jira.codehaus.org/browse/MPH-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MPH-49. --- Resolution: Fixed Fix Version/s: 2.1 Fixed revision 690099. help:describe no-arg error doesn't mention cmd Key: MPH-49 URL: http://jira.codehaus.org/browse/MPH-49 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Dan Fabulich Fix For: 2.1 Run mvn help:describe with no other arguments with help-plugin 2.1. It instructs you to pass in a plugin, or a groupId/artifactId. It doesn't mention that you can pass in a cmd -- 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: (MPH-52) help:describe never shows Default Value
help:describe never shows Default Value - Key: MPH-52 URL: http://jira.codehaus.org/browse/MPH-52 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Dan Fabulich Run mvn help:describe -Dcmd=help:describe -Dfull. The output should include some default values (e.g. medium's default value is true), but no default values are specified. There's code in help:describe to display default values, but strangely the code never activates because the MojoDescriptor's parameters always claim to have a null default value. -- 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: (MNG-2576) Make Like Reactor Mode
[ http://jira.codehaus.org/browse/MNG-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=145787#action_145787 ] Dan Fabulich commented on MNG-2576: --- I don't think I understand your question, but maybe this will help: revision 687388 was made to branches/maven-2.1.x. I have not ported it to trunk. The fate of the maven-2.1.x branch is up in the air right now, but I imagine that we will do a release off of that branch, and that it will be called 2.1.0 or possibly 2.1.1. Make Like Reactor Mode -- Key: MNG-2576 URL: http://jira.codehaus.org/browse/MNG-2576 Project: Maven 2 Issue Type: New Feature Components: Command Line, Reactor and workspace Reporter: Kenney Westerhof Assignee: Dan Fabulich Fix For: 2.1.0 Add a commandline option to enable maven to expand the reactor scope to find projects that are dependencies of the projects currently in the reactor, and add them. Currently only the current project and child projects are included in the reactor search. I'm proposing to add a commandline switch that lets maven check parent directories to find the root of the project tree, and then do a normal reactor scan, only adding projects that would normally not be added if they're needed as dependencies of the projects that would normally be built. Here's a sample project tree: * root ** p1 *** c1 (depends on p2) ** p2 (depends on c2) ** p3 *** c2 And a sample algorithm: - When building c1, the reactor would contain [c1]. - Maven would check p1, then root, etc, using the parent tags (without the versions!) to see if the project is still in the current reactor. - It would then create a second list of projects (reactor2) containing ALL projects, using the newly discovered root: [root, p1, c2, p2]. - remove all projects from reactor2 contained in reactor: reactor2 = [root, p1, p2] - resolve all direct dependencies for all projects in reactor in reactor2 and add them to reactor, taking versions into account: reactor = [p2, c1] - repeat previous step until all projects have their dependencies resolved from reactor 2. first iteration would yield reactor = [c2, p2, c1], next iteration would stop since c1 doesn't have any dependencies present in reactor2. This would ensure that when some local project's sources have changed, they'll be incorporated in the build, regardless of where you build. So you don't have to do a reactor build each time you change more than 1 project, and you don't have to remember which projects you changed and build them in the correct order yourself, manually. -- 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: (MNG-2576) Make Like Reactor Mode
[ http://jira.codehaus.org/browse/MNG-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated MNG-2576: -- Priority: Major (was: Minor) Summary: Make Like Reactor Mode (was: Add option to find root of project tree from subproject and build required deps) Make Like Reactor Mode -- Key: MNG-2576 URL: http://jira.codehaus.org/browse/MNG-2576 Project: Maven 2 Issue Type: New Feature Components: Command Line, Reactor and workspace Reporter: Kenney Westerhof Fix For: Reviewed Pending Version Assignment Add a commandline option to enable maven to expand the reactor scope to find projects that are dependencies of the projects currently in the reactor, and add them. Currently only the current project and child projects are included in the reactor search. I'm proposing to add a commandline switch that lets maven check parent directories to find the root of the project tree, and then do a normal reactor scan, only adding projects that would normally not be added if they're needed as dependencies of the projects that would normally be built. Here's a sample project tree: * root ** p1 *** c1 (depends on p2) ** p2 (depends on c2) ** p3 *** c2 And a sample algorithm: - When building c1, the reactor would contain [c1]. - Maven would check p1, then root, etc, using the parent tags (without the versions!) to see if the project is still in the current reactor. - It would then create a second list of projects (reactor2) containing ALL projects, using the newly discovered root: [root, p1, c2, p2]. - remove all projects from reactor2 contained in reactor: reactor2 = [root, p1, p2] - resolve all direct dependencies for all projects in reactor in reactor2 and add them to reactor, taking versions into account: reactor = [p2, c1] - repeat previous step until all projects have their dependencies resolved from reactor 2. first iteration would yield reactor = [c2, p2, c1], next iteration would stop since c1 doesn't have any dependencies present in reactor2. This would ensure that when some local project's sources have changed, they'll be incorporated in the build, regardless of where you build. So you don't have to do a reactor build each time you change more than 1 project, and you don't have to remember which projects you changed and build them in the correct order yourself, manually. -- 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: (MNG-2576) Make Like Reactor Mode
[ http://jira.codehaus.org/browse/MNG-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MNG-2576. - Resolution: Fixed Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1.0 Checked in revision 687388. Make Like Reactor Mode -- Key: MNG-2576 URL: http://jira.codehaus.org/browse/MNG-2576 Project: Maven 2 Issue Type: New Feature Components: Command Line, Reactor and workspace Reporter: Kenney Westerhof Fix For: 2.1.0 Add a commandline option to enable maven to expand the reactor scope to find projects that are dependencies of the projects currently in the reactor, and add them. Currently only the current project and child projects are included in the reactor search. I'm proposing to add a commandline switch that lets maven check parent directories to find the root of the project tree, and then do a normal reactor scan, only adding projects that would normally not be added if they're needed as dependencies of the projects that would normally be built. Here's a sample project tree: * root ** p1 *** c1 (depends on p2) ** p2 (depends on c2) ** p3 *** c2 And a sample algorithm: - When building c1, the reactor would contain [c1]. - Maven would check p1, then root, etc, using the parent tags (without the versions!) to see if the project is still in the current reactor. - It would then create a second list of projects (reactor2) containing ALL projects, using the newly discovered root: [root, p1, c2, p2]. - remove all projects from reactor2 contained in reactor: reactor2 = [root, p1, p2] - resolve all direct dependencies for all projects in reactor in reactor2 and add them to reactor, taking versions into account: reactor = [p2, c1] - repeat previous step until all projects have their dependencies resolved from reactor 2. first iteration would yield reactor = [c2, p2, c1], next iteration would stop since c1 doesn't have any dependencies present in reactor2. This would ensure that when some local project's sources have changed, they'll be incorporated in the build, regardless of where you build. So you don't have to do a reactor build each time you change more than 1 project, and you don't have to remember which projects you changed and build them in the correct order yourself, manually. -- 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-402) scm:checkin doesn't work on OS X 10.5 Leopard
scm:checkin doesn't work on OS X 10.5 Leopard - Key: SCM-402 URL: http://jira.codehaus.org/browse/SCM-402 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Affects Versions: 1.0 Reporter: Dan Fabulich Priority: Blocker Run mvn scm:checkin -Dmessage=test on OS X 10.5 Leopard. You'll see: [INFO] Executing: svn --non-interactive commit --file /tmp/maven-scm-1856881168.commit But --non-interactive is broken on OS X 10.5 Leopard. http://subversion.tigris.org/issues/show_bug.cgi?id=3059 Brett Porter has a hacky workaround for it here: http://blogs.exist.com/bporter/2008/02/25/working-around-non-interactive-problems-in-leopards-subversion/ -- 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-514) Provide a way to skip a project's tests if nothing has changed
Provide a way to skip a project's tests if nothing has changed -- Key: SUREFIRE-514 URL: http://jira.codehaus.org/browse/SUREFIRE-514 Project: Maven Surefire Issue Type: New Feature Reporter: Dan Fabulich Surefire should have an incremental mode, perhaps enabled by default. We should check the timestamps of every element of the classpath (and every class in any classpath folder) and touch a file in target with that timestamp. If none of those files have been updated, skip tests for the current project. It definitely needs to be possible to turn this feature off, though, because sometimes you need to re-run tests based on external resources not on the classpath: deployed web servers, database schema changes, etc. -- 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: (MINVOKER-54) Invoker should provide support for activateReactor
Invoker should provide support for activateReactor
Key: MINVOKER-54
URL: http://jira.codehaus.org/browse/MINVOKER-54
Project: Maven 2.x Invoker Plugin
Issue Type: New Feature
Affects Versions: 1.3
Reporter: Dan Fabulich
mvn --reactor will search subdirectories for pom.xml files and dynamically
build a reactor using them. You can also specify includes/excludes directory
with -Dmaven.reactor.includes and -Dmaven.reactor.excludes.
It would be nice to be able to use this with the Maven Invoker... but look at
DefaultInvocationRequest. It has a method called activateReactor:
{code}
public InvocationRequest activateReactor( String[] includes, String[] excludes )
{
throw new UnsupportedOperationException( Not implemented yet. );
}
{code}
It would be helpful if it were implemented.
--
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: (MINVOKER-54) Invoker should provide support for activateReactor
[
http://jira.codehaus.org/browse/MINVOKER-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed MINVOKER-54.
Resolution: Fixed
Fix Version/s: 1.3
Checked in a fix to maven-invoker revision 686017, so now the API supports it.
The invoker-plugin already provides support for running included/excluded POMs,
so I don't necessarily think it's worth adding the feature in at that level;
somebody else can file that bug if anyone cares! ;-)
Invoker should provide support for activateReactor
Key: MINVOKER-54
URL: http://jira.codehaus.org/browse/MINVOKER-54
Project: Maven 2.x Invoker Plugin
Issue Type: New Feature
Affects Versions: 1.2
Reporter: Dan Fabulich
Assignee: Dan Fabulich
Fix For: 1.3
mvn --reactor will search subdirectories for pom.xml files and dynamically
build a reactor using them. You can also specify includes/excludes directory
with -Dmaven.reactor.includes and -Dmaven.reactor.excludes.
It would be nice to be able to use this with the Maven Invoker... but look at
DefaultInvocationRequest. It has a method called activateReactor:
{code}
public InvocationRequest activateReactor( String[] includes, String[]
excludes )
{
throw new UnsupportedOperationException( Not implemented yet. );
}
{code}
It would be helpful if it were implemented.
--
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-499) Can't use -Dmaven.repo.local=tmp in multi-module reactor when useSystemClassLoader=false
Can't use -Dmaven.repo.local=tmp in multi-module reactor when useSystemClassLoader=false Key: SUREFIRE-499 URL: http://jira.codehaus.org/browse/SUREFIRE-499 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.4.3 Reporter: Dan Fabulich At Redfin, we often launch builds with -Dmaven.repo.local=tmp (that is, temporarily put the local repo in the root of the build dir) to guarantee reproducibility. In a reactor build, we launch the sub-process and modify user.dir to be the dir of the leaf projects. When useSystemClassLoader=false, the IsolatedClassLoader thinks that the local repo is in parent/child/tmp rather than parent/tmp; as a result, the ICL fails to load any classes out of the local repository. The fix should be to make the classpath absolute rather than passing relative paths to the launched process. This might be a Maven core bug, or it might be possible to handle it in the 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] Closed: (SUREFIRE-491) All system properties from Maven process are copied to forked Surefire process
[ http://jira.codehaus.org/browse/SUREFIRE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-491. - Resolution: Fixed Fixed revision 652773. All system properties from Maven process are copied to forked Surefire process -- Key: SUREFIRE-491 URL: http://jira.codehaus.org/browse/SUREFIRE-491 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.4.3 Reporter: Dan Fabulich Fix For: 2.4.3 Run a Surefire test with a different JVM using the -Djvm argument. For example, run the test with JDK 1.4 while running Maven with a 1.5 or 1.6 JVM. Examine the XML file in target/surefire-reports corresponding to your test. The java.* properties will match the parent process, not the forked process. For example, property name=java.version value=1.6.0_02/. -- 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-121) System properties set on the command line get clobbered
[ http://jira.codehaus.org/browse/SUREFIRE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-121: -- Fix Version/s: (was: 2.4.1) Future System properties set on the command line get clobbered --- Key: SUREFIRE-121 URL: http://jira.codehaus.org/browse/SUREFIRE-121 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.0 (2.2 plugin) Environment: Linux, Maven 2.0.4, Sun JDK 1.5U5, bash 3.0 Reporter: Brenton Leanhardt Priority: Critical Fix For: Future Some system properties get clobbered if you set them on the command line. For example, mvn clean test -Dtest=LoginTest -Dselenium.user=test32 The 'test' system property will work, but the 'selenium.user' property will be null at runtime. I have tried: * hard coding the system property in the unit test, this worked fine. * setting the system properties in the pom file, this worked fine also. * tried an older version of the surefire plugin, this worked fine. -- 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] Reopened: (SUREFIRE-121) System properties set on the command line get clobbered
[ http://jira.codehaus.org/browse/SUREFIRE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich reopened SUREFIRE-121: --- Deliberately broken in revision 652773 to fix SUREFIRE-491. System properties set on the command line get clobbered --- Key: SUREFIRE-121 URL: http://jira.codehaus.org/browse/SUREFIRE-121 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.0 (2.2 plugin) Environment: Linux, Maven 2.0.4, Sun JDK 1.5U5, bash 3.0 Reporter: Brenton Leanhardt Priority: Critical Fix For: Future Some system properties get clobbered if you set them on the command line. For example, mvn clean test -Dtest=LoginTest -Dselenium.user=test32 The 'test' system property will work, but the 'selenium.user' property will be null at runtime. I have tried: * hard coding the system property in the unit test, this worked fine. * setting the system properties in the pom file, this worked fine also. * tried an older version of the surefire plugin, this worked fine. -- 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: (SUREFIRE-473) Documentation for additionalClassPath feature
[ http://jira.codehaus.org/browse/SUREFIRE-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-473. - Resolution: Fixed Submitted in revision 652774... cleaned up grammar a bit and also added a recommendation to use a private repository. Documentation for additionalClassPath feature - Key: SUREFIRE-473 URL: http://jira.codehaus.org/browse/SUREFIRE-473 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.4.2 Reporter: Pascal Lambert Priority: Minor Fix For: 2.4.3 Attachments: surefire-additional-classpath.patch Here is the example documentation for implemented feature additionalClasspath http://jira.codehaus.org/browse/SUREFIRE-118 -- 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: (SUREFIRE-492) Allow test parameter to override suiteXmlFiles
[ http://jira.codehaus.org/browse/SUREFIRE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-492. - Resolution: Fixed Fixed revision 652695. Allow test parameter to override suiteXmlFiles Key: SUREFIRE-492 URL: http://jira.codehaus.org/browse/SUREFIRE-492 Project: Maven Surefire Issue Type: Bug Components: TestNG support Reporter: Dan Fabulich Fix For: 2.4.3 If a suiteXmlFile is specified in the POM, it's impossible to override it from the command line; that doesn't make much sense, especially now that TestNG 5.8 includes support for @Optional parameters, so it may make sense to run the tests with -Dtest. -- 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: (SUREFIRE-488) Document TestNG listeners/reporters
[ http://jira.codehaus.org/browse/SUREFIRE-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-488. - Resolution: Fixed Fixed revision 652699 Document TestNG listeners/reporters --- Key: SUREFIRE-488 URL: http://jira.codehaus.org/browse/SUREFIRE-488 Project: Maven Surefire Issue Type: Task Components: documentation, TestNG support Reporter: Dan Fabulich Fix For: 2.4.3 TestNG listeners/reporters are kind of tricky. The TestNG documentation should be updated to explain how to do this. http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/testng-listener-reporter -- 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: (SUREFIRE-489) Document classpath issues
[ http://jira.codehaus.org/browse/SUREFIRE-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-489. - Resolution: Fixed Fixed revision 652710. Document classpath issues - Key: SUREFIRE-489 URL: http://jira.codehaus.org/browse/SUREFIRE-489 Project: Maven Surefire Issue Type: Task Reporter: Dan Fabulich Fix For: 2.4.3 This doc should be incorporated into the main site: http://docs.codehaus.org/display/MAVENUSER/Classloading+and+Forking+under+Maven+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: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[ http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-482: -- Fix Version/s: (was: 2.5) Surefire tries to run JUnit4 tests that contain no @Test annotations Key: SUREFIRE-482 URL: http://jira.codehaus.org/browse/SUREFIRE-482 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.4.2 Reporter: Mark Hobson Attachments: test.zip Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that contain no @Test annotations as tests, resulting in the exception: java.lang.Exception: No runnable methods at org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32) at org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43) at org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36) at org.junit.internal.runners.JUnit4ClassRunner.init(JUnit4ClassRunner.java:27) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) at org.apache.maven.surefire.junit4.JUnit4TestSet.init(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:156) 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.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Such classes should be ignored by 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] Closed: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[ http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-482. - Resolution: Won't Fix I'm marking this won't fix, though I could be convinced otherwise. Forgetting to add @Test annotations is a common error for users upgrading from JUnit 3, and even occasionally for experienced users. Naming a class *Test without making it abstract and without putting any @Test annotations is quite unusual, and probably shouldn't be silently ignored. Surefire tries to run JUnit4 tests that contain no @Test annotations Key: SUREFIRE-482 URL: http://jira.codehaus.org/browse/SUREFIRE-482 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.4.2 Reporter: Mark Hobson Fix For: 2.5 Attachments: test.zip Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that contain no @Test annotations as tests, resulting in the exception: java.lang.Exception: No runnable methods at org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32) at org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43) at org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36) at org.junit.internal.runners.JUnit4ClassRunner.init(JUnit4ClassRunner.java:27) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) at org.apache.maven.surefire.junit4.JUnit4TestSet.init(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:156) 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.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Such classes should be ignored by 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] Closed: (SUREFIRE-474) Allow TestNG to use its built-in HTMLReporter
[ http://jira.codehaus.org/browse/SUREFIRE-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-474. - Resolution: Fixed Fix Version/s: (was: 2.5) 2.4.3 Fixed revision 652745. TestNG's reporter works only at test time, so we just enable the default HTML reports at runtime, but allow the user to manually disable them with the usedefaultlisteners option. Special case for TestNG 4.7, which drops its default XML files in the surefire-reports directory inappropriately; in that case, usedefaultlisteners is false by default. Allow TestNG to use its built-in HTMLReporter - Key: SUREFIRE-474 URL: http://jira.codehaus.org/browse/SUREFIRE-474 Project: Maven Surefire Issue Type: Improvement Reporter: Dan Fabulich Fix For: 2.4.3 TestNG has no way to generate reports from its own XML file after the fact. (Seriously? Seriously.) http://groups.google.com/group/testng-users/browse_thread/thread/79cf66e72aa65255 So, in order to get HTML reports, you have to generate them at test time. But we expose no convenient way for you to do that in Surefire. (I think you can attach TestNG's HTMLReporter as a custom listener, but that's kinda tricky for what should be a simple problem.) -- 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: (SUREFIRE-490) Provide an option to use simplified classloading
[ http://jira.codehaus.org/browse/SUREFIRE-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-490. - Resolution: Fixed Fix Version/s: (was: 2.5) 2.4.3 Fixed in revision 652767. Provide an option to use simplified classloading Key: SUREFIRE-490 URL: http://jira.codehaus.org/browse/SUREFIRE-490 Project: Maven Surefire Issue Type: Improvement Components: classloading Reporter: Dan Fabulich Fix For: 2.4.3 Surefire is currently able to launch tests using a manifest-only jar, or by using a funky isolated classloader if useSystemClassLoader=true. But we currently don't provide a way to just use a plain old java classpath (POJC?) A POJC will often fail for Windows users; we should warn users to be careful with it, but provide it as an option where necessary. -- 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-491) All system properties from Maven process are copied to forked Surefire process
[ http://jira.codehaus.org/browse/SUREFIRE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-491: -- Fix Version/s: (was: 2.5) 2.4.3 All system properties from Maven process are copied to forked Surefire process -- Key: SUREFIRE-491 URL: http://jira.codehaus.org/browse/SUREFIRE-491 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.4.3 Reporter: Dan Fabulich Fix For: 2.4.3 Run a Surefire test with a different JVM using the -Djvm argument. For example, run the test with JDK 1.4 while running Maven with a 1.5 or 1.6 JVM. Examine the XML file in target/surefire-reports corresponding to your test. The java.* properties will match the parent process, not the forked process. For example, property name=java.version value=1.6.0_02/. -- 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: (SUREFIRE-486) Exlude tests via an external exlude file
[ http://jira.codehaus.org/browse/SUREFIRE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-486. - Resolution: Won't Fix That page doesn't have anything to do with testing, though I'm quite familiar with the idea that some tests may be expected to fail on some platforms but pass on other platforms. TestNG allows you to specify an external suite file which configures which tests will be skipped. You can also use code to decide when to throw a skip exception. You can even dynamically query your bug DB to find out whether a bug is still unresolved, and skip only if the bug is open. [Of course, it may not be a good idea to make your tests that complex. ;-)] Your remark about being tied to a testing framework is strange, because Surefire only runs tests that are tied to a testing framework: it will run JUnit tests (which are tied to JUnit) or it will run TestNG tests (which are tied to TestNG). The @Ignore/Skip feature is not specific to either framework; you can use it in either, but if you want to switch frameworks, you have to re-code all of your tests. More generally, sometimes people file feature requests to Surefire that are appropriately targeted to the underlying test framework. [I wish JUnit had feature X. But the JUnit guys do releases less than once a year! Maybe I could ask the Surefire guys to do it for me instead.] This is one of those feature requests that not only *can* be solved by the underlying test framework, it already *has* been solved in both of the test frameworks we support. Exlude tests via an external exlude file Key: SUREFIRE-486 URL: http://jira.codehaus.org/browse/SUREFIRE-486 Project: Maven Surefire Issue Type: New Feature Reporter: Thomas Diesler Similar to Ant, Surefire should support excludes defined in an external file like this testExcludes excludeFiletest-excludes-jboss501.txt/excludeFile /testExcludes The exclude file would look like this # [JBWS-2135] WebServiceException: Undefined port type org/jboss/test/ws/jaxws/jbws1822/** # [JBWS-2136] ClassCastException: com.sun.xml.ws.server.EndpointMessageContextImpl org/jboss/test/ws/jaxws/namespace/** # [JBAS-5359] mapped-name is required for context of deployment org/jboss/test/ws/jaxws/jbws1611/** -- 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: (SUREFIRE-494) Add support to set listener to testNG runner
[ http://jira.codehaus.org/browse/SUREFIRE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-494. - Resolution: Not A Bug Surefire already supports configuring custom listeners/reporters. Unfortunately, our documentation isn't very clear on this point; I've field SUREFIRE-488 to update our documentation so other people will know how to do this in the future. Sorry! :-( Add support to set listener to testNG runner Key: SUREFIRE-494 URL: http://jira.codehaus.org/browse/SUREFIRE-494 Project: Maven Surefire Issue Type: New Feature Components: TestNG support Affects Versions: 2.4.2 Environment: Continuous integration using maven. Reporter: Nicolas Santini Attachments: SurefirePlugin.diff Add a listener property to the class org.apache.maven.plugin.surefire.SurefirePlugin to support adding custom/propietary listeners through pom configuration. We've created a patch for this, please evaluate it. In this solution we added a new private field called listener and an if clause in the convertTestNGParameters method to set it to the TestNG artifact 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
[jira] Closed: (SUREFIRE-477) Issue with redirectTestOutputToFile and unit test with System.out.print
[
http://jira.codehaus.org/browse/SUREFIRE-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed SUREFIRE-477.
-
Resolution: Cannot Reproduce
Something is wrong with your attached file! It's 0.0 kb. Try again?
Issue with redirectTestOutputToFile and unit test with System.out.print
---
Key: SUREFIRE-477
URL: http://jira.codehaus.org/browse/SUREFIRE-477
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.4
Reporter: Denis Sadowski
Priority: Minor
Attachments: command_prompt.JPG, redirectIssue.zip, surefire477.zip
We have the Maven surefire plugin configured to redirect test output to file
using the redirectTestOutputToFile property.
Consider the following unit test:
import static org.junit.Assert.*;
import org.junit.Test;
public class PrintUnitTest {
@Test
public final void test1() {
assertTrue(true);
System.out.print(System.currentTimeMillis());
}
}
The surefire plugin fails to print any more information to the console window
after Running PrintUnitTest. Hence does not show the Tests run .
line.
Furthermore, if other unit tests are run after this one, they run, but there
output is also not shown on the console window. If a build failure occurs in
any of the unit tests the Results, with mention of which tests failed are not
printed.
--
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: (SUREFIRE-493) UrlUtilsTest fails
[
http://jira.codehaus.org/browse/SUREFIRE-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed SUREFIRE-493.
-
Resolution: Fixed
Fixed in revision 652176.
UrlUtilsTest fails
--
Key: SUREFIRE-493
URL: http://jira.codehaus.org/browse/SUREFIRE-493
Project: Maven Surefire
Issue Type: Bug
Environment: Maven version: 2.0.8, Java version: 1.6.0_02, OS name:
windows xp version: 5.1 arch: x86 Family: windows
Reporter: Dan Fabulich
Priority: Blocker
Fix For: 2.4.3
When I run UrlUtilsTest from the command line or from Eclipse, it fails.
(Note my environment above.)
{code}
testTestNoSpecialCharacters(org.apache.maven.surefire.util.UrlUtilsTest)
Time elapsed: 0 sec FAILURE!
junit.framework.AssertionFailedError:
expected:file://C:/svn/maven/trunks/surefire/surefire-api/foo.txt but
was:file:/C:/svn/maven/trunks/surefire/surefire-api/foo.txt
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:71)
at
org.apache.maven.surefire.util.UrlUtilsTest.testTestNoSpecialCharacters(UrlUtilsTest.java:55)
testTestWithSpaces(org.apache.maven.surefire.util.UrlUtilsTest) Time
elapsed: 0 sec FAILURE!
junit.framework.AssertionFailedError:
expected:file://C:/svn/maven/trunks/surefire/surefire-api/foo%20bar.txt but
was:file:/C:/svn/maven/trunks/surefire/surefire-api/foo%20bar.txt
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:71)
at
org.apache.maven.surefire.util.UrlUtilsTest.testTestWithSpaces(UrlUtilsTest.java:70)
testTestWithUmlaut(org.apache.maven.surefire.util.UrlUtilsTest) Time
elapsed: 0.016 sec FAILURE!
junit.framework.AssertionFailedError:
expected:file://C:/svn/maven/trunks/surefire/surefire-api/fo%c3%9c.txt but
was:file:/C:/svn/maven/trunks/surefire/surefire-api/fo%c3%9c.txt
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:71)
at
org.apache.maven.surefire.util.UrlUtilsTest.testTestWithUmlaut(UrlUtilsTest.java:77)
{code}
--
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: (SUREFIRE-485) Support AntUnit XML output
[ http://jira.codehaus.org/browse/SUREFIRE-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-485. - Resolution: Fixed Patch submitted revision 652186. Thanks! Support AntUnit XML output -- Key: SUREFIRE-485 URL: http://jira.codehaus.org/browse/SUREFIRE-485 Project: Maven Surefire Issue Type: Improvement Components: report plugin Affects Versions: 2.4.2 Environment: Maven 2.0.8 on Linux, but probably other versions and platforms Reporter: Peter Janes Priority: Minor Fix For: 2.4.3 Attachments: report.patch Because AntUnit (http://ant.apache.org/antlibs/antunit/) doesn't include a time attribute on its JUnit-like testsuite element, maven-surefire-report-plugin throws a NullPointerException when parsing its XML output. The attached patch continues to use the attribute if it's present, but will set the elapsed time for a test suite from AntUnit's nested time element if it exists. -- 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: (SUREFIRE-463) ClassCastException when using testng suiteXmlFile and forkMode=always
[ http://jira.codehaus.org/browse/SUREFIRE-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-463. - Resolution: Fixed Fixed revision 652188. ClassCastException when using testng suiteXmlFile and forkMode=always - Key: SUREFIRE-463 URL: http://jira.codehaus.org/browse/SUREFIRE-463 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.4.2 Environment: linux 2.6.22-1-mepis-smp Reporter: Andreas Andreou Fix For: 2.4.3 Attachments: SUREFIRE-463__handle_TestNG_xmlTestSuites.patch, surefire-bug.zip The related pom part is: profile idbrowser/id build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration suiteXmlFiles suiteXmlFilesrc/test/resources/testng-browser.xml/suiteXmlFile /suiteXmlFiles /configuration /plugin /plugins /build /profile Issuing mvn -Pbrowser test results in the exception: java.lang.ClassCastException: java.io.File cannot be cast to java.lang.String at org.apache.maven.surefire.booter.SurefireBooter.runSuitesForkPerTestSet(SurefireBooter.java:403) at org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:249) at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:492) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.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) Any workarounds for 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: (SUREFIRE-487) We're using DynamicJasper to create reports in our web application. DynamicJasper creates a java report file at runtime and compiles it. It works fine in the application
[ http://jira.codehaus.org/browse/SUREFIRE-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-487. - Resolution: Cannot Reproduce I get compile errors when I try to build your project; I'm unable to run its tests: Procurador.java:[6,24] package javax.persistence does not exist With that said, I surmise that you may have some luck if you try useSystemClassLoader=false, as described in this wiki article: http://docs.codehaus.org/display/MAVENUSER/Classloading+and+Forking+under+Maven+Surefire We're using DynamicJasper to create reports in our web application. DynamicJasper creates a java report file at runtime and compiles it. It works fine in the application. But when we run our test, the compiler can't find any classes in the classpath. --- Key: SUREFIRE-487 URL: http://jira.codehaus.org/browse/SUREFIRE-487 Project: Maven Surefire Issue Type: Bug Components: classloading Reporter: Márcio. P. D. Priority: Blocker Attachments: TesteCaseDJSureFire.zip We're using DynamicJasper ( http://dynamicjasper.sourceforge.net/ ) to create reports in our web application. DynamicJasper creates a java report file at runtime and compiles it. It works fine in the application. But when we run our test, the compiler can't find any classes in the classpath. A test case is provided with the problematic test. -- 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-489) Document classpath issues
Document classpath issues - Key: SUREFIRE-489 URL: http://jira.codehaus.org/browse/SUREFIRE-489 Project: Maven Surefire Issue Type: Task Reporter: Dan Fabulich Fix For: 2.4.3 This doc should be incorporated into the main site: http://docs.codehaus.org/display/MAVENUSER/Classloading+and+Forking+under+Maven+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: (SUREFIRE-489) Document classpath issues
[ http://jira.codehaus.org/browse/SUREFIRE-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-489: -- Fix Version/s: 2.4.3 Document classpath issues - Key: SUREFIRE-489 URL: http://jira.codehaus.org/browse/SUREFIRE-489 Project: Maven Surefire Issue Type: Task Reporter: Dan Fabulich Fix For: 2.4.3 This doc should be incorporated into the main site: http://docs.codehaus.org/display/MAVENUSER/Classloading+and+Forking+under+Maven+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] Closed: (SUREFIRE-481) java.lang.NoSuchMethodError when forking on a 1.3 JDK
[ http://jira.codehaus.org/browse/SUREFIRE-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-481. - Resolution: Fixed Fix Version/s: 2.4.3 This is indeed fixed. I'll try to push out a snapshot today or tomorrow. java.lang.NoSuchMethodError when forking on a 1.3 JDK - Key: SUREFIRE-481 URL: http://jira.codehaus.org/browse/SUREFIRE-481 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.4, 2.4.1, 2.4.2 Environment: Maven version: 2.0.7, 2.0.8, 2.0.9-RC8 or Java version: 1.5.0_12 Reporter: David J. M. Karlsen Fix For: 2.4.3 [INFO] [surefire:test] [DEBUG] dummy:dummy:jar:1.0 (selected for null) [DEBUG] org.apache.maven.surefire:surefire-booter:jar:2.4.2:runtime (selected for runtime) [DEBUG] org.apache.maven.surefire:surefire-api:jar:2.4.2:runtime (selected for runtime) [DEBUG] Adding to surefire booter test classpath: /heim/ab62939/.m2/repository/org/apache/maven/surefire/surefire-booter/2.4.2/surefire-booter-2.4.2.jar [DEBUG] Adding to surefire booter test classpath: /heim/ab62939/.m2/repository/org/apache/maven/surefire/surefire-api/2.4.2/surefire-api-2.4.2.jar [DEBUG] dummy:dummy:jar:1.0 (selected for null) [DEBUG] Retrieving parent-POM: org.apache.maven.surefire:surefire-providers::2.4.2 for project: null:surefire-junit:jar:null from the repository. [DEBUG] Adding managed dependencies for unknown:surefire-junit [DEBUG] org.apache.maven.surefire:surefire-api:jar:2.4.2 [DEBUG] org.apache.maven.surefire:surefire-booter:jar:2.4.2 [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.4.9 [DEBUG] org.apache.maven.surefire:surefire-junit:jar:2.4.2:test (selected for test) [DEBUG] junit:junit:jar:3.8.1:test (selected for test) [DEBUG] org.apache.maven.surefire:surefire-api:jar:2.4.2:test (selected for test) [DEBUG] Adding to surefire test classpath: /heim/ab62939/.m2/repository/org/apache/maven/surefire/surefire-junit/2.4.2/surefire-junit-2.4.2.jar [DEBUG] Adding to surefire test classpath: /heim/ab62939/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar [DEBUG] Adding to surefire test classpath: /heim/ab62939/.m2/repository/org/apache/maven/surefire/surefire-api/2.4.2/surefire-api-2.4.2.jar [DEBUG] Test Classpath : [snip...] [INFO] Surefire report directory: /tmp/dnbnorapi-trunk/dnbnorapi-server/target/surefire-reports Forking command line: /bin/sh -c cd /tmp/dnbnorapi-trunk/dnbnorapi-server /dnb/prosess/WebSphere5/AppServer/java/jre/bin/java -Xmx128M -jar /var/tmp/surefirebooter29275.jar /var/tmp/surefire29273tmp /var/tmp/surefire29274tmp java.lang.NoSuchMethodError at org.apache.maven.surefire.util.UrlUtils.getURL(UrlUtils.java:39) at org.apache.maven.surefire.booter.SurefireBooter.createClassLoader(SurefireBooter.java:730) at org.apache.maven.surefire.booter.SurefireBooter.createClassLoader(SurefireBooter.java:715) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:277) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993) [ERROR] There are test failures. -- 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-468) When tests timeout, report files on disk are incorrect
[ http://jira.codehaus.org/browse/SUREFIRE-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-468: -- Fix Version/s: 2.5 Summary: When tests timeout, report files on disk are incorrect (was: test timeout handling) When I run the timeout-forked integration test, it fails the Maven build, which is correct behavior. However, it seems to always generate the TXT file, and sometimes generates the XML file and sometimes not. (Seems like it usually doesn't generate XML when using mvn clean test, but usually does generate XML when using mvn clean mvn test.) In all cases, all of the files remaining on disk seem to suggest that the test passed. For example, the TXT file says Tests run: 1, Failures: 0, the XML file says testsuite failures=0 tests=1, etc. When tests timeout, report files on disk are incorrect -- Key: SUREFIRE-468 URL: http://jira.codehaus.org/browse/SUREFIRE-468 Project: Maven Surefire Issue Type: Bug Components: plugin, process forking Affects Versions: 2.4.2 Reporter: A Fix For: 2.5 When forkmode is always/prtest (probably that could be true for the last test and forkmode once) when one test hangs and timeout occurs, est suite execution stops and report file for the offending test not generated. That could mislead somebody to think all tests passed if all tests before the offending one passed. AFAICT that should be synchronized between one of these: 1. CommandLineUtils.executeCommandLine() 2. SurefireBooter.fork() 3. SurefireBooter.run() 4. SurefirePlugin.execute() Probably fork must detect a timeout. Then the timeout be gracefully handled by generating a report file for the test. Then continue execution of remaining tests. -- 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-472) Add support for view by groups in the surefire report
[ http://jira.codehaus.org/browse/SUREFIRE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-472: -- Fix Version/s: Future This would be handy. Probably more likely when we get group support for JUnit; in the meantime, we should probably just find a way to attach TestNG's HTML reports to Surefire reports. Add support for view by groups in the surefire report -- Key: SUREFIRE-472 URL: http://jira.codehaus.org/browse/SUREFIRE-472 Project: Maven Surefire Issue Type: Improvement Components: TestNG support Affects Versions: 2.4.2 Environment: Linux, java 1.6 Reporter: Erik Drolshammer Fix For: Future The group annotation in testng is really useful. It would be even more useful if Maven had a report that could show these groups. See mail thread on the testng list for details: http://forums.opensymphony.com/thread.jspa?messageID=334370tstart=0 I.e., something like the report in http://testng.org/test-output/index.html cannot be found in http://maven.apache.org/plugins/maven-surefire-report-plugin/surefire-report.html. -- 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-490) Provide an option to use simplified classloading
Provide an option to use simplified classloading Key: SUREFIRE-490 URL: http://jira.codehaus.org/browse/SUREFIRE-490 Project: Maven Surefire Issue Type: Improvement Components: classloading Reporter: Dan Fabulich Surefire is currently able to launch tests using a manifest-only jar, or by using a funky isolated classloader if useSystemClassLoader=true. But we currently don't provide a way to just use a plain old java classpath (POJC?) A POJC will often fail for Windows users; we should warn users to be careful with it, but provide it as an option where necessary. -- 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-490) Provide an option to use simplified classloading
[ http://jira.codehaus.org/browse/SUREFIRE-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-490: -- Fix Version/s: 2.5 Provide an option to use simplified classloading Key: SUREFIRE-490 URL: http://jira.codehaus.org/browse/SUREFIRE-490 Project: Maven Surefire Issue Type: Improvement Components: classloading Reporter: Dan Fabulich Fix For: 2.5 Surefire is currently able to launch tests using a manifest-only jar, or by using a funky isolated classloader if useSystemClassLoader=true. But we currently don't provide a way to just use a plain old java classpath (POJC?) A POJC will often fail for Windows users; we should warn users to be careful with it, but provide it as an option where necessary. -- 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-491) All system properties from Maven process are copied to forked Surefire process
All system properties from Maven process are copied to forked Surefire process -- Key: SUREFIRE-491 URL: http://jira.codehaus.org/browse/SUREFIRE-491 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.5 Reporter: Dan Fabulich Run a Surefire test with a different JVM using the -Djvm argument. For example, run the test with JDK 1.4 while running Maven with a 1.5 or 1.6 JVM. Examine the XML file in target/surefire-reports corresponding to your test. The java.* properties will match the parent process, not the forked process. For example, property name=java.version value=1.6.0_02/. -- 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: (SUREFIRE-461) -Xbootclasspath specified in argLine not passed to forked JVM
[ http://jira.codehaus.org/browse/SUREFIRE-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-461. - Resolution: Duplicate Yes, I can reproduce your test failure. In fact, I think this is just a special case of SUREFIRE-491. With that said, I believe that the boot class path *is* being modified, you just can't see it in Java system properties. -Xbootclasspath specified in argLine not passed to forked JVM --- Key: SUREFIRE-461 URL: http://jira.codehaus.org/browse/SUREFIRE-461 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.4, 2.4.1, 2.4.2 Reporter: Jason Voegele Attachments: surefire-argline-bug.tar.gz The 2.4.x versions of maven-surefire-plugin do not propagate the bootclasspath to the forked JVM that executes the tests. I have attached a sample project that demonstrates this problem. The sample application has a test case that verifies that the -Xbootclasspath parameter given in the argLine of the POM is properly passed to the JVM running the tests, but the test fails when using 2.4.x versions. If you modify the POM to use 2.3 version instead of 2.4.2, the tests pass. -- 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-491) All system properties from Maven process are copied to forked Surefire process
[ http://jira.codehaus.org/browse/SUREFIRE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=132897#action_132897 ] Dan Fabulich commented on SUREFIRE-491: --- This is happening due to the fix for SUREFIRE-121. I was afraid when I did this that it was risky: http://www.nabble.com/passing-system-properties-to-forked-test-td13947630.html I even included a comment in the code: [Is this wise?|http://svn.apache.org/viewvc/maven/surefire/trunk/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java?r1=598217r2=598216pathrev=598217] In hindsight, it was not wise; the initial implementation broke the embedder. Milos fixed that later, but it's still doing the wrong thing from the command line. I'm not exactly sure how to fix this without breaking the fix available in SUREFIRE-121...? All system properties from Maven process are copied to forked Surefire process -- Key: SUREFIRE-491 URL: http://jira.codehaus.org/browse/SUREFIRE-491 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.5 Reporter: Dan Fabulich Run a Surefire test with a different JVM using the -Djvm argument. For example, run the test with JDK 1.4 while running Maven with a 1.5 or 1.6 JVM. Examine the XML file in target/surefire-reports corresponding to your test. The java.* properties will match the parent process, not the forked process. For example, property name=java.version value=1.6.0_02/. -- 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: (SUREFIRE-476) Skipped test should not be considered as failed test
[ http://jira.codehaus.org/browse/SUREFIRE-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-476. - Resolution: Won't Fix I don't think this patch is logically correct. Logically, a test can have three results: pass, fail or skip. Unfortunately, most people assume that there are only two possible results (pass or fail); they furthermore assume that fail means the same thing as did not pass. I don't think we want an option to decide whether skip means fail or whether skip means pass. Skip is separate; it's not a success, and it's not a failure. If a test is skipped, then it is not a success. That doesn't mean it's a failure, but it also means that you don't have 100% success. Perhaps what you'd want is a separate failure percentage. If all tests are skipped, the pass percentage is 0 and the failure percentage is 0. Regardless, I'm pretty sure it's wrong to make the successful percentage be 100% when there are skipped tests, because those tests did not succeed. Skipped test should not be considered as failed test -- Key: SUREFIRE-476 URL: http://jira.codehaus.org/browse/SUREFIRE-476 Project: Maven Surefire Issue Type: Improvement Components: report plugin Affects Versions: 2.4.2 Reporter: Baptiste MATHUS Attachments: surefire-report-skippedIsSuccess.patch I guess the plugin should allow people to decide whether skipped test is the same as a failed test, as it is at the moment in the report plugin. As you know, with the surefire plugin (not the report one), a skipped test is not considered as a failed one, as it doesn't make the whole test phase fail, isn't it? So, I guess there should be at least an option to choose how to treat skipped tests when reporting. As a small modification, I'm attaching a small patch to not lower the success rate (for example, with two tests one successful, one skipped, the success rate stays 100%). This patch uses an option -DskippedIsFailed=false that lets the current behaviour be if you don't use this switch (the testcase was also updated to test this new switch). I think there could be a good idea to introduce a specific part in the report showing the skipped tests. What do you think? If you agree, I could try and propose a patch for it. Cheers. PS: the patch was applied against the 2.4.2 tag. If you want me to update it against another source version, please 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] Updated: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[ http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-482: -- Fix Version/s: 2.5 Surefire tries to run JUnit4 tests that contain no @Test annotations Key: SUREFIRE-482 URL: http://jira.codehaus.org/browse/SUREFIRE-482 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.4.2 Reporter: Mark Hobson Fix For: 2.5 Attachments: test.zip Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that contain no @Test annotations as tests, resulting in the exception: java.lang.Exception: No runnable methods at org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32) at org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43) at org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36) at org.junit.internal.runners.JUnit4ClassRunner.init(JUnit4ClassRunner.java:27) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) at org.apache.maven.surefire.junit4.JUnit4TestSet.init(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:156) 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.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Such classes should be ignored by 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] Created: (MNG-3556) XML entity not supported in Maven 2
XML entity not supported in Maven 2
---
Key: MNG-3556
URL: http://jira.codehaus.org/browse/MNG-3556
Project: Maven 2
Issue Type: Bug
Components: General
Reporter: Dan Fabulich
Attachments: pom.xml
The attached XML file defines and uses an XML entity called amp;blah;. It
validates in FF and in other XML parsers, but when I attempt to load it up in
Maven, I get the fellowing exception:
{code}
[INFO] Scanning for projects...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: unknown
POM Location: C:\blah\pom.xml
Reason: Parse error reading POM. Reason: could not resolve entity named 'blah'
(position: START_TAG seen .../version\r\n nameblah;... @11:15) for
project unknown at C:\blah\pom.xml
[INFO]
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Parse error reading POM.
Reason: could not resolve entity named 'blah' (position: START_TAG seen
.../version\r\n nameblah;... @11:15) for project unknown at
C:\blah\pom.xml
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.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.project.InvalidProjectModelException: Parse error
reading POM. Reason: could not resolve entity named 'blah' (position: START_TAG
seen .../version\r\n nameblah;... @11:15) for project unknown at
C:\blah\pom.xml
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1416)
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1377)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:474)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362)
... 11 more
Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: could not
resolve entity named 'blah' (position: START_TAG seen .../version\r\n
nameblah;... @11:15)
at
org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1282)
at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1093)
at
org.codehaus.plexus.util.xml.pull.MXParser.nextText(MXParser.java:1058)
at
org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Reader.java:2050)
at
org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4422)
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1412)
... 17 more
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Mon Apr 28 14:43:06 PDT 2008
[INFO] Final Memory: 1M/4M
[INFO]
{code}
--
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: (SUREFIRE-486) Exlude tests via an external exlude file
[ http://jira.codehaus.org/browse/SUREFIRE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-486. - Resolution: Won't Fix I don't think that's the feature you want; there's a better way to do it. JUnit 4 includes a @Ignore annotiation; TestNG allows you to have your tests throw a SkipException which does something similar. That will keep the tests in the report, but mark them as yellow or skipped. If we excluded known bugs entirely, they would simply disappear from the report. Exlude tests via an external exlude file Key: SUREFIRE-486 URL: http://jira.codehaus.org/browse/SUREFIRE-486 Project: Maven Surefire Issue Type: New Feature Reporter: Thomas Diesler Similar to Ant, Surefire should support excludes defined in an external file like this testExcludes excludeFiletest-excludes-jboss501.txt/excludeFile /testExcludes The exclude file would look like this # [JBWS-2135] WebServiceException: Undefined port type org/jboss/test/ws/jaxws/jbws1822/** # [JBWS-2136] ClassCastException: com.sun.xml.ws.server.EndpointMessageContextImpl org/jboss/test/ws/jaxws/namespace/** # [JBAS-5359] mapped-name is required for context of deployment org/jboss/test/ws/jaxws/jbws1611/** -- 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-479) @BeforeClass and @AfterClass on parent class are not executed
[
http://jira.codehaus.org/browse/SUREFIRE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich updated SUREFIRE-479:
--
Attachment: surefire479.zip
@BeforeClass and @AfterClass on parent class are not executed
-
Key: SUREFIRE-479
URL: http://jira.codehaus.org/browse/SUREFIRE-479
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.4.2
Reporter: Erik Putrycz
Attachments: surefire479.zip
I have
public abstract class A {
@BeforeClass
public void init() {...}
@AfterClass
public void cleanup() {...}
}
and
@Test
public class TestA extends A {
public void testSomething() {...}
}
when surefire executes testSomething, the @BeforeClass and @AfterClass are
never being called. I have testng 5.7.
--
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: (SUREFIRE-479) @BeforeClass and @AfterClass on parent class are not executed
[
http://jira.codehaus.org/browse/SUREFIRE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed SUREFIRE-479.
-
Resolution: Cannot Reproduce
I can't reproduce this. I've attached a sample Maven project that follows your
guidelines with println commands in init, cleanup and testSomething. When I
run mvn test in that project, I see:
init
something
cleanup
which tells me that TestNG is working correctly. If you don't see that in your
output, please reopen the bug.
@BeforeClass and @AfterClass on parent class are not executed
-
Key: SUREFIRE-479
URL: http://jira.codehaus.org/browse/SUREFIRE-479
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.4.2
Reporter: Erik Putrycz
Attachments: surefire479.zip
I have
public abstract class A {
@BeforeClass
public void init() {...}
@AfterClass
public void cleanup() {...}
}
and
@Test
public class TestA extends A {
public void testSomething() {...}
}
when surefire executes testSomething, the @BeforeClass and @AfterClass are
never being called. I have testng 5.7.
--
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-465) Add numeric option for forkmode param
[ http://jira.codehaus.org/browse/SUREFIRE-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-465: -- Fix Version/s: Future Perhaps more plausible might be to fork a process on a per-package basis. Add numeric option for forkmode param - Key: SUREFIRE-465 URL: http://jira.codehaus.org/browse/SUREFIRE-465 Project: Maven Surefire Issue Type: Improvement Components: process forking Reporter: Eric Smalling Priority: Minor Fix For: Future PermGen memory becomes very full for large sets of junits. So much so that unless I turn on forkmodepertest/forkmode I have to up my MaxPermGen to over 300m (we have 2600+ tests) Since that slows the tests to a crawl, and since using that much perm space causes problems with virtual memory paging I'd like to see if an option to fork on every n-th test could be added. ie: forkmode100/forkmode would create a new fork for every 100 tests. I'll dl the source and see if i can submit a patch here too. -- 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
