[jira] Commented: (MCHECKSTYLE-42) checkstyle does not take into account proxy settings from settings.xml
[ http://jira.codehaus.org/browse/MCHECKSTYLE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=144776#action_144776 ] Stephen Connolly commented on MCHECKSTYLE-42: - It makes publishing a org.codehaus.mojo plugin project site from behind a proxy very difficult checkstyle does not take into account proxy settings from settings.xml -- Key: MCHECKSTYLE-42 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-42 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Feniks Nator I've been hesitating wether to report it as bug or as improvement, but at the moment I'd rate it as a bug. It took me quite some time to figure out why this was going wrong. In my settings.xml I've defined our company proxysettings. These settings are used by Maven when connecting to the remote repository. However when using the checkstyle plugin as part of the site generation I can not obtain our checkstyle.xml which is available via http. I found a solution by adding the following parameters on the command line when continuum launches maven: -Dhttp.proxyHost=myproxy -Dhttp.proxyPort=80 Wouldn't it be possible for the maven checkstyle plugin to use the settings defined in settings.xml, so I've only to define those once? FYI the error generated: [INFO] Generate Dependencies report. [INFO] Generate Issue Tracking report. [INFO] Generate Project License report. [INFO] Generate Mailing Lists report. [INFO] Generate Source Repository report. [INFO] Generate Project Team report. [INFO] Generate Maven Surefire Report report. [INFO] Generate Checkstyle report. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during report generation Embedded error: Unable to find configuration file location. http://spirou.mycompany.be/javadev/install/checkstyle/mycompany-checkstyle-1.5.xml [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error during report generation at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error during report generation at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:389) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.reporting.MavenReportException: Unable to find configuration file location. at org.apache.maven.plugin.checkstyle.CheckstyleReport.getConfigFile(CheckstyleReport.java:879) at org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:466) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) at org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.java:802) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:301) ... 18 more Caused by:
[jira] Moved: (MENFORCER-51) build failure in case of available updates
[ http://jira.codehaus.org/browse/MENFORCER-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly moved MVERSIONS-4 to MENFORCER-51: --- Key: MENFORCER-51 (was: MVERSIONS-4) Project: Maven 2.x Enforcer Plugin (was: Maven 2.x Versions Plugin) build failure in case of available updates -- Key: MENFORCER-51 URL: http://jira.codehaus.org/browse/MENFORCER-51 Project: Maven 2.x Enforcer Plugin Issue Type: Wish Reporter: Tomasz Pik It would be useful to have a possibility to fail build if there's an update of given dependency. In some way it would 'solve' problem of 'how to depend of latest stable version of my company parent pom' problem - build would just not pass if there's an update. -- 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-51) build failure in case of available updates
[ http://jira.codehaus.org/browse/MENFORCER-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=147195#action_147195 ] Stephen Connolly commented on MENFORCER-51: --- I moved this to enforcer from versions-maven-plugin because fundamentally I believe this wisk to beout of scope for the versions maven plugin. The enforcer plugin is responsible for failing the build if things need to be enforced. I may be able to write a patch to implement this in the standard rules in the next couple of days if nobody else writes one first! build failure in case of available updates -- Key: MENFORCER-51 URL: http://jira.codehaus.org/browse/MENFORCER-51 Project: Maven 2.x Enforcer Plugin Issue Type: Wish Reporter: Tomasz Pik It would be useful to have a possibility to fail build if there's an update of given dependency. In some way it would 'solve' problem of 'how to depend of latest stable version of my company parent pom' problem - build would just not pass if there's an update. -- 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] Issue Comment Edited: (MENFORCER-51) build failure in case of available updates
[ http://jira.codehaus.org/browse/MENFORCER-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=147195#action_147195 ] stephenconnolly edited comment on MENFORCER-51 at 9/8/08 12:44 AM: I moved this to enforcer from versions-maven-plugin because fundamentally I believe this wish to be out of scope for the versions maven plugin. The enforcer plugin is responsible for failing the build if things need to be enforced. I may be able to write a patch to implement this in the standard rules in the next couple of days if nobody else writes one first! was (Author: stephenconnolly): I moved this to enforcer from versions-maven-plugin because fundamentally I believe this wisk to beout of scope for the versions maven plugin. The enforcer plugin is responsible for failing the build if things need to be enforced. I may be able to write a patch to implement this in the standard rules in the next couple of days if nobody else writes one first! build failure in case of available updates -- Key: MENFORCER-51 URL: http://jira.codehaus.org/browse/MENFORCER-51 Project: Maven 2.x Enforcer Plugin Issue Type: Wish Reporter: Tomasz Pik It would be useful to have a possibility to fail build if there's an update of given dependency. In some way it would 'solve' problem of 'how to depend of latest stable version of my company parent pom' problem - build would just not pass if there's an update. -- 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] (MNG-5280) Inconsistent order of repositories and pluginRepositories from profiles in settings (regression Maven 3)
[ https://jira.codehaus.org/browse/MNG-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306338#comment-306338 ] Stephen Connolly commented on MNG-5280: --- Integration test added to core it suite in r1373759 Inconsistent order of repositories and pluginRepositories from profiles in settings (regression Maven 3) Key: MNG-5280 URL: https://jira.codehaus.org/browse/MNG-5280 Project: Maven 2 3 Issue Type: Bug Components: Settings Affects Versions: 3.0.3, 3.0.4 Environment: Mac OS 10.7 and Windows XP Java 1.6.0 Reporter: Anders Hammar Attachments: fake-maven-plugin-1.0.jar, MNG-5280-IT.patch, MNG-5280-maven-model-builder.patch Repositories and pluginRepositories defined in profiles in settings.xml are not order consistently. This is a regression compared to Maven 2. Scenario: * Settings.xml defines two profiles, A and B (in this order). * Both profiles define a repository and a pluginRepository, A-repo/A-pluginrepo and B-repo/B-pluginrepo respectively. When checking the effective pom (help:effective-pom) the resulting list of repositories and pluginRepositories shows that they are not ordered consistently. The order is B-repo, A-repo and A-pluginrepo, B-pluginrepo respectively. With Maven 2.2.1 they are ordered consistently (and what I argue is correct): B-repo, A-repo and B-pluginrepo, A-pluginrepo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5280) Inconsistent order of repositories and pluginRepositories from profiles in settings (regression Maven 3)
[ https://jira.codehaus.org/browse/MNG-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MNG-5280. - Resolution: Fixed Fix Version/s: 3.0.5 r1373761 Inconsistent order of repositories and pluginRepositories from profiles in settings (regression Maven 3) Key: MNG-5280 URL: https://jira.codehaus.org/browse/MNG-5280 Project: Maven 2 3 Issue Type: Bug Components: Settings Affects Versions: 3.0.3, 3.0.4 Environment: Mac OS 10.7 and Windows XP Java 1.6.0 Reporter: Anders Hammar Fix For: 3.0.5 Attachments: fake-maven-plugin-1.0.jar, MNG-5280-IT.patch, MNG-5280-maven-model-builder.patch Repositories and pluginRepositories defined in profiles in settings.xml are not order consistently. This is a regression compared to Maven 2. Scenario: * Settings.xml defines two profiles, A and B (in this order). * Both profiles define a repository and a pluginRepository, A-repo/A-pluginrepo and B-repo/B-pluginrepo respectively. When checking the effective pom (help:effective-pom) the resulting list of repositories and pluginRepositories shows that they are not ordered consistently. The order is B-repo, A-repo and A-pluginrepo, B-pluginrepo respectively. With Maven 2.2.1 they are ordered consistently (and what I argue is correct): B-repo, A-repo and B-pluginrepo, A-pluginrepo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MAVEN-1871) Xircles signup screen should not allow xircles usernames with . in the name
Stephen Connolly created MAVEN-1871: --- Summary: Xircles signup screen should not allow xircles usernames with . in the name Key: MAVEN-1871 URL: https://jira.codehaus.org/browse/MAVEN-1871 Project: Maven 1 Issue Type: Bug Reporter: Stephen Connolly Now that jira account creation is via xircles, need to ensure that only valid jira usernames get accepted for xircles account names -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5358) Install Plugin installs poms that contain variables in artifact version and parent version
[ https://jira.codehaus.org/browse/MNG-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MNG-5358. - Resolution: Not A Bug Property substitution is not supported at the following XPath locations /project/parent/groupId /project/parent/artifactId /project/parent/version /project/groupId /project/artifactId /project/version /project/packaging Doe in part to Maven Core currently requiring that the unresolved POM be deployed to the remote repository (or else inheritance fails) and when used as a dependency the properties supplied at original build time will not be available to the depending project. One attempt at solving this issue was to resolve the properties in the pom before installing/deploying but that broke a bunch of projects that relied on overriding properties to control the version specified in dependencyManagement among other things. This one of the reasons why Maven 2.1.0 and 2.2.0 are not recommended for use. Install Plugin installs poms that contain variables in artifact version and parent version -- Key: MNG-5358 URL: https://jira.codehaus.org/browse/MNG-5358 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories, Deployment Affects Versions: 3.0.3 Reporter: Christofer Dutz Attachments: module1-1.2-SNAPSHOT.pom, module2-1.2-SNAPSHOT.pom, TestProject-1.2-SNAPSHOT.pom, Test.zip I am currently trying to create a build process that is optimized for being able to have individual modules of one project deployed with different versions. Therefore I created a build that uses properties for providing the version numbers for artifacts, dependencies and parent relations. The build is working nicely, unfortunately the install plugin installs the artifacts into the correct directories, but it doesn't replace the properties. This way the repo contains artifacts it can certainly not resolve ich a user checks out only part of the project. I created a small test-project. If you simply mvn install it you will see the problematic results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5358) Install Plugin installs poms that contain variables in artifact version and parent version
[
https://jira.codehaus.org/browse/MNG-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311513#comment-311513
]
Stephen Connolly commented on MNG-5358:
---
let me rephrase.
The quick solution was to resolve *all* properties in the pom. That breaks
stuff.
Take for example the case where a parent pom defines a dependencyManagement,
e.g.
{code}
project
groupIdg/groupId
artifactIda/artifactId
version1/version
properties
foo.version1.0/foo.version
/properties
dependencyManagement
dependencies
dependency
groupIdfoo/groupId
artifactIdmanchu/artifactId
version${foo.version}/version
/dependency
dependency
groupIdfoo/groupId
artifactIdbar/artifactId
version${foo.version}/version
/dependency
/dependencies
/dependencyManagement
/project
{code}
If there is then a child module *that wants to use a newer version of the foo
dependencies* it can currently do like so:
{code}
project
parent
groupIdg/groupId
artifactIda/artifactId
version1/version
/parent
artifactIdb/artifactId
properties
foo.version1.1/foo.version
/properties
dependencies
dependency
groupIdfoo/groupId
artifactIdmanchu/artifactId
/dependency
dependency
groupIdfoo/groupId
artifactIdbar/artifactId
/dependency
/dependencies
/project
{code}
Now I am not commenting on whether the above is good practice, but there are
enough projects out there that we cannot cause the above to break, so we end up
with the quick solution of deploying a fully resolved pom being unworkable as
it would break backwards compatibility with existing projects.
Install Plugin installs poms that contain variables in artifact version and
parent version
--
Key: MNG-5358
URL: https://jira.codehaus.org/browse/MNG-5358
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories, Deployment
Affects Versions: 3.0.3
Reporter: Christofer Dutz
Attachments: module1-1.2-SNAPSHOT.pom, module2-1.2-SNAPSHOT.pom,
TestProject-1.2-SNAPSHOT.pom, Test.zip
I am currently trying to create a build process that is optimized for being
able to have individual modules of one project deployed with different
versions. Therefore I created a build that uses properties for providing the
version numbers for artifacts, dependencies and parent relations. The build
is working nicely, unfortunately the install plugin installs the artifacts
into the correct directories, but it doesn't replace the properties. This way
the repo contains artifacts it can certainly not resolve ich a user checks
out only part of the project.
I created a small test-project. If you simply mvn install it you will see
the problematic results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5387) Add ability to replace an artifact in mid-build
[ https://jira.codehaus.org/browse/MNG-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=314338#comment-314338 ] Stephen Connolly commented on MNG-5387: --- I agree with last wins. The only gotcha-cconcern I have is the forked life cycles. Specifically a cobertura or clover forked life cycle. If the forked life cycle doesn't splat over then it's fine Add ability to replace an artifact in mid-build --- Key: MNG-5387 URL: https://jira.codehaus.org/browse/MNG-5387 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.1.0 Reporter: Benson Margulies Assignee: Benson Margulies To clean up how the shade plugin works, we need an API to allow it to say, 'please replace the jar file that the jar plugin has given you with this other one here.' It turns out we already more or less have this method, due to a collection of historical conflict. At some point in time, http://jira.codehaus.org/browse/MNG-3119 called for Maven to reject more than one call to attach the same artifact to the build. However, this proved an unacceptable incompatibility at the time. Instead, under http://jira.codehaus.org/browse/MNG-4013, Maven was changed to log but otherwise ignore all calls to 'addArtifact' on MavenProject after the first for a G/A/V/C/T coordinate. This decision to take 'first wins' instead of 'last wins' doesn't help much of anyone. It prevents something like shade from intentionally displacing an earlier execution's results, and while it doesn't produce backtraces, ever, it can still be entirely confusing. Under this JIRA, I'm switching to 'last one wins'. This could still be confusing, and someone might argue that there should be some way to distinguish casual and incorrect user config that results in two plugins trying to deliver the same thing from something intentional. On the other hand, if two plugins are configured to attach the same G/A/V/C, having the last one win makes more sense, and has the effect of enabling the desired behavior in shade. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5185) Improve missing dependency error message when _maven.repositories contains other repository ids than requested
[
https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=320559#comment-320559
]
Stephen Connolly commented on MNG-5185:
---
Thinking about this some more, what users probably want is a way to mark
specific repository ids as offline.
Most of the cases where -Dmaven.legacyLocalRepository is required are, IMHO,
where the user is not connected to the corporate VPN and so resolution against
the corporate repo should not be attempted because it is offline
The legacy behaviour is really a global switch for all repositories, much
better IMHO is
{code}
-Dmaven.repositories.offline=central,java.net2,...
{code}
or
{code}
-Dmaven.repository.offline.central
-Dmaven.repository.offline.java.net2
{code}
Now it may not be possible to implement this way with the current Aether, but I
think this is more the solution we should be heading towards.
Another way would be to have a repository-status file on disk that contained
the list of repository id's and their on-line/off-line status... or even an
extension to allow querying... so that users could plug a vpn status detector
into their maven installation and have auto-just-works
Improve missing dependency error message when _maven.repositories contains
other repository ids than requested
Key: MNG-5185
URL: https://jira.codehaus.org/browse/MNG-5185
Project: Maven 2 3
Issue Type: Improvement
Affects Versions: 3.0.2, 3.0.3, 3.0.4
Reporter: Mark Derricutt
Assignee: Olivier Lamy
Fix For: 3.1.0
Attachments:
0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch
Based on a discussion on the users list [1], Maven 3 has changed how it
resolves artifacts from remote repositories. Unfortunately, when conflicts
arise ( GAV is cached in local repo, but POM has no matching repository id
declared ), Maven just tells the user that the artifact could not be resolved.
This leads to confusion from users who find the .jar files in their local
repository, and they just get frustrated and complain that maven sucks.
It would be good if Maven was updated with some improved error messages along
the lines of:
The {GAV} artifact was found in your local repository, but came from the
undeclared repository xxx, either configure this in your pom with {insert
sample XML block in error message}, or in your yyy mirror.
The mirror section of the error message should be included -if- the current
~/.m2/settings.xml declares a mirror. By improving the messages here we can
help the users move on to building software, rather than pulling out their
hair :)
[1]
http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
--
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] (MNG-5185) Improve missing dependency error message when _maven.repositories contains other repository ids than requested
[
https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=320577#comment-320577
]
Stephen Connolly commented on MNG-5185:
---
Your corporate repository has an ID, so when off-VPN you would just go
{code}
-Dmaven.repository.offline.corp-mirror
{code}
And then all your corporate artifacts will not be attempted to re-download...
oh that repo is missing... oh fail the build.
-Dmaven.legacyLocalRepository is just a hack on top of a hack, what I am
pointing is a solution to the first hack that removes the need for the second.
Improve missing dependency error message when _maven.repositories contains
other repository ids than requested
Key: MNG-5185
URL: https://jira.codehaus.org/browse/MNG-5185
Project: Maven 2 3
Issue Type: Improvement
Affects Versions: 3.0.2, 3.0.3, 3.0.4
Reporter: Mark Derricutt
Assignee: Olivier Lamy
Fix For: 3.1.0
Attachments:
0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch
Based on a discussion on the users list [1], Maven 3 has changed how it
resolves artifacts from remote repositories. Unfortunately, when conflicts
arise ( GAV is cached in local repo, but POM has no matching repository id
declared ), Maven just tells the user that the artifact could not be resolved.
This leads to confusion from users who find the .jar files in their local
repository, and they just get frustrated and complain that maven sucks.
It would be good if Maven was updated with some improved error messages along
the lines of:
The {GAV} artifact was found in your local repository, but came from the
undeclared repository xxx, either configure this in your pom with {insert
sample XML block in error message}, or in your yyy mirror.
The mirror section of the error message should be included -if- the current
~/.m2/settings.xml declares a mirror. By improving the messages here we can
help the users move on to building software, rather than pulling out their
hair :)
[1]
http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
--
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] Created: (MINVOKER-76) Have invoker:run generate report files to allow reporting on the results of running invoker
Have invoker:run generate report files to allow reporting on the results of running invoker --- Key: MINVOKER-76 URL: http://jira.codehaus.org/browse/MINVOKER-76 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Reporter: Stephen Connolly Attachments: patch.diff The attached patch will adds generation of basic XML reports for each invoker run. This will allow other tools to report on the trends and the number of successes / failures. If this patch gets picked up I'll have a Hudson plugin to read these reports and I can also write a Maven reporting plugin to integrate with site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINVOKER-76) Have invoker:run generate report files to allow reporting on the results of running invoker
[ http://jira.codehaus.org/browse/MINVOKER-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162373#action_162373 ] Stephen Connolly commented on MINVOKER-76: -- point me at an example and I'll rewrite the patch Have invoker:run generate report files to allow reporting on the results of running invoker --- Key: MINVOKER-76 URL: http://jira.codehaus.org/browse/MINVOKER-76 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Reporter: Stephen Connolly Attachments: patch.diff The attached patch will adds generation of basic XML reports for each invoker run. This will allow other tools to report on the trends and the number of successes / failures. If this patch gets picked up I'll have a Hudson plugin to read these reports and I can also write a Maven reporting plugin to integrate with site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINVOKER-76) Have invoker:run generate report files to allow reporting on the results of running invoker
[ http://jira.codehaus.org/browse/MINVOKER-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162431#action_162431 ] Stephen Connolly commented on MINVOKER-76: -- Hey, I'm stuck in no-commit-access land when it's apache... if you guys are going refactoring it'll be impossible for me to get a patch together. Any chance of some coordination as I'd like to get some patches accepted for apache at some stage! ;-) Have invoker:run generate report files to allow reporting on the results of running invoker --- Key: MINVOKER-76 URL: http://jira.codehaus.org/browse/MINVOKER-76 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Reporter: Stephen Connolly Assignee: Olivier Lamy Fix For: 1.4 Attachments: patch.diff The attached patch will adds generation of basic XML reports for each invoker run. This will allow other tools to report on the trends and the number of successes / failures. If this patch gets picked up I'll have a Hudson plugin to read these reports and I can also write a Maven reporting plugin to integrate with site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINVOKER-76) Have invoker:run generate report files to allow reporting on the results of running invoker
[ http://jira.codehaus.org/browse/MINVOKER-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162432#action_162432 ] Stephen Connolly commented on MINVOKER-76: -- By the way, i'm happy to do BB's refactoring and produce an uber-patch Have invoker:run generate report files to allow reporting on the results of running invoker --- Key: MINVOKER-76 URL: http://jira.codehaus.org/browse/MINVOKER-76 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Reporter: Stephen Connolly Assignee: Olivier Lamy Fix For: 1.4 Attachments: patch.diff The attached patch will adds generation of basic XML reports for each invoker run. This will allow other tools to report on the trends and the number of successes / failures. If this patch gets picked up I'll have a Hudson plugin to read these reports and I can also write a Maven reporting plugin to integrate with site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINVOKER-76) Have invoker:run generate report files to allow reporting on the results of running invoker
[ http://jira.codehaus.org/browse/MINVOKER-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162433#action_162433 ] Stephen Connolly commented on MINVOKER-76: -- And another addition to the data model I want is to copy the contents of /project/name and /project/description from each pom that is invoked so that we have a sensible place to keep documentation of the tests Have invoker:run generate report files to allow reporting on the results of running invoker --- Key: MINVOKER-76 URL: http://jira.codehaus.org/browse/MINVOKER-76 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Reporter: Stephen Connolly Assignee: Olivier Lamy Fix For: 1.4 Attachments: patch.diff The attached patch will adds generation of basic XML reports for each invoker run. This will allow other tools to report on the trends and the number of successes / failures. If this patch gets picked up I'll have a Hudson plugin to read these reports and I can also write a Maven reporting plugin to integrate with site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINVOKER-76) Have invoker:run generate report files to allow reporting on the results of running invoker
[ http://jira.codehaus.org/browse/MINVOKER-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162437#action_162437 ] Stephen Connolly commented on MINVOKER-76: -- Yeah, but 1. JXR will cross-link to the unit test source code 2. JUnit tests are usually more descriptive that it-104 Another alternative is if there is a plain text file with a magic name, we use that as the description of the test but I think reading the pom if it is there is simpler Have invoker:run generate report files to allow reporting on the results of running invoker --- Key: MINVOKER-76 URL: http://jira.codehaus.org/browse/MINVOKER-76 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Reporter: Stephen Connolly Assignee: Olivier Lamy Fix For: 1.4 Attachments: patch.diff The attached patch will adds generation of basic XML reports for each invoker run. This will allow other tools to report on the trends and the number of successes / failures. If this patch gets picked up I'll have a Hudson plugin to read these reports and I can also write a Maven reporting plugin to integrate with site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINVOKER-76) Have invoker:run generate report files to allow reporting on the results of running invoker
[ http://jira.codehaus.org/browse/MINVOKER-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162438#action_162438 ] Stephen Connolly commented on MINVOKER-76: -- we could add a property to invoker.properties... invoker.description=Blah blah blah Have invoker:run generate report files to allow reporting on the results of running invoker --- Key: MINVOKER-76 URL: http://jira.codehaus.org/browse/MINVOKER-76 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Reporter: Stephen Connolly Assignee: Olivier Lamy Fix For: 1.4 Attachments: patch.diff The attached patch will adds generation of basic XML reports for each invoker run. This will allow other tools to report on the trends and the number of successes / failures. If this patch gets picked up I'll have a Hudson plugin to read these reports and I can also write a Maven reporting plugin to integrate with site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINVOKER-80) introduce some simple bean to hold/collect the data/state of a project instead of passing its path, duration, error etc. around as individual variables
introduce some simple bean to hold/collect the data/state of a project instead of passing its path, duration, error etc. around as individual variables --- Key: MINVOKER-80 URL: http://jira.codehaus.org/browse/MINVOKER-80 Project: Maven 2.x Invoker Plugin Issue Type: Sub-task Affects Versions: 1.4 Reporter: Stephen Connolly http://jira.codehaus.org/browse/MINVOKER-76?focusedCommentId=162425page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_162425 -- 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: (MINVOKER-76) Have invoker:run generate report files to allow reporting on the results of running invoker
[ http://jira.codehaus.org/browse/MINVOKER-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MINVOKER-76: - Attachment: new-patch.diff New patch using mdo file and refactoring per MINVOKER-80 Have invoker:run generate report files to allow reporting on the results of running invoker --- Key: MINVOKER-76 URL: http://jira.codehaus.org/browse/MINVOKER-76 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Reporter: Stephen Connolly Assignee: Olivier Lamy Fix For: 1.4 Attachments: new-patch.diff, patch.diff The attached patch will adds generation of basic XML reports for each invoker run. This will allow other tools to report on the trends and the number of successes / failures. If this patch gets picked up I'll have a Hudson plugin to read these reports and I can also write a Maven reporting plugin to integrate with site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MINVOKER-76) Have invoker:run generate report files to allow reporting on the results of running invoker
[ http://jira.codehaus.org/browse/MINVOKER-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MINVOKER-76: - Attachment: new-patch.diff I realised that the new file (i.e. the mdo) was missing the ASL license header... this patch fixes that oversight Have invoker:run generate report files to allow reporting on the results of running invoker --- Key: MINVOKER-76 URL: http://jira.codehaus.org/browse/MINVOKER-76 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Reporter: Stephen Connolly Assignee: Olivier Lamy Fix For: 1.4 Attachments: new-patch.diff, new-patch.diff, patch.diff The attached patch will adds generation of basic XML reports for each invoker run. This will allow other tools to report on the trends and the number of successes / failures. If this patch gets picked up I'll have a Hudson plugin to read these reports and I can also write a Maven reporting plugin to integrate with site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINVOKER-80) introduce some simple bean to hold/collect the data/state of a project instead of passing its path, duration, error etc. around as individual variables
[ http://jira.codehaus.org/browse/MINVOKER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MINVOKER-80. Resolution: Fixed fixed with patch applied in [MINVOKER-76] introduce some simple bean to hold/collect the data/state of a project instead of passing its path, duration, error etc. around as individual variables --- Key: MINVOKER-80 URL: http://jira.codehaus.org/browse/MINVOKER-80 Project: Maven 2.x Invoker Plugin Issue Type: Sub-task Affects Versions: 1.4 Reporter: Stephen Connolly http://jira.codehaus.org/browse/MINVOKER-76?focusedCommentId=162425page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_162425 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=169447#action_169447
]
Stephen Connolly commented on SCM-406:
--
There are some reports I saw a month back on the subversion mailing list that
this is an issue with the neon transport. If you use the serf transport the
problem goes away.
AFAIK the situation is as follows:
svn:// always works
svn+ssh:// always works
http:// only works with serf (I have not confirmed this yet)
https:// only works with serf (I have not confirmed this yet)
scm tag does not work with Subversion 1.5.1
---
Key: SCM-406
URL: http://jira.codehaus.org/browse/SCM-406
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-svn
Affects Versions: 1.0
Reporter: James William Dumay
Fix For: 1.1.1
scm:checkin does not work with Subversion 1.5.1
On release:perform (which I assume calls scm:checkin) the following error
occurs:
{code}
svn: File
'/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
already exists
{code}
Using subversion 1.4.x is a good enough workaround.
--
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] Moved: (MNG-4124) mvn --version returns OS name: windows nt (unknown)
[ http://jira.codehaus.org/browse/MNG-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly moved MVERSIONS-27 to MNG-4124: Complexity: Intermediate Key: MNG-4124 (was: MVERSIONS-27) Project: Maven 2 (was: Maven 2.x Versions Plugin) mvn --version returns OS name: windows nt (unknown) -- Key: MNG-4124 URL: http://jira.codehaus.org/browse/MNG-4124 Project: Maven 2 Issue Type: Bug Reporter: Josef Stadelmann Priority: Minor C:\mvn --version Maven version: 2.0.10 Java version: 1.5.0_09 OS name: windows nt (unknown) version: 6.0 arch: x86 Family: windows C:\ that is what I get when I run mvn from a Microsoft Windows Vista System Josef -- 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: (MJAR-54) Update dependency on maven-archiver past 2.0
Update dependency on maven-archiver past 2.0 Key: MJAR-54 URL: http://jira.codehaus.org/browse/MJAR-54 Project: Maven 2.x Jar Plugin Issue Type: Bug Reporter: Stephen Connolly The current version of maven-plugin-jar has a dependency on org.apache.maven.maven-archiver version 2.0 org.apache.maven.maven-archiver 2.0.1 allows the configuration item: addMavenDescriptor to be specified while version 2.0 does not At the moment I am using a work-around by hand editing the pom in my local repository, but this should not be necessary. Can somebody do even a minor point release with the dependency updated to at least 2.0.1 (which is what the current release of the maven-war-plugin is using) -- 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: (MIDEA-64) Provided dependencies are also copied to /WEB-INF/lib
[ http://jira.codehaus.org/browse/MIDEA-64?page=comments#action_75996 ] Stephen Connolly commented on MIDEA-64: --- I can confirm this bug exists in IDEA 4.5.4, IDEA 5.1.2, and IDEA 6.0 beta. In all cases I regenerated the IDEA project files mvn idea:clean mvn idea:idea before loading in the IDE in order to eliminate contamination between IDEA versions. In our case the dependency in our pom.xml is: dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version scopeprovided/scope /dependency I have checked all the poms for all of our dependencies and any that list servlet-api as a dependency also have scope set to provided. In all three versions of the IDE the WAR packaging is incorrectly set to Copy files to. Provided dependencies are also copied to /WEB-INF/lib - Key: MIDEA-64 URL: http://jira.codehaus.org/browse/MIDEA-64 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Geoffrey De Smet Attachments: screenshot-1.jpg A dependency with the scope provided (and probably system too) is also marked as to be copied to /WEB-INF/lib for webapp modules. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-71) Implement accurev provider
[ http://jira.codehaus.org/browse/SCM-71?page=comments#action_79569 ] Stephen Connolly commented on SCM-71: - Have a look at: https://accurev4idea.dev.java.net/ Apache Software License Has implementation of accurev as an api that is mostly abstracted from intellij's api Could save most of the work... Note: I am currently trying to implement maven scm provider for accurev this but my employers will not let me commit back without arguing with legal for a long long time :-( Implement accurev provider -- Key: SCM-71 URL: http://jira.codehaus.org/browse/SCM-71 Project: Maven SCM Issue Type: New Feature Reporter: Emmanuel Venisse I look at documentation, and it's very easy to do (works like cvs or svn) http://www.accurev.com/download/docs/AccuRev_User_CLI.pdf -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-71) Implement accurev provider
[ http://jira.codehaus.org/browse/SCM-71?page=comments#action_79682 ] Stephen Connolly commented on SCM-71: - The big road-block as I see it is how to integrate AccuRev's depot/stream/workspace model with maven's scm model. the scm ulr should be something like: scm:accurev:server:port/depot/stream/path_to_module AccuRev requires that all changes be implemented in a workspace. We can auto discover the workspace once we know what host we are on and the server/depot/stream details. We can force the user to create the workspace for themselves to prevent accumulation of temporary workspaces and the cluttering up of the stream namespace (all streams must have a unique name, and workspaces are also streams. you cannot delete streams, only hide them, so a temporary workspace will not do) The workspace is rooted at scm:accurev:server:port/depot/stream/ so if we have a module that is at scm:accurev:server:port/depot/main_stream/my_app/my_core/my_module the workspace will be rooted at, say c:\workspaces\main_stream_sconnolly\ the pom.xml will be in c:\workspaces\main_stream_sconnolly\my_app\my_core\my_module\ You cannot put a workspace inside another workspace, so when the release plugin tries to check-out a copy of the source tree we will have to move our workspace to the directory that the release plugin wants us to check-out into... release is going to want us to checkout into c:\workspaces\main_stream_sconnolly\my_app\my_core\my_module\target\temp so we move the workspace to there, and now we populate only the module we are using accurev pop -R my_app\my_core\my_module and now we have the clean checked-out pom.xml in c:\workspaces\main_stream_sconnolly\my_app\my_core\my_module\target\temp\my_app\my_core\my_module but the release plugin (afaik) is thinking that it's in c:\workspaces\main_stream_sconnolly\my_app\my_core\my_module\target\temp I am also unsure where/how to store the state info about the workspace while the release plugin is doing it's thing... i.e. in order to check-out the tagged module, you need to move the workspace stream into the snapshot stream... and when you are finished, you need to move it back to where it was before the release plugin runs... (both in terms of the local file system base for the workspace, and the accurev stream base for the workspace [the stream base will come from the scm url, but the problem lies in figuring out which workspace to move back and where it's base will be, i.e. should it be c:\workspaces\main_stream_sconnolly\my_app\my_core\ or c:\workspaces\main_stream_sconnolly\ if it is not c:\workspaces\main_stream_sconnolly\ then we will have problems]) --- This is a note for anybody trying to implement as regards my stumbling blocks. unless somebody can see an easy work-around I do not think accurev can be integrated with the release plugin. Implement accurev provider -- Key: SCM-71 URL: http://jira.codehaus.org/browse/SCM-71 Project: Maven SCM Issue Type: New Feature Reporter: Emmanuel Venisse I look at documentation, and it's very easy to do (works like cvs or svn) http://www.accurev.com/download/docs/AccuRev_User_CLI.pdf -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-71) Implement accurev provider
[ http://jira.codehaus.org/browse/SCM-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89767 ] Stephen Connolly commented on SCM-71: - If you have made some work on this module, I would be happy to test against Accurev 4.5.1. Implement accurev provider -- Key: SCM-71 URL: http://jira.codehaus.org/browse/SCM-71 Project: Maven SCM Issue Type: New Feature Components: maven-scm-provider-accurev Reporter: Emmanuel Venisse I look at documentation, and it's very easy to do (works like cvs or svn) http://www.accurev.com/download/docs/AccuRev_User_CLI.pdf -- 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: (MRELEASE-621) Add a postPrepareGoals
Add a postPrepareGoals -- Key: MRELEASE-621 URL: http://jira.codehaus.org/browse/MRELEASE-621 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.1 Reporter: Stephen Connolly Priority: Minor At present the preparationGoals run before the tag is created. It would be nice to have a means of doing additional stuff after the tag has been created and before the next-version-SNAPSHOT pom is checked back into the trunk (or branch that you were releasing from) Could then be used to have versions-maven-plugin resolve the ranges for the release and restore them to ranges for development. -- 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: (MANTTASKS-210) When creating path objects using the dependencies task it is not possible to filter out artifacts by type.
When creating path objects using the dependencies task it is not possible to filter out artifacts by type. -- Key: MANTTASKS-210 URL: http://jira.codehaus.org/browse/MANTTASKS-210 Project: Maven 2.x Ant Tasks Issue Type: Improvement Components: dependencies task Affects Versions: 2.1.1 Reporter: Stephen Connolly Priority: Minor If you reference an object of type pom and pull its dependencies into a path object, the resulting path will contain the pom files which java then presumes to be malformed zip files. If you use type=jar then it will not resolve the dependencies of the pom artifact at all, so you need to have type=jar,pom to get the dependencies of the packaging pom artifact. What is needed is a separate pathType attribute to allow retrieving the full set of dependencies into the fileset, while selecting a subset for the path object. -- 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: (MANTTASKS-210) When creating path objects using the dependencies task it is not possible to filter out artifacts by type.
[ http://jira.codehaus.org/browse/MANTTASKS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MANTTASKS-210. -- Resolution: Fixed Fix Version/s: 2.1.2 r1061291. When creating path objects using the dependencies task it is not possible to filter out artifacts by type. -- Key: MANTTASKS-210 URL: http://jira.codehaus.org/browse/MANTTASKS-210 Project: Maven 2.x Ant Tasks Issue Type: Improvement Components: dependencies task Affects Versions: 2.1.1 Reporter: Stephen Connolly Priority: Minor Fix For: 2.1.2 If you reference an object of type pom and pull its dependencies into a path object, the resulting path will contain the pom files which java then presumes to be malformed zip files. If you use type=jar then it will not resolve the dependencies of the pom artifact at all, so you need to have type=jar,pom to get the dependencies of the packaging pom artifact. What is needed is a separate pathType attribute to allow retrieving the full set of dependencies into the fileset, while selecting a subset for the path object. -- 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: (MANTTASKS-211) Support launching Maven 3.x from the mvn task
Support launching Maven 3.x from the mvn task - Key: MANTTASKS-211 URL: http://jira.codehaus.org/browse/MANTTASKS-211 Project: Maven 2.x Ant Tasks Issue Type: Improvement Components: mvn task Affects Versions: 2.1.1 Reporter: Stephen Connolly The mvn task cannot launch maven 3.0.x as the list of dependencies is not complete if resolving from maven-core only. Resolving from apache-maven will give the correct list of dependencies now that MANTTASKS-210 allows path object filtering. -- 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: (MANTTASKS-211) Support launching Maven 3.x from the mvn task
[ http://jira.codehaus.org/browse/MANTTASKS-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MANTTASKS-211. -- Resolution: Fixed Fix Version/s: 2.1.2 r1061312. Support launching Maven 3.x from the mvn task - Key: MANTTASKS-211 URL: http://jira.codehaus.org/browse/MANTTASKS-211 Project: Maven 2.x Ant Tasks Issue Type: Improvement Components: mvn task Affects Versions: 2.1.1 Reporter: Stephen Connolly Assignee: Stephen Connolly Fix For: 2.1.2 The mvn task cannot launch maven 3.0.x as the list of dependencies is not complete if resolving from maven-core only. Resolving from apache-maven will give the correct list of dependencies now that MANTTASKS-210 allows path object filtering. -- 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: (MANTTASKS-217) Add a pseudo-reactor so that parent pom references can be resolved without pushing poms to the file system
Add a pseudo-reactor so that parent pom references can be resolved without pushing poms to the file system -- Key: MANTTASKS-217 URL: http://jira.codehaus.org/browse/MANTTASKS-217 Project: Maven 2.x Ant Tasks Issue Type: Improvement Reporter: Stephen Connolly Attachments: pseudo-reactor-testcase.diff This is a blocker for Apache Cassandra 0.8. At present you cannot create both the parent pom and the child pom in memory in ant and have the parent pom's dependencyManagement propagate to the child pom. Thus, for example, with Apache Cassandra 0.8 we cannot define a dependencyManagement in a parent pom and then use the versions from that dependencyManagement through out all the child poms that are required to be generated significantly hindering version management -- 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: (MANTTASKS-217) Add a pseudo-reactor so that parent pom references can be resolved without pushing poms to the file system
[ http://jira.codehaus.org/browse/MANTTASKS-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=261455#action_261455 ] Stephen Connolly commented on MANTTASKS-217: test case committed in r1085344 Add a pseudo-reactor so that parent pom references can be resolved without pushing poms to the file system -- Key: MANTTASKS-217 URL: http://jira.codehaus.org/browse/MANTTASKS-217 Project: Maven 2.x Ant Tasks Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Stephen Connolly Assignee: Stephen Connolly Fix For: 2.1.2 Attachments: pseudo-reactor-testcase.diff This is a blocker for Apache Cassandra 0.8. At present you cannot create both the parent pom and the child pom in memory in ant and have the parent pom's dependencyManagement propagate to the child pom. Thus, for example, with Apache Cassandra 0.8 we cannot define a dependencyManagement in a parent pom and then use the versions from that dependencyManagement through out all the child poms that are required to be generated significantly hindering version management -- 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: (MANTTASKS-217) Add a pseudo-reactor so that parent pom references can be resolved without pushing poms to the file system
[ http://jira.codehaus.org/browse/MANTTASKS-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MANTTASKS-217. -- Resolution: Fixed r1085345 Add a pseudo-reactor so that parent pom references can be resolved without pushing poms to the file system -- Key: MANTTASKS-217 URL: http://jira.codehaus.org/browse/MANTTASKS-217 Project: Maven 2.x Ant Tasks Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Stephen Connolly Assignee: Stephen Connolly Fix For: 2.1.2 Attachments: pseudo-reactor-testcase.diff This is a blocker for Apache Cassandra 0.8. At present you cannot create both the parent pom and the child pom in memory in ant and have the parent pom's dependencyManagement propagate to the child pom. Thus, for example, with Apache Cassandra 0.8 we cannot define a dependencyManagement in a parent pom and then use the versions from that dependencyManagement through out all the child poms that are required to be generated significantly hindering version management -- 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: (MANTTASKS-218) cacheDependencyRefs is ignored when pulling dependencies from a pom defined in the build.xml
cacheDependencyRefs is ignored when pulling dependencies from a pom defined in the build.xml -- Key: MANTTASKS-218 URL: http://jira.codehaus.org/browse/MANTTASKS-218 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: dependencies task Affects Versions: 2.1.2 Reporter: Stephen Connolly When a pom is defined in the ant build.xml and then the dependencies task uses that pom then cacheDependencyRefs is ignored unless the pom is loaded from a file on disk. This is causing a regression in build time for the Apache Cassandra project (https://issues.apache.org/jira/browse/CASSANDRA-1851?focusedCommentId=13017152page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13017152) -- 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: (MANTTASKS-218) cacheDependencyRefs is ignored when pulling dependencies from a pom defined in the build.xml
[ http://jira.codehaus.org/browse/MANTTASKS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MANTTASKS-218: --- Attachment: MANTTASKS-218.patch Attaching the patch for the Apache Cassandra guys to be able to build local copy cacheDependencyRefs is ignored when pulling dependencies from a pom defined in the build.xml -- Key: MANTTASKS-218 URL: http://jira.codehaus.org/browse/MANTTASKS-218 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: dependencies task Affects Versions: 2.1.2 Reporter: Stephen Connolly Attachments: MANTTASKS-218.patch When a pom is defined in the ant build.xml and then the dependencies task uses that pom then cacheDependencyRefs is ignored unless the pom is loaded from a file on disk. This is causing a regression in build time for the Apache Cassandra project (https://issues.apache.org/jira/browse/CASSANDRA-1851?focusedCommentId=13017152page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13017152) -- 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: (MANTTASKS-218) cacheDependencyRefs is ignored when pulling dependencies from a pom defined in the build.xml
[ http://jira.codehaus.org/browse/MANTTASKS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MANTTASKS-218: --- Fix Version/s: 2.1.3 cacheDependencyRefs is ignored when pulling dependencies from a pom defined in the build.xml -- Key: MANTTASKS-218 URL: http://jira.codehaus.org/browse/MANTTASKS-218 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: dependencies task Affects Versions: 2.1.2 Reporter: Stephen Connolly Fix For: 2.1.3 Attachments: MANTTASKS-218.patch When a pom is defined in the ant build.xml and then the dependencies task uses that pom then cacheDependencyRefs is ignored unless the pom is loaded from a file on disk. This is causing a regression in build time for the Apache Cassandra project (https://issues.apache.org/jira/browse/CASSANDRA-1851?focusedCommentId=13017152page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13017152) -- 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: (MANTTASKS-218) cacheDependencyRefs is ignored when pulling dependencies from a pom defined in the build.xml
[ http://jira.codehaus.org/browse/MANTTASKS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MANTTASKS-218. -- Resolution: Fixed r1091446 cacheDependencyRefs is ignored when pulling dependencies from a pom defined in the build.xml -- Key: MANTTASKS-218 URL: http://jira.codehaus.org/browse/MANTTASKS-218 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: dependencies task Affects Versions: 2.1.2 Reporter: Stephen Connolly Fix For: 2.1.3 Attachments: MANTTASKS-218.patch When a pom is defined in the ant build.xml and then the dependencies task uses that pom then cacheDependencyRefs is ignored unless the pom is loaded from a file on disk. This is causing a regression in build time for the Apache Cassandra project (https://issues.apache.org/jira/browse/CASSANDRA-1851?focusedCommentId=13017152page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13017152) -- 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-275) Figuring out duplicate class definitions using the Analyze goal
[ http://jira.codehaus.org/browse/MDEP-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263872#action_263872 ] Stephen Connolly commented on MDEP-275: --- See https://svn.codehaus.org/mojo/trunk/sandbox/extra-enforcer-rules/src/main/java/org/codehaus/mojo/enforcer/rule/BanDuplicateClassesRule.java@13945 Figuring out duplicate class definitions using the Analyze goal --- Key: MDEP-275 URL: http://jira.codehaus.org/browse/MDEP-275 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: analyze Affects Versions: 2.1 Reporter: Petter Måhlén Assignee: Brian Fox Attachments: dependency-analyzer.diff, dependency-plugin.diff Hi, I've pretty frequently run into issues where changes to the library structure of some product (that is, changing the way that classes are grouped into libraries) leads to the same classes being defined in more than one place. This can lead to system-dependent problems, because different versions of the same class are being loaded by different systems. I was going to create a new goal for the dependency plugin to check for duplicate classes, but when I looked a bit closer at the analyze goal, it already had all the information needed to do that check as well, so I came up with some changes that add this functionality. The intended usage is something like: mvn dependency:analyze -DcheckDuplicateClasses I get the feeling that I might want to add the ability to exclude certain packages (that I might be comfortable are safe to have duplicates of), so I added this option too: mvn dependency:analyze -DcheckDuplicateClasses -DexcludePrefixes=org., net.sf.cglib, javax.xml, junit. The output looks something like: [WARNING] Duplicate class definitions found: [WARNING]com.shopzilla.common.data.ObjectFactory defined in: [WARNING] com.shopzilla.site.url.c14n:model:jar:1.4:compile [WARNING] com.shopzilla.common.data:data-model-schema:jar:1.11:compile [WARNING]com.shopzilla.site.category.CategoryProvider defined in: [WARNING] com.shopzilla.site2.sasClient:sas-client-core:jar:5.47:compile [WARNING] com.shopzilla.site2.service:common-web:jar:5.50:compile A couple of notes: - I was unable to get configuration (setting checkDuplicateClasses, etc.) using the pom to work, but I think that might be due to lack of understanding on my part. - I don't fully understand the effect of calling compileProject() during unit tests, but I think it may be sufficient to call it only once for the duplicateClasses project, during setUp(). That would speed up the unit tests. - I haven't added duplicate class definition checking to the AnalyzeReportMojo, because I wanted to get some feedback on whether this addition was felt to be valuable before spending any time on that. - A lot of the unit test dummy code in the attached diff files needs cleaning up, but again I wanted to wait with that until hearing whether this might be useful to others. - I made an API change in the ProjectDependencyAnalyzer interface, which might be an issue if there are other implementations than the default one. That change was only needed to support the 'exclude package' feature, which might not be super-important. Cheers, Petter -- 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: (MCOMPILER-21) compiler smarts
[ http://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MCOMPILER-21: -- Fix Version/s: (was: 2.1) 2.2 compiler smarts --- Key: MCOMPILER-21 URL: http://jira.codehaus.org/browse/MCOMPILER-21 Project: Maven 2.x Compiler Plugin Issue Type: Bug Reporter: Brett Porter Priority: Minor Fix For: 2.2 there are probably other ways we can make the compiler stale check smarter. List them out here if you think of them. 1) if a snapshot was resolved to a newer version, rebuild everything. -- 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: (MCOMPILER-16) ability to separate compilation parameters for different compilers / create a compilation configuration object
[ http://jira.codehaus.org/browse/MCOMPILER-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MCOMPILER-16: -- Fix Version/s: (was: 2.1) 2.2 ability to separate compilation parameters for different compilers / create a compilation configuration object -- Key: MCOMPILER-16 URL: http://jira.codehaus.org/browse/MCOMPILER-16 Project: Maven 2.x Compiler Plugin Issue Type: Bug Reporter: Brett Porter Fix For: 2.2 I think we should introduce a compilation configuration object (and deprecate but not remove the old parameters) in the compiler plugin. This can have a base class that is extended by the different compiler types. I'm not sure if the Maven processing does enough just yet to be able to set a specific field with the right type without setting implementation= however, and we should also be able to make the object a fullly-fledged component (with expressions and default values, as long as it is in the same source tree). -- 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: (MCOMPILER-6) improve documentation
[ http://jira.codehaus.org/browse/MCOMPILER-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MCOMPILER-6: - Fix Version/s: (was: 2.1) 2.2 improve documentation - Key: MCOMPILER-6 URL: http://jira.codehaus.org/browse/MCOMPILER-6 Project: Maven 2.x Compiler Plugin Issue Type: Bug Reporter: Brett Porter Fix For: 2.2 some aspects are unclear: - compilerVersion is only used when forking - fork should indicate that it uses the built in version when false, not an executable. Also: - don't set parameters that only apply to forking when fork is false to make the code more readable - specifiy which are specific to javac, or java in general (perhaps we should be able to assign a @category to a plugin parameter) -- 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: (MCOMPILER-37) make configuration more flexible, and easier configuration based on jdk level
[ http://jira.codehaus.org/browse/MCOMPILER-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MCOMPILER-37: -- Fix Version/s: (was: 2.1) 2.2 make configuration more flexible, and easier configuration based on jdk level - Key: MCOMPILER-37 URL: http://jira.codehaus.org/browse/MCOMPILER-37 Project: Maven 2.x Compiler Plugin Issue Type: Improvement Affects Versions: 2.0 Reporter: Brett Porter Fix For: 2.2 see: http://mail-archives.apache.org/mod_mbox/maven-users/200603.mbox/%3c9e3862d80603261452w509238afx9472b4850007f...@mail.gmail.com%3e and rest of that thread. the plugin needs to be more flexible in regards to setting the compiler settings for the tests vs the main source tree, and could be easier to configure in general for different language settings. -- 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: (MCOMPILER-112) Change mavenVersion from 2.0.6 to 2.0.9 in the prereq
Change mavenVersion from 2.0.6 to 2.0.9 in the prereq - Key: MCOMPILER-112 URL: http://jira.codehaus.org/browse/MCOMPILER-112 Project: Maven 2.x Compiler Plugin Issue Type: Task Affects Versions: 2.1 Reporter: Stephen Connolly In order to prevent the release of compiler plugin from breaking the builds of people using Maven 2.0.6, 2.0.7 or 2.0.8 we need to update the mavenVersion to 2.0.9 (when the superpom lockdown started) so that projects which are not following best practice (i.e. locking down their plugin versions) will not be affected by the release of m-c-p 2.1 -- 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: (MCOMPILER-112) Change mavenVersion from 2.0.6 to 2.0.9 in the prereq
[ http://jira.codehaus.org/browse/MCOMPILER-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MCOMPILER-112. -- Resolution: Fixed Fix Version/s: 2.1 r894456 Change mavenVersion from 2.0.6 to 2.0.9 in the prereq - Key: MCOMPILER-112 URL: http://jira.codehaus.org/browse/MCOMPILER-112 Project: Maven 2.x Compiler Plugin Issue Type: Task Affects Versions: 2.1 Reporter: Stephen Connolly Fix For: 2.1 In order to prevent the release of compiler plugin from breaking the builds of people using Maven 2.0.6, 2.0.7 or 2.0.8 we need to update the mavenVersion to 2.0.9 (when the superpom lockdown started) so that projects which are not following best practice (i.e. locking down their plugin versions) will not be affected by the release of m-c-p 2.1 -- 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-584) Integration tests do not work during a release
Integration tests do not work during a release -- Key: SUREFIRE-584 URL: http://jira.codehaus.org/browse/SUREFIRE-584 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.5 Reporter: Stephen Connolly Priority: Blocker The integration tests fail when running a release. They need to be refactored to work with staged versions of the dependencies from 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-555) Support junit core for parallel running of tests
[ http://jira.codehaus.org/browse/SUREFIRE-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-555: -- Component/s: Junit 4.x support Fix Version/s: 2.5 targetting for 2.5 Support junit core for parallel running of tests Key: SUREFIRE-555 URL: http://jira.codehaus.org/browse/SUREFIRE-555 Project: Maven Surefire Issue Type: New Feature Components: Junit 4.x support Environment: All Reporter: Kristian Rosenvold Assignee: Stephen Connolly Fix For: 2.5 Attachments: surefire.patch, surefirev2.patch, surefirev3.patch, surefirev4.patch The enclosed patch adds junitcore support to surefire. The patch requires junit 4.6 (the latest released version) to compile, but is only activated when running with the 4.7 snapshot or higher (due to some bugs in 4.6). The patch adds one extra setting to the surefire plugin. More details at http://incodewetrustinc.blogspot.com/ The new plugin also requires an external library which can be found at http://github.com/krosenvold/configurable-parallel-computer/tree/master, which will be bumped to 1.0 when/if you decide to accept the patch. I am requesting that the junit project actually accept the features of the configurable-parallel-computer as a standard feature in junit 4.7, but that's not decided yet. I do not have a public maven repo that is hosting configurable-parallel-computer, but was hoping maybe you could publish it ? -- 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 ] Stephen Connolly updated SUREFIRE-468: -- Fix Version/s: (was: 2.5) 2.6 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.6 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] Closed: (SUREFIRE-555) Support junit core for parallel running of tests
[ http://jira.codehaus.org/browse/SUREFIRE-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-555. - Resolution: Fixed r895651. Support junit core for parallel running of tests Key: SUREFIRE-555 URL: http://jira.codehaus.org/browse/SUREFIRE-555 Project: Maven Surefire Issue Type: New Feature Components: Junit 4.x support Environment: All Reporter: Kristian Rosenvold Assignee: Stephen Connolly Fix For: 2.5 Attachments: surefire.patch, surefirev2.patch, surefirev3.patch, surefirev4.patch The enclosed patch adds junitcore support to surefire. The patch requires junit 4.6 (the latest released version) to compile, but is only activated when running with the 4.7 snapshot or higher (due to some bugs in 4.6). The patch adds one extra setting to the surefire plugin. More details at http://incodewetrustinc.blogspot.com/ The new plugin also requires an external library which can be found at http://github.com/krosenvold/configurable-parallel-computer/tree/master, which will be bumped to 1.0 when/if you decide to accept the patch. I am requesting that the junit project actually accept the features of the configurable-parallel-computer as a standard feature in junit 4.7, but that's not decided yet. I do not have a public maven repo that is hosting configurable-parallel-computer, but was hoping maybe you could publish it ? -- 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-586) Add support for Maven Toolchains
Add support for Maven Toolchains Key: SUREFIRE-586 URL: http://jira.codehaus.org/browse/SUREFIRE-586 Project: Maven Surefire Issue Type: Improvement Components: plugin Reporter: Stephen Connolly Add support for Maven Toolchains -- 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-586) Add support for Maven Toolchains
[ http://jira.codehaus.org/browse/SUREFIRE-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-586. - Resolution: Fixed Fix Version/s: 2.5 Assignee: Milos Kleint r649441 Add support for Maven Toolchains Key: SUREFIRE-586 URL: http://jira.codehaus.org/browse/SUREFIRE-586 Project: Maven Surefire Issue Type: Improvement Components: plugin Reporter: Stephen Connolly Assignee: Milos Kleint Fix For: 2.5 Add support for Maven Toolchains -- 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-586) Add support for Maven Toolchains
[ http://jira.codehaus.org/browse/SUREFIRE-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-586: -- Issue Type: New Feature (was: Improvement) Add support for Maven Toolchains Key: SUREFIRE-586 URL: http://jira.codehaus.org/browse/SUREFIRE-586 Project: Maven Surefire Issue Type: New Feature Components: plugin Reporter: Stephen Connolly Assignee: Milos Kleint Fix For: 2.5 Add support for Maven Toolchains -- 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-584) Integration tests do not work during a release
[ http://jira.codehaus.org/browse/SUREFIRE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-584: -- Issue Type: Bug (was: Improvement) actually a bug Integration tests do not work during a release -- Key: SUREFIRE-584 URL: http://jira.codehaus.org/browse/SUREFIRE-584 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.5 Reporter: Stephen Connolly Assignee: Stephen Connolly Priority: Blocker The integration tests fail when running a release. They need to be refactored to work with staged versions of the dependencies from 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-584) Integration tests do not work during a release
[ http://jira.codehaus.org/browse/SUREFIRE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-584: -- Fix Version/s: 2.5 Integration tests do not work during a release -- Key: SUREFIRE-584 URL: http://jira.codehaus.org/browse/SUREFIRE-584 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.5 Reporter: Stephen Connolly Assignee: Stephen Connolly Priority: Blocker Fix For: 2.5 The integration tests fail when running a release. They need to be refactored to work with staged versions of the dependencies from 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: (SUREFIRE-584) Integration tests do not work during a release
[ http://jira.codehaus.org/browse/SUREFIRE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-584. - Resolution: Fixed r896852 r896882 Integration tests do not work during a release -- Key: SUREFIRE-584 URL: http://jira.codehaus.org/browse/SUREFIRE-584 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.5 Reporter: Stephen Connolly Assignee: Stephen Connolly Priority: Blocker Fix For: 2.5 The integration tests fail when running a release. They need to be refactored to work with staged versions of the dependencies from 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] Created: (SUREFIRE-591) Add maven-failsafe-plugin to surefire project
Add maven-failsafe-plugin to surefire project - Key: SUREFIRE-591 URL: http://jira.codehaus.org/browse/SUREFIRE-591 Project: Maven Surefire Issue Type: New Feature Components: plugin Reporter: Stephen Connolly The failsafe-maven-plugin is a fork of maven-surefire-plugin which is used when running integration tests. In order to simplify maintenance, rehost this plugin @apache rather than @codehaus -- 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-591) Add maven-failsafe-plugin to surefire project
[ http://jira.codehaus.org/browse/SUREFIRE-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-591. - Resolution: Fixed Fix Version/s: 2.5 r897127. Add maven-failsafe-plugin to surefire project - Key: SUREFIRE-591 URL: http://jira.codehaus.org/browse/SUREFIRE-591 Project: Maven Surefire Issue Type: New Feature Components: plugin Reporter: Stephen Connolly Assignee: Stephen Connolly Fix For: 2.5 The failsafe-maven-plugin is a fork of maven-surefire-plugin which is used when running integration tests. In order to simplify maintenance, rehost this plugin @apache rather than @codehaus -- 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-592) Refactor plugins to remove duplicate code
[ http://jira.codehaus.org/browse/SUREFIRE-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-592: -- Fix Version/s: 2.6 Refactor plugins to remove duplicate code - Key: SUREFIRE-592 URL: http://jira.codehaus.org/browse/SUREFIRE-592 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.5 Reporter: Stephen Connolly Assignee: Stephen Connolly Fix For: 2.6 After the addition of maven-failsafe-plugin there is now a fair bit of duplicate code between failsafe and surefire plugins. This code needs to be refactored into a single base class -- 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-592) Refactor plugins to remove duplicate code
Refactor plugins to remove duplicate code - Key: SUREFIRE-592 URL: http://jira.codehaus.org/browse/SUREFIRE-592 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.5 Reporter: Stephen Connolly After the addition of maven-failsafe-plugin there is now a fair bit of duplicate code between failsafe and surefire plugins. This code needs to be refactored into a single base class -- 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-594) Create an integration test for r897240
Create an integration test for r897240 -- Key: SUREFIRE-594 URL: http://jira.codehaus.org/browse/SUREFIRE-594 Project: Maven Surefire Issue Type: Task Affects Versions: 2.5 Reporter: Stephen Connolly Priority: Minor to reproduce the failure, URL: http://svn.apache.org/repos/asf/maven/archetype/trunk Revision: 897208 when was giving an NPE. -- 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-594) Create an integration test for r897240
[ http://jira.codehaus.org/browse/SUREFIRE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-594: -- Fix Version/s: 2.6 Create an integration test for r897240 -- Key: SUREFIRE-594 URL: http://jira.codehaus.org/browse/SUREFIRE-594 Project: Maven Surefire Issue Type: Task Affects Versions: 2.5 Reporter: Stephen Connolly Assignee: Stephen Connolly Priority: Minor Fix For: 2.6 to reproduce the failure, URL: http://svn.apache.org/repos/asf/maven/archetype/trunk Revision: 897208 when was giving an NPE. -- 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-593) Tag surefire-2.5 creates null.txt as test report
[ http://jira.codehaus.org/browse/SUREFIRE-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=205824#action_205824 ] Stephen Connolly commented on SUREFIRE-593: --- Have you got custom information in your settings.xml? If you cannot attach your settings.xml (with passwords hidden) feel free to email it to me (stephenc at apache.org) so that I can resolve this issue. Tag surefire-2.5 creates null.txt as test report Key: SUREFIRE-593 URL: http://jira.codehaus.org/browse/SUREFIRE-593 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.5 Environment: Windows XP Pro, maven 2.2.1 Reporter: Kiril Raychev When executing 'mvn install' on the tags/surefire-2.5 release (r897179) I get one failing test: Running org.apache.maven.surefire.its.UmlautDirIT Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.219 sec FAILURE! When executing 'mvn install -Dmaven.test.skip=true' the build succeeds, but when it is used on other project, the only output to target/surefire-reports are null.txt and TEST-org.junit.runner.Result.xml, which contain report of the last test class run. -- 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-596) Junit test output is broken with junit4-7+
[ http://jira.codehaus.org/browse/SUREFIRE-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206524#action_206524 ] Stephen Connolly commented on SUREFIRE-596: --- The patch is malformed, specifically: |=== |--- surefire-integration-tests/src/test/resources/concurrentjunit47/src/test/java/junit47/BasicTest.java (revision 0) |+++ surefire-integration-tests/src/test/resources/concurrentjunit47/src/test/java/junit47/BasicTest.java (working copy) -- File to patch: surefire-integration-tests/src/test/resources/concurrentjunit47/src/test/java/junit47/BasicTest.java patching file surefire-integration-tests/src/test/resources/concurrentjunit47/src/test/java/junit47/BasicTest.java Hunk #1 FAILED at 1. Hunk #2 FAILED at 35. 2 out of 2 hunks FAILED -- saving rejects to file surefire-integration-tests/src/test/resources/concurrentjunit47/src/test/java/junit47/BasicTest.java.rej patching file pom.xml Hunk #1 FAILED at 24. Hunk #2 FAILED at 56. 2 out of 2 hunks FAILED -- saving rejects to file pom.xml.rej Junit test output is broken with junit4-7+ --- Key: SUREFIRE-596 URL: http://jira.codehaus.org/browse/SUREFIRE-596 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.5 Environment: junit 4.7 Reporter: Kristian Rosenvold Attachments: junit1.diff There is a bug in the log output for the junit4.7+ provider, where it just says Result null instead of outputting the proper surefire output. Additionally, the concurrent junit provider should really only be used when the user has requested some concurrent execution model in the configuration. Workaround at the moment is one of the following: A) Use surefire-2.4.3 until this is fixed B) Downgrade to junit 4.6 until this is fixed C) ignore the problem. This may be possible, but some CI systems also parse the output so it may break the build. The enclosed patch fixes both problems on svn trunk of surefire, and also includes updated integration 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] Closed: (SUREFIRE-596) Junit test output is broken with junit4-7+
[ http://jira.codehaus.org/browse/SUREFIRE-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-596. - Resolution: Fixed Fix Version/s: 2.5 r898206 Junit test output is broken with junit4-7+ --- Key: SUREFIRE-596 URL: http://jira.codehaus.org/browse/SUREFIRE-596 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.5 Environment: junit 4.7 Reporter: Kristian Rosenvold Assignee: Stephen Connolly Fix For: 2.5 Attachments: junit1.diff, junit2.diff, junit2.zip There is a bug in the log output for the junit4.7+ provider, where it just says Result null instead of outputting the proper surefire output. Additionally, the concurrent junit provider should really only be used when the user has requested some concurrent execution model in the configuration. Workaround at the moment is one of the following: A) Use surefire-2.4.3 until this is fixed B) Downgrade to junit 4.6 until this is fixed C) ignore the problem. This may be possible, but some CI systems also parse the output so it may break the build. The enclosed patch fixes both problems on svn trunk of surefire, and also includes updated integration 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] Created: (MGPG-19) Site descriptor does not get signed
Site descriptor does not get signed --- Key: MGPG-19 URL: http://jira.codehaus.org/browse/MGPG-19 Project: Maven 2.x GPG Plugin Issue Type: Bug Affects Versions: 1.0-alpha-4 Reporter: Stephen Connolly Priority: Blocker When the site descriptor is an attached artifact, the GPG signature is not generated. Steps to reproduce: svn co https://svn.apache.org/repos/asf/maven/surefire/tags/surefire-...@898285 surefire-2.5 cd surefire-2.5 mvn site:attach-descriptor gpg:sign -Papache-release -N ls target/*.asc if there is a surefire-2.5-site.xml.asc then this bug is fixed. -- 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: (MRELEASE-492) The svn tag command failed
[
http://jira.codehaus.org/browse/MRELEASE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=208745#action_208745
]
Stephen Connolly commented on MRELEASE-492:
---
What version of SVN are you using on the client and the server side.
Did the release continue correctly after executing
svn update
mvn release:prepare
as (for those of us in Europe making releases on the apache svn server, the
sync process can cause a fail similar to what you are seeing which can be
resolved by svn update followed by continuing the release:prepare)?
The svn tag command failed
--
Key: MRELEASE-492
URL: http://jira.codehaus.org/browse/MRELEASE-492
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-9
Environment: ubuntu 9.04 ,
Apache Maven 2.1.0 (r755702; 2009-03-19 00:40:27+0530)
Java version: 1.6.0_13
Java home: /usr/lib/jvm/java-6-sun-1.6.0.13/jre
Default locale: en_IN, platform encoding: UTF-8
OS name: linux version: 2.6.28-15-server arch: i386 Family: unix
Reporter: Sridher Jakku
when i run the mvn release:prepare this error comming
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.584
sec
[INFO] Running com.ipleanty.accure.module.orm.AppTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018
sec
[INFO]
[INFO] Results :
[INFO]
[INFO] Tests run: 27, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] [INFO] [antrun:run {execution: default}]
[INFO] [INFO] Executing tasks
[INFO] [echo]
[INFO] [echo] r2093 | js | 2009-10-13 20:02:29 +0530 (Tue, 13 Oct 2009)
[INFO] [echo]
[INFO] [echo] Your orm Revision number : 2073
[INFO] [INFO] Executed tasks
[INFO] [INFO] [jar:jar]
[INFO] [INFO] Building jar: /home/sridher/maven/svn/orm/target/orm-0.7.jar
[INFO] [INFO]
[INFO] [INFO] BUILD SUCCESSFUL
[INFO] [INFO]
[INFO] [INFO] Total time: 26 seconds
[INFO] [INFO] Finished at: Tue Oct 13 20:03:30 IST 2009
[INFO] [INFO] Final Memory: 25M/114M
[INFO] [INFO]
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /home/sridher/maven/svn/orm svn --username
js --password '*' --non-interactive commit --file
/tmp/maven-scm-327676631.commit --targets
/tmp/maven-scm-7485856893453511468-targets
[INFO] Working directory: /home/sridher/maven/svn/orm
[INFO] Tagging release with the label orm-0.7...
[INFO] Executing: /bin/sh -c cd /home/sridher/maven/svn/orm svn --username
js --password '*' --non-interactive copy --file
/tmp/maven-scm-895863680.commit .
scm:svn:svn://192.168.1.10/Accure/orm/tags/orm-0.7
[INFO] Working directory: /home/sridher/maven/svn/orm
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Local, non-commit operations do not take a log message or revision
properties
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 41 seconds
[INFO] Finished at: Tue Oct 13 20:03:32 IST 2009
[INFO] Final Memory: 12M/119M
[INFO]
--
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: (MRELEASE-514) release:branch hit remoteTagging problem
[
http://jira.codehaus.org/browse/MRELEASE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=208746#action_208746
]
Stephen Connolly commented on MRELEASE-514:
---
Did you have a mixed revision working copy?
I have seen this type of issue just creating tags using svn directly.
If you modify files locally, commit just those files and then do an svn cp
without doing an svn update first, then you can end up with the above issue.
If this is a case of a mixed revision working copy, then there may not be an
easy way to fix this, we could force an svn update, but that might be counter
to what the user is trying to do, e.g. they may want to branch from their
working copy... which has some files updated to HEAD while others have not been
updated (because the update would break the code)
release:branch hit remoteTagging problem
Key: MRELEASE-514
URL: http://jira.codehaus.org/browse/MRELEASE-514
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: branch
Affects Versions: 2.0-beta-9
Reporter: Benson Margulies
I ran:
mvn release:branch -DbranchName=rlp_7.1
and got ...
{noformat}
[INFO] Working directory: /Users/benson/x/rex2009-trunk/java
org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to
branch SCM
Provider message:
The svn branch command failed.
Command output:
svn: Commit failed (details follow):
svn: File '/engineering/rex2009/branches/rlp_7.1/annotatortools/pom.xml'
already exists
at
org.apache.maven.shared.release.phase.ScmBranchPhase.execute(ScmBranchPhase.java:98)
at
org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:379)
at
org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:350)
at
org.apache.maven.plugins.release.BranchReleaseMojo.execute(BranchReleaseMojo.java:133)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
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)
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to branch SCM
Provider message:
The svn branch command failed.
Command output:
svn: Commit failed (details follow):
svn: File '/engineering/rex2009/branches/rlp_7.1/annotatortools/pom.xml'
already exists
{noformat}
--
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: (MRELEASE-140) Tests fail during release:perform but work elsewhere
[
http://jira.codehaus.org/browse/MRELEASE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=208747#action_208747
]
Stephen Connolly commented on MRELEASE-140:
---
Have you tried changing forkMode on surefire... by default forkMode will be
none, which means that if the release plugin is pulling in extra classes, they
will still be in the JVM (even if classworlds keeps them on a separate
classloader)
Tests fail during release:perform but work elsewhere
Key: MRELEASE-140
URL: http://jira.codehaus.org/browse/MRELEASE-140
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-4
Environment: Maven 2.0.4. Linux
Reporter: Adrian
Priority: Blocker
Attachments: com.dolby.pics.core.ejb.bean.CountryBeanTestCase.txt,
perform-output, TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml,
WORKING-TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml
h2. Summary
I have a project that builds successfully when {{mvn clean install}} is
executed.
When {{mvn clean release:prepare}} is executed the integration tests run
successfully too.
When {{mvn release:perform}} is executed the junit tests using surefire fail.
h2. Details
h3. The project layout
The project is an EJB 3 project. The unit tests bootstrap/startup an embedded
EJB container to test the EJBs. The container is configured via a set of xml
and property files that are specified in the testResources section of the
pom. The embedded container is a dependency of the project with _test_ scope.
h3. release:perform output
The output of the release:perform goal is attached to this issue.
h3. surefire junit test report
The output of the release:perform goal is attached to this issue. A snippet
is shown here:
{code}
---
Battery: com.dolby.pics.core.ejb.bean.CountryBeanTestCase
---
Tests run: 11, Failures: 0, Errors: 11, Time elapsed: 7.234 sec
testGetAll(com.dolby.pics.core.ejb.bean.CountryBeanTestCase) Time elapsed:
2.255 sec ERROR!
[ stdout ] ---
[ stderr ] ---
[ stacktrace ] ---
java.lang.RuntimeException: org.jboss.xb.binding.JBossXBRuntimeException:
Failed to create a new SAX parser
at
org.jboss.ejb3.embedded.EJB3StandaloneBootstrap.boot(EJB3StandaloneBootstrap.java:391)
at
com.dolby.pics.test.AbstractEJBTestCase.startupEmbeddedJboss(AbstractEJBTestCase.java:63)
at
com.dolby.pics.test.AbstractEJBTestCase.setUp(AbstractEJBTestCase.java:145)
at
com.dolby.pics.core.ejb.bean.CountryBeanTestCase.setUp(CountryBeanTestCase.java:43)
at junit.framework.TestCase.runBare(TestCase.java:128)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:228)
at junit.framework.TestSuite.run(TestSuite.java:223)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242)
at
org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216)
at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215)
at org.apache.maven.surefire.Surefire.run(Surefire.java:163)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:313)
at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:221)
at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:371)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
[jira] Moved: (SUREFIRE-603) http://jira.codehaus.org/browse/SUREFIRE-541
[ http://jira.codehaus.org/browse/SUREFIRE-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly moved MOJO-1391 to SUREFIRE-603: - Component/s: (was: failsafe) Maven Failsafe Plugin Fix Version/s: (was: failsafe-maven-plugin-2.5) 2.5 Key: SUREFIRE-603 (was: MOJO-1391) Project: Maven Surefire (was: Mojo) http://jira.codehaus.org/browse/SUREFIRE-541 Key: SUREFIRE-603 URL: http://jira.codehaus.org/browse/SUREFIRE-603 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin Reporter: Stephen Connolly Priority: Blocker Fix For: 2.5 Attachments: objectFactory.patch Need to apply this patch when surefire released with http://jira.codehaus.org/browse/SUREFIRE-541 included -- 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-603) http://jira.codehaus.org/browse/SUREFIRE-541
[ http://jira.codehaus.org/browse/SUREFIRE-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-603. - Resolution: Fixed fixed in 2.5 release http://jira.codehaus.org/browse/SUREFIRE-541 Key: SUREFIRE-603 URL: http://jira.codehaus.org/browse/SUREFIRE-603 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin Reporter: Stephen Connolly Priority: Blocker Fix For: 2.5 Attachments: objectFactory.patch Need to apply this patch when surefire released with http://jira.codehaus.org/browse/SUREFIRE-541 included -- 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] Moved: (SUREFIRE-604) failsave plugin does not execute post-integrateion-test phase after timeout via forkedProcessTimeoutInSeconds
[ http://jira.codehaus.org/browse/SUREFIRE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly moved MOJO-1507 to SUREFIRE-604: - Component/s: (was: failsafe) Maven Failsafe Plugin Affects Version/s: (was: failsafe-maven-plugin-2.5) Key: SUREFIRE-604 (was: MOJO-1507) Project: Maven Surefire (was: Mojo) failsave plugin does not execute post-integrateion-test phase after timeout via forkedProcessTimeoutInSeconds --- Key: SUREFIRE-604 URL: http://jira.codehaus.org/browse/SUREFIRE-604 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin Environment: maven3 alpha6 Reporter: Volkmar Nissen Attachments: failsave.timout.example.zip, MOJO-1507.patch The failsave plugin does not execute post-integrateion-test phase after timeout via forkedProcessTimeoutInSeconds The attached example project contains - a integration junit test which runs forever - a pom.xml which has failsafe configured to fire a timeout after 3 seconds. - In the pom.xml it's configured to execute the help:describe goal in the post-integration-test phase in order to check whether the post-integration-test phase has been triggered even in case of the timeout. So, something like the following lines are expected in the output (but the lines do not occure): [INFO] --- maven-help-plugin:2.1:describe (post-integration-test) @ failsave.timeout.example --- [INFO] 'install' is a phase corresponding to this plugin: org.apache.maven.plugins:maven-install-plugin:install It is a part of the lifecycle for the POM packaging 'jar'. This lifecycle includes the following phases: * validate: Not defined * initialize: Not defined * generate-sources: Not defined * process-sources: Not defined * generate-resources: Not defined * process-resources: org.apache.maven.plugins:maven-resources-plugin:resources * compile: org.apache.maven.plugins:maven-compiler-plugin:compile * process-classes: Not defined * generate-test-sources: Not defined * process-test-sources: Not defined * generate-test-resources: Not defined * process-test-resources: org.apache.maven.plugins:maven-resources-plugin:testResources * test-compile: org.apache.maven.plugins:maven-compiler-plugin:testCompile * process-test-classes: Not defined * test: org.apache.maven.plugins:maven-surefire-plugin:test * prepare-package: Not defined * package: org.apache.maven.plugins:maven-jar-plugin:jar * pre-integration-test: Not defined * integration-test: Not defined * post-integration-test: Not defined * verify: Not defined * install: org.apache.maven.plugins:maven-install-plugin:install * deploy: org.apache.maven.plugins:maven-deploy-plugin:deploy [INFO] [INFO] --- maven-install-plugin:2.3:install (default-install) @ failsave.timeout.example --- [INFO] Installing C:\hudson\workspacedemo\failsave.timout.example\target\failsave.timeout.example-0.0.1-SNAPSHOT.jar to C:\Users\D035406\.m2\repository\failsave\timeout\example\failsave.timeout.example\0.0.1-SNAPSHOT\failsave.timeout.example-0.0.1-SNAPSHOT.jar [INFO] -- 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] Moved: (SUREFIRE-605) skip verify phase on Hudson CI
[ http://jira.codehaus.org/browse/SUREFIRE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly moved MOJO-1409 to SUREFIRE-605: - Component/s: (was: failsafe) Maven Failsafe Plugin Affects Version/s: (was: failsafe-maven-plugin-2.4.3-alpha-1) Key: SUREFIRE-605 (was: MOJO-1409) Project: Maven Surefire (was: Mojo) skip verify phase on Hudson CI Key: SUREFIRE-605 URL: http://jira.codehaus.org/browse/SUREFIRE-605 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Reporter: nicolas de loof On Hudson CI server, failsafe:verify will report a broken build on IT test error, not just unstable build. Hudson seems to detect the build has been failed from surefire plugin, not sure how it does -- 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] Moved: (SUREFIRE-606) Provide a way for multiple executions of failsafe:integration-test to communicate with failsafe:verify (and the maven-surefire-report-plugin)
[
http://jira.codehaus.org/browse/SUREFIRE-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly moved MOJO-1474 to SUREFIRE-606:
-
Component/s: (was: failsafe)
Maven Failsafe Plugin
Affects Version/s: (was: failsafe-maven-plugin-2.4.3-alpha-1)
Key: SUREFIRE-606 (was: MOJO-1474)
Project: Maven Surefire (was: Mojo)
Provide a way for multiple executions of failsafe:integration-test to
communicate with failsafe:verify (and the maven-surefire-report-plugin)
-
Key: SUREFIRE-606
URL: http://jira.codehaus.org/browse/SUREFIRE-606
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Failsafe Plugin
Reporter: Andreas Sewe
Priority: Minor
Providing such a means to communicate would be useful to support use cases
like the following, reported on the Maven users lists
(http://www.mail-archive.com/us...@maven.apache.org/msg104821.html):
{quote}
Our project has a set of integration tests that have to be passed using
*several* combinations of systemProperties/argLine. (Note that the test
classes are identical; only the configuration changes.)
Getting the tests to execute is easy; I just bind multiple executions of
failsafe:integration-test to the integration-test phase. Getting
failsafe:verify to pick up all tests results, however, is not, as I
wasn't able to figure out which parameters to tweak: summaryFile?
reportsDirectory?
{quote}
--
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] Moved: (SUREFIRE-607) Failsafe should create workingDirectory if it does not exist
[
http://jira.codehaus.org/browse/SUREFIRE-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly moved MOJO-1465 to SUREFIRE-607:
-
Component/s: (was: failsafe)
Maven Failsafe Plugin
Affects Version/s: (was: failsafe-maven-plugin-2.4.3-alpha-1)
Key: SUREFIRE-607 (was: MOJO-1465)
Project: Maven Surefire (was: Mojo)
Failsafe should create workingDirectory if it does not exist
Key: SUREFIRE-607
URL: http://jira.codehaus.org/browse/SUREFIRE-607
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Failsafe Plugin
Environment: Fedora 11, Maven 2.2.1
Reporter: Peter Janes
Attachments: failsafe-workingDirectory.patch
Failsafe allows the user to set a workingDirectory, e.g.
lt;workingDirectorygt;${project.build.directory}/failsafe-working-directorylt;/workingDirectorygt;,
but if it doesn't exist the integration-test goal reports a
CommandLineException:
[INFO] Error while executing forked tests.; nested exception is
org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.CommandLineException:
Working directory /home/pjanes/failsafe/target/failsafe-working-directory
does not exist!
The attached patch creates the directory if it doesn't exist. This can also
be worked around by adding an instance of maven-antrun-plugin that invokes
Ant's lt;mkdirgt; task, but it seems like overkill and unnecessary
repetition to configure and invoke a completely separate plugin just to
create a directory.
(maven-surefire-plugin doesn't create its workingDirectory either.)
--
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] Moved: (SUREFIRE-608) the -DskipITs parameter went missing from the source code
[ http://jira.codehaus.org/browse/SUREFIRE-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly moved MOJO-1400 to SUREFIRE-608: - Component/s: (was: failsafe) Maven Failsafe Plugin Affects Version/s: (was: failsafe-maven-plugin-2.4.3-alpha-1) 2.4.3 Key: SUREFIRE-608 (was: MOJO-1400) Project: Maven Surefire (was: Mojo) the -DskipITs parameter went missing from the source code - Key: SUREFIRE-608 URL: http://jira.codehaus.org/browse/SUREFIRE-608 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin Affects Versions: 2.4.3 Reporter: Stephen Connolly I'd added a -DskipITs parameter, but in merging with surefire code it appears to have gone missing. -- 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-608) the -DskipITs parameter went missing from the source code
[ http://jira.codehaus.org/browse/SUREFIRE-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-608: -- Fix Version/s: 2.5 the -DskipITs parameter went missing from the source code - Key: SUREFIRE-608 URL: http://jira.codehaus.org/browse/SUREFIRE-608 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin Affects Versions: 2.4.3 Reporter: Stephen Connolly Fix For: 2.5 I'd added a -DskipITs parameter, but in merging with surefire code it appears to have gone missing. -- 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] Moved: (SUREFIRE-609) Failsafe should create workingDirectory if it does not exist
[
http://jira.codehaus.org/browse/SUREFIRE-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly moved MOJO-1501 to SUREFIRE-609:
-
Component/s: (was: failsafe)
Maven Failsafe Plugin
Affects Version/s: (was: failsafe-maven-plugin-2.4.3-alpha-1)
2.4.3
Key: SUREFIRE-609 (was: MOJO-1501)
Project: Maven Surefire (was: Mojo)
Failsafe should create workingDirectory if it does not exist
Key: SUREFIRE-609
URL: http://jira.codehaus.org/browse/SUREFIRE-609
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Failsafe Plugin
Affects Versions: 2.4.3
Environment: Fedora 11, Maven 2.2.1
Reporter: Peter Janes
Attachments: failsafe-workingDirectory.patch
Failsafe allows the user to set a workingDirectory, e.g.
lt;workingDirectorygt;${project.build.directory}/failsafe-working-directorylt;/workingDirectorygt;,
but if it doesn't exist the integration-test goal reports a
CommandLineException:
[INFO] Error while executing forked tests.; nested exception is
org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.CommandLineException:
Working directory /home/pjanes/failsafe/target/failsafe-working-directory
does not exist!
The attached patch creates the directory if it doesn't exist. This can also
be worked around by adding an instance of maven-antrun-plugin that invokes
Ant's lt;mkdirgt; task, but it seems like overkill and unnecessary
repetition to configure and invoke a completely separate plugin just to
create a directory.
(maven-surefire-plugin doesn't create its workingDirectory either.)
--
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-604) failsave plugin does not execute post-integrateion-test phase after timeout via forkedProcessTimeoutInSeconds
[ http://jira.codehaus.org/browse/SUREFIRE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-604. - Resolution: Fixed Fix Version/s: 2.6 r923683. failsave plugin does not execute post-integrateion-test phase after timeout via forkedProcessTimeoutInSeconds --- Key: SUREFIRE-604 URL: http://jira.codehaus.org/browse/SUREFIRE-604 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin Environment: maven3 alpha6 Reporter: Volkmar Nissen Fix For: 2.6 Attachments: failsave.timout.example.zip, MOJO-1507.patch The failsave plugin does not execute post-integrateion-test phase after timeout via forkedProcessTimeoutInSeconds The attached example project contains - a integration junit test which runs forever - a pom.xml which has failsafe configured to fire a timeout after 3 seconds. - In the pom.xml it's configured to execute the help:describe goal in the post-integration-test phase in order to check whether the post-integration-test phase has been triggered even in case of the timeout. So, something like the following lines are expected in the output (but the lines do not occure): [INFO] --- maven-help-plugin:2.1:describe (post-integration-test) @ failsave.timeout.example --- [INFO] 'install' is a phase corresponding to this plugin: org.apache.maven.plugins:maven-install-plugin:install It is a part of the lifecycle for the POM packaging 'jar'. This lifecycle includes the following phases: * validate: Not defined * initialize: Not defined * generate-sources: Not defined * process-sources: Not defined * generate-resources: Not defined * process-resources: org.apache.maven.plugins:maven-resources-plugin:resources * compile: org.apache.maven.plugins:maven-compiler-plugin:compile * process-classes: Not defined * generate-test-sources: Not defined * process-test-sources: Not defined * generate-test-resources: Not defined * process-test-resources: org.apache.maven.plugins:maven-resources-plugin:testResources * test-compile: org.apache.maven.plugins:maven-compiler-plugin:testCompile * process-test-classes: Not defined * test: org.apache.maven.plugins:maven-surefire-plugin:test * prepare-package: Not defined * package: org.apache.maven.plugins:maven-jar-plugin:jar * pre-integration-test: Not defined * integration-test: Not defined * post-integration-test: Not defined * verify: Not defined * install: org.apache.maven.plugins:maven-install-plugin:install * deploy: org.apache.maven.plugins:maven-deploy-plugin:deploy [INFO] [INFO] --- maven-install-plugin:2.3:install (default-install) @ failsave.timeout.example --- [INFO] Installing C:\hudson\workspacedemo\failsave.timout.example\target\failsave.timeout.example-0.0.1-SNAPSHOT.jar to C:\Users\D035406\.m2\repository\failsave\timeout\example\failsave.timeout.example\0.0.1-SNAPSHOT\failsave.timeout.example-0.0.1-SNAPSHOT.jar [INFO] -- 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-607) Failsafe should create workingDirectory if it does not exist
[
http://jira.codehaus.org/browse/SUREFIRE-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed SUREFIRE-607.
-
Resolution: Fixed
Fix Version/s: 2.6
r923888
Failsafe should create workingDirectory if it does not exist
Key: SUREFIRE-607
URL: http://jira.codehaus.org/browse/SUREFIRE-607
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Failsafe Plugin
Environment: Fedora 11, Maven 2.2.1
Reporter: Peter Janes
Fix For: 2.6
Attachments: failsafe-workingDirectory.patch
Failsafe allows the user to set a workingDirectory, e.g.
lt;workingDirectorygt;${project.build.directory}/failsafe-working-directorylt;/workingDirectorygt;,
but if it doesn't exist the integration-test goal reports a
CommandLineException:
[INFO] Error while executing forked tests.; nested exception is
org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.CommandLineException:
Working directory /home/pjanes/failsafe/target/failsafe-working-directory
does not exist!
The attached patch creates the directory if it doesn't exist. This can also
be worked around by adding an instance of maven-antrun-plugin that invokes
Ant's lt;mkdirgt; task, but it seems like overkill and unnecessary
repetition to configure and invoke a completely separate plugin just to
create a directory.
(maven-surefire-plugin doesn't create its workingDirectory either.)
--
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-605) skip verify phase on Hudson CI
[ http://jira.codehaus.org/browse/SUREFIRE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-605: -- Priority: Minor (was: Major) skip verify phase on Hudson CI Key: SUREFIRE-605 URL: http://jira.codehaus.org/browse/SUREFIRE-605 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Reporter: nicolas de loof Priority: Minor On Hudson CI server, failsafe:verify will report a broken build on IT test error, not just unstable build. Hudson seems to detect the build has been failed from surefire plugin, not sure how it does -- 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-605) skip verify phase on Hudson CI
[ http://jira.codehaus.org/browse/SUREFIRE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=214062#action_214062 ] Stephen Connolly commented on SUREFIRE-605: --- This sounds more like a Hudson issue and not a failsafe issue skip verify phase on Hudson CI Key: SUREFIRE-605 URL: http://jira.codehaus.org/browse/SUREFIRE-605 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Reporter: nicolas de loof On Hudson CI server, failsafe:verify will report a broken build on IT test error, not just unstable build. Hudson seems to detect the build has been failed from surefire plugin, not sure how it does -- 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: (MRELEASE-549) Pin svn:externals when tagging
Pin svn:externals when tagging -- Key: MRELEASE-549 URL: http://jira.codehaus.org/browse/MRELEASE-549 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0 Reporter: Stephen Connolly svn:externals is a property set on directories in a subversion repository. there are two classes of svn:externals, ones which specify a revision and ones which do not. when creating a tag, the tag should only contain svn:externals which have been pinned to specific revisions, otherwise the tag is not a tag, i.e. it is subject to change. A generic solution (i.e. not SVN specific) would be to add preTagGoals and postTagGoals so that a custom goal could be invoked around creating the tag. -- 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] Work started: (SUREFIRE-592) Refactor plugins to remove duplicate code
[ http://jira.codehaus.org/browse/SUREFIRE-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SUREFIRE-592 started by Stephen Connolly. Refactor plugins to remove duplicate code - Key: SUREFIRE-592 URL: http://jira.codehaus.org/browse/SUREFIRE-592 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.5 Reporter: Stephen Connolly Assignee: Stephen Connolly Fix For: 2.6 After the addition of maven-failsafe-plugin there is now a fair bit of duplicate code between failsafe and surefire plugins. This code needs to be refactored into a single base class -- 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-592) Refactor plugins to remove duplicate code
[ http://jira.codehaus.org/browse/SUREFIRE-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221531#action_221531 ] Stephen Connolly commented on SUREFIRE-592: --- There has been a bit of discussion and the consensus view at the time is to keep the plugins separate but find a way for having the common code shared. I have made some progress on making the common code shared, I still have a little bit more refactoring to tidy things up some more before I am ready to mark this issue resolved Refactor plugins to remove duplicate code - Key: SUREFIRE-592 URL: http://jira.codehaus.org/browse/SUREFIRE-592 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.5 Reporter: Stephen Connolly Assignee: Stephen Connolly Fix For: 2.6 After the addition of maven-failsafe-plugin there is now a fair bit of duplicate code between failsafe and surefire plugins. This code needs to be refactored into a single base class -- 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-592) Refactor plugins to remove duplicate code
[ http://jira.codehaus.org/browse/SUREFIRE-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-592. - Resolution: Fixed r945183 looks to be all the refactoring I wanted to do. If more is needed/desired we can open another enhancement request Refactor plugins to remove duplicate code - Key: SUREFIRE-592 URL: http://jira.codehaus.org/browse/SUREFIRE-592 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.5 Reporter: Stephen Connolly Assignee: Stephen Connolly Fix For: 2.6 After the addition of maven-failsafe-plugin there is now a fair bit of duplicate code between failsafe and surefire plugins. This code needs to be refactored into a single base class -- 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-594) Create an integration test for r897240
[ http://jira.codehaus.org/browse/SUREFIRE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-594. - Resolution: Cannot Reproduce I could not reproduce the NPE using Maven 2.0.11, 2.2.1, or 3.0-beta-1 and Surefire 2.5. As a result I cannot create an integration test for same Create an integration test for r897240 -- Key: SUREFIRE-594 URL: http://jira.codehaus.org/browse/SUREFIRE-594 Project: Maven Surefire Issue Type: Task Affects Versions: 2.5 Reporter: Stephen Connolly Assignee: Stephen Connolly Priority: Minor Fix For: 2.6 to reproduce the failure, URL: http://svn.apache.org/repos/asf/maven/archetype/trunk Revision: 897208 when was giving an NPE. -- 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-605) skip verify phase on Hudson CI
[ http://jira.codehaus.org/browse/SUREFIRE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-605. - Resolution: Not A Bug This is a hudson issue not a maven issue skip verify phase on Hudson CI Key: SUREFIRE-605 URL: http://jira.codehaus.org/browse/SUREFIRE-605 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Reporter: nicolas de loof Priority: Minor On Hudson CI server, failsafe:verify will report a broken build on IT test error, not just unstable build. Hudson seems to detect the build has been failed from surefire plugin, not sure how it does -- 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-606) Provide a way for multiple executions of failsafe:integration-test to communicate with failsafe:verify (and the maven-surefire-report-plugin)
[
http://jira.codehaus.org/browse/SUREFIRE-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed SUREFIRE-606.
-
Resolution: Fixed
Fix Version/s: 2.6
r982554
Provide a way for multiple executions of failsafe:integration-test to
communicate with failsafe:verify (and the maven-surefire-report-plugin)
-
Key: SUREFIRE-606
URL: http://jira.codehaus.org/browse/SUREFIRE-606
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Failsafe Plugin
Reporter: Andreas Sewe
Priority: Minor
Fix For: 2.6
Providing such a means to communicate would be useful to support use cases
like the following, reported on the Maven users lists
(http://www.mail-archive.com/us...@maven.apache.org/msg104821.html):
{quote}
Our project has a set of integration tests that have to be passed using
*several* combinations of systemProperties/argLine. (Note that the test
classes are identical; only the configuration changes.)
Getting the tests to execute is easy; I just bind multiple executions of
failsafe:integration-test to the integration-test phase. Getting
failsafe:verify to pick up all tests results, however, is not, as I
wasn't able to figure out which parameters to tweak: summaryFile?
reportsDirectory?
{quote}
--
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-623) Docs say that Java 1.3 is supported, but minimum version is 1.4
[ http://jira.codehaus.org/browse/SUREFIRE-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-623. - Resolution: Fixed Fix Version/s: 2.6 r982558 Docs say that Java 1.3 is supported, but minimum version is 1.4 --- Key: SUREFIRE-623 URL: http://jira.codehaus.org/browse/SUREFIRE-623 Project: Maven Surefire Issue Type: Bug Components: documentation Affects Versions: 2.5 Environment: http://maven.apache.org/plugins/maven-surefire-plugin/plugin-info.html Reporter: SebbASF Fix For: 2.6 http://maven.apache.org/plugins/maven-surefire-plugin/plugin-info.html says: The following specifies the minimum requirements to run this Maven plugin: Maven 2.0.9 JDK 1.3 However I get the following error when using jvm 1.3: java.lang.NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter Exception in thread main Works OK with Java 1.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-142) Create new surefire:integration-test mojo for IT
[ http://jira.codehaus.org/browse/SUREFIRE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-142. - Resolution: Won't Fix Failsafe resolves this issue Create new surefire:integration-test mojo for IT Key: SUREFIRE-142 URL: http://jira.codehaus.org/browse/SUREFIRE-142 Project: Maven Surefire Issue Type: Task Reporter: Vincent Massol Fix For: Backlog See http://www.nabble.com/-PROPOSAL-Integration-testing-proposal-for-Maven-2.0.x-t980095.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] Commented: (SUREFIRE-85) java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedCheckedException
[ http://jira.codehaus.org/browse/SUREFIRE-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231051#action_231051 ] Stephen Connolly commented on SUREFIRE-85: -- we really need to see a sample test case to reproduce the issue java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedCheckedException - Key: SUREFIRE-85 URL: http://jira.codehaus.org/browse/SUREFIRE-85 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.0 (2.2 plugin) Environment: Windows XP / Sun JDK 1.5.0_06 Reporter: David J. M. Karlsen Fix For: 2.6 Attachments: log.txt java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedCheckedException Exception in thread main is thrown during execution of the maven-surefire-plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-615) Surefire providers shouldn't need to download old versions of the library
[ http://jira.codehaus.org/browse/SUREFIRE-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231052#action_231052 ] Stephen Connolly commented on SUREFIRE-615: --- my preference is the scopeprovided/scope option, what are other people's thoughts Surefire providers shouldn't need to download old versions of the library - Key: SUREFIRE-615 URL: http://jira.codehaus.org/browse/SUREFIRE-615 Project: Maven Surefire Issue Type: Improvement Components: JUnit 3.x support, Junit 4.x support, Maven Surefire Plugin, TestNG support Affects Versions: 2.5 Reporter: Brett Porter Fix For: 2.6 currently, the Surefire plugin uses resolveTransitively to obtain the Surefire provider (junit, junit4, junit47, testng). Each of these has a compile time dependency on the library itself to interact with their API. This results in downloading older versions as well as the newer one requested by the project (TestNG 5.7, JUnit 4.0, JUnit 3.8.1). There are two possible solutions to this: - alter the resolveTranstively method to exclude the artifact that is already available from the project - set the dependency to 'provided' in the providers POM -- 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-615) Surefire providers shouldn't need to download old versions of the library
[ http://jira.codehaus.org/browse/SUREFIRE-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-615. - Resolution: Fixed Assignee: Stephen Connolly r982995 unless the CI build fails and I have to revert back Surefire providers shouldn't need to download old versions of the library - Key: SUREFIRE-615 URL: http://jira.codehaus.org/browse/SUREFIRE-615 Project: Maven Surefire Issue Type: Improvement Components: JUnit 3.x support, Junit 4.x support, Maven Surefire Plugin, TestNG support Affects Versions: 2.5 Reporter: Brett Porter Assignee: Stephen Connolly Fix For: 2.6 currently, the Surefire plugin uses resolveTransitively to obtain the Surefire provider (junit, junit4, junit47, testng). Each of these has a compile time dependency on the library itself to interact with their API. This results in downloading older versions as well as the newer one requested by the project (TestNG 5.7, JUnit 4.0, JUnit 3.8.1). There are two possible solutions to this: - alter the resolveTranstively method to exclude the artifact that is already available from the project - set the dependency to 'provided' in the providers POM -- 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-85) java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedCheckedException
[ http://jira.codehaus.org/browse/SUREFIRE-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-85: - Fix Version/s: (was: 2.6) Backlog Moving to backlog until we are provided with a sample test case java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedCheckedException - Key: SUREFIRE-85 URL: http://jira.codehaus.org/browse/SUREFIRE-85 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.0 (2.2 plugin) Environment: Windows XP / Sun JDK 1.5.0_06 Reporter: David J. M. Karlsen Fix For: Backlog Attachments: log.txt java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedCheckedException Exception in thread main is thrown during execution of the maven-surefire-plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-615) Surefire providers shouldn't need to download old versions of the library
[ http://jira.codehaus.org/browse/SUREFIRE-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231433#action_231433 ] Stephen Connolly commented on SUREFIRE-615: --- r983549 reverse merged r982995 Surefire providers shouldn't need to download old versions of the library - Key: SUREFIRE-615 URL: http://jira.codehaus.org/browse/SUREFIRE-615 Project: Maven Surefire Issue Type: Improvement Components: JUnit 3.x support, Junit 4.x support, Maven Surefire Plugin, TestNG support Affects Versions: 2.5 Reporter: Brett Porter Assignee: Stephen Connolly Fix For: 2.6 currently, the Surefire plugin uses resolveTransitively to obtain the Surefire provider (junit, junit4, junit47, testng). Each of these has a compile time dependency on the library itself to interact with their API. This results in downloading older versions as well as the newer one requested by the project (TestNG 5.7, JUnit 4.0, JUnit 3.8.1). There are two possible solutions to this: - alter the resolveTranstively method to exclude the artifact that is already available from the project - set the dependency to 'provided' in the providers POM -- 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-615) Surefire providers shouldn't need to download old versions of the library
[ http://jira.codehaus.org/browse/SUREFIRE-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-615. - Resolution: Fixed r983577 Surefire providers shouldn't need to download old versions of the library - Key: SUREFIRE-615 URL: http://jira.codehaus.org/browse/SUREFIRE-615 Project: Maven Surefire Issue Type: Improvement Components: JUnit 3.x support, Junit 4.x support, Maven Surefire Plugin, TestNG support Affects Versions: 2.5 Reporter: Brett Porter Assignee: Stephen Connolly Fix For: 2.6 currently, the Surefire plugin uses resolveTransitively to obtain the Surefire provider (junit, junit4, junit47, testng). Each of these has a compile time dependency on the library itself to interact with their API. This results in downloading older versions as well as the newer one requested by the project (TestNG 5.7, JUnit 4.0, JUnit 3.8.1). There are two possible solutions to this: - alter the resolveTranstively method to exclude the artifact that is already available from the project - set the dependency to 'provided' in the providers POM -- 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
