[jira] Commented: (MCHECKSTYLE-165) Upgrade to checkstyle 5.5
[ https://jira.codehaus.org/browse/MCHECKSTYLE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283184#comment-283184 ] Ernst de Haan commented on MCHECKSTYLE-165: --- Note that 5.6 is apparently being prepared, see this commit (Nov 6, 2011): * http://checkstyle.hg.sourceforge.net/hgweb/checkstyle/checkstyle/rev/0019833f0b97 Upgrade to checkstyle 5.5 - Key: MCHECKSTYLE-165 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-165 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Reporter: Michael Pellaton Checkstyle 5.5 has bean released [1] recently. I suggest updating to that new version to allow for Java 7 based projects to make use of the maven-checkstyle-plugin. [1] http://checkstyle.sourceforge.net/releasenotes.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHECKSTYLE-166) Dro @requiresDependencyResolution test
Dro @requiresDependencyResolution test
--
Key: MCHECKSTYLE-166
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-166
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.8
Environment: N/A
Reporter: Ernst de Haan
Priority: Minor
Currently, the
[{{CheckstyleViolationCheckMojo}}|http://svn.apache.org/viewvc/maven/plugins/tags/maven-checkstyle-plugin-2.8/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleViolationCheckMojo.java?revision=1188083view=markup]
class declares:{code}@requiresDependencyResolution test{code}However, that
should not be necessary. Checkstyle works on source files, not on bytecode.
If this declaration would be removed, then this Checkstyle plugin should still
work perfectly fine (I would expect without any further code changes).
The advantage would be that in our Continuous Integration pipeline I can skip
the _compile_ stage and immediately trigger the _checkstyle_ stage. That would
save us multiple minutes on the feedback roundtrip.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-166) Dro @requiresDependencyResolution test
[
https://jira.codehaus.org/browse/MCHECKSTYLE-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283185#comment-283185
]
Ernst de Haan commented on MCHECKSTYLE-166:
---
In the title, _Dro_ should be _Drop_.
Dro @requiresDependencyResolution test
--
Key: MCHECKSTYLE-166
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-166
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.8
Environment: N/A
Reporter: Ernst de Haan
Priority: Minor
Currently, the
[{{CheckstyleViolationCheckMojo}}|http://svn.apache.org/viewvc/maven/plugins/tags/maven-checkstyle-plugin-2.8/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleViolationCheckMojo.java?revision=1188083view=markup]
class declares:{code}@requiresDependencyResolution test{code}However, that
should not be necessary. Checkstyle works on source files, not on bytecode.
If this declaration would be removed, then this Checkstyle plugin should
still work perfectly fine (I would expect without any further code changes).
The advantage would be that in our Continuous Integration pipeline I can skip
the _compile_ stage and immediately trigger the _checkstyle_ stage. That
would save us multiple minutes on the feedback roundtrip.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-577) dependencySet inside moduleSet/binaries picks up dependencies of other dependencySets
[ https://jira.codehaus.org/browse/MASSEMBLY-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283188#comment-283188 ] Filipe Dias commented on MASSEMBLY-577: --- I'm experiencing the same problem. dependencySet inside moduleSet/binaries picks up dependencies of other dependencySets - Key: MASSEMBLY-577 URL: https://jira.codehaus.org/browse/MASSEMBLY-577 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2.1 Environment: JDK 1.6_27, maven 3.0.2, Eclipse Indigo Reporter: Carlos Martins Attachments: moduleset-issue.zip Inside moduleset-issue.zip is a maven project (including eclipse indigo project files) The project has three modules: module-a, module-b and assembler. The assembler module used the assembly plugin with a descriptor. You can reproduce the issue by executing mvn package for the assembler module and then observing the file moduleset-issue/assebler/target/assembler-0.0.1-SNAPSHOT-bin.zip. The objective of the descriptor was to create a zip file with two directories: Directory A would include module-a and its dependencies and directory B would contain module-b and its dependencies. What happens is: both directories have all the dependencies. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-137) Use of @ delimiters
[
https://jira.codehaus.org/browse/MRESOURCES-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283189#comment-283189
]
David Bernard commented on MRESOURCES-137:
--
I have had success with this issue with the following:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
version2.5/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
configuration
userDefaultDelimitersfalse/userDefaultDelimiters
delimiters
delimiter${*}/delimiter
/delimiters
/configuration
/plugin
Use of @ delimiters
---
Key: MRESOURCES-137
URL: https://jira.codehaus.org/browse/MRESOURCES-137
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Components: delimiters
Affects Versions: 2.4.3
Reporter: Nathan Maves
As far as I can tell maven 2.x filtering does not use the @ delimiter by
default. The 2.4.3 version with maven 3.x adds this delimiter which breaks
existing filters.
I tried to override this using the code below and could not get it to work.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
version2.4.3/version
configuration
delimiters
delimiter${*}/delimiter
/delimiters
/configuration
/plugin
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-786) JUnit @Category are not taken into account if forkMode=always
JUnit @Category are not taken into account if forkMode=always - Key: SUREFIRE-786 URL: https://jira.codehaus.org/browse/SUREFIRE-786 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.11 Reporter: nkeywal Attachments: JUnit48TestCategoriesForkIT.java Selection by groups works if forkMode=once or none. Whith forkMode=always, it seems that all tests are executed. See attachment for a test case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-239) release:perform and release:prepare should accept multi-line goals/preparationGoals configurations
[
https://jira.codehaus.org/browse/MRELEASE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283190#comment-283190
]
Mass Dosage commented on MRELEASE-239:
--
I'm running version 2.2.1 of the maven-release-plugin and Maven 3. If we have a
preparationGoals element that spans more than one line like so:
{code}
configuration
preparationGoalsfm.last.maven:changelog-maven-plugin:verify
org.codehaus.mojo:buildnumber-maven-plugin:create
fm.last.maven:changelog-maven-plugin:update scm:checkin/preparationGoals
/configuration
{code}
The build fails with the following stack trace:
{code}
[INFO] /bin/sh: org.codehaus.mojo:buildnumber-maven-plugin:create: not found
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Last.fm parent POM FAILURE [15.067s]
[INFO] Last.fm Parent project with legacy project layout . SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 16.816s
[INFO] Finished at: Thu Nov 10 09:46:25 GMT 2011
[INFO] Final Memory: 7M/89M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare (default-cli) on
project parent: Maven execution failed, exit code: '127' - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare (default-cli) on
project parent: Maven execution failed, exit code: '127'
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Maven execution
failed, exit code: '127'
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:306)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:258)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Maven
execution failed, exit code: '127'
at
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:89)
at
org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:44)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:206)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:142)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:104)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:302)
... 22 more
Caused by: org.apache.maven.shared.release.exec.MavenExecutorException: Maven
execution failed, exit code: '127'
at
[jira] Commented: (MRELEASE-239) release:perform and release:prepare should accept multi-line goals/preparationGoals configurations
[ https://jira.codehaus.org/browse/MRELEASE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283191#comment-283191 ] Stephen Connolly commented on MRELEASE-239: --- One solution would be to create a profile that executes your required plugins and change the preparation goals to preparationGoals-Pprepare-release/preparationGoals where the profile would look something like profile idprepare-release/id build defaultGoalinitialize/defaultGoal !-- the phase that you are binding scm:checkin to -- plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdbuildnumber-maven-plugin/artifactId executions execution idprepare-release/id phasevalidate/phase goals goalcreate/goal /goals /execution /executions /plugin plugin groupIdfm.last.maven/groupId artifactIdchangelog-maven-plugin/artifactId executions execution idprepare-release/id phasevalidate/phase goals goalverify/goal !-- if this has to happens-before buildnumber then you will need to use a third phase rather than just validate and initialize, moving the buildnumber and update goals to the initialize phase and the scm:checkin to the generate-sources phase (or you could hijack the clean lifecycle (which might be no harm) and use pre-clean, clean and post-clean) -- goalupdate/goal /goals /execution /executions /plugin plugin artifactIdmaven-scm-plugin/artifactId executions execution idprepare-release/id phaseinitialize/phase goals goalcheckin/goal /goals /execution /executions /plugin But you should create a separate bug for the line separator issue anyway release:perform and release:prepare should accept multi-line goals/preparationGoals configurations -- Key: MRELEASE-239 URL: https://jira.codehaus.org/browse/MRELEASE-239 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0-beta-6 Reporter: Steve Rowe Assignee: Stephen Connolly Priority: Minor Fix For: 2.2.1 Attachments: ForkedMavenExecutor.patch When I specify a list of goals in my POM that span multiple lines (see an example below), only those goals before the newline are executed when I run mvn release:perform. I have only noticed this for release:perform, but given what the code looks like, I assume it's an issue for release:prepare too. This is a minor problem, but an irritating one, because release:peform claims to successfully complete without actually executing all specified goals. I attach a patch to ForkedMavenExecutor.java that splits the goals list on newlines and carriage returns, in addition to the comma and space split characters that were there already. Here's an example configuration that will trigger the problem: plugin artifactIdmaven-release-plugin/artifactId configuration ... goals package group:first-goal group:second-goal group:third-goal site-deploy changes:announcement-generate changes:announcement-mail /goals /configuration /plugin -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-239) release:perform and release:prepare should accept multi-line goals/preparationGoals configurations
[ https://jira.codehaus.org/browse/MRELEASE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283192#comment-283192 ] Stephen Connolly commented on MRELEASE-239: --- Actually, just I'll re-open this bug rather than open a new one release:perform and release:prepare should accept multi-line goals/preparationGoals configurations -- Key: MRELEASE-239 URL: https://jira.codehaus.org/browse/MRELEASE-239 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0-beta-6 Reporter: Steve Rowe Assignee: Stephen Connolly Priority: Minor Fix For: 2.2.1 Attachments: ForkedMavenExecutor.patch When I specify a list of goals in my POM that span multiple lines (see an example below), only those goals before the newline are executed when I run mvn release:perform. I have only noticed this for release:perform, but given what the code looks like, I assume it's an issue for release:prepare too. This is a minor problem, but an irritating one, because release:peform claims to successfully complete without actually executing all specified goals. I attach a patch to ForkedMavenExecutor.java that splits the goals list on newlines and carriage returns, in addition to the comma and space split characters that were there already. Here's an example configuration that will trigger the problem: plugin artifactIdmaven-release-plugin/artifactId configuration ... goals package group:first-goal group:second-goal group:third-goal site-deploy changes:announcement-generate changes:announcement-mail /goals /configuration /plugin -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MRELEASE-239) release:perform and release:prepare should accept multi-line goals/preparationGoals configurations
[ https://jira.codehaus.org/browse/MRELEASE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly reopened MRELEASE-239: --- Reopened according to user report release:perform and release:prepare should accept multi-line goals/preparationGoals configurations -- Key: MRELEASE-239 URL: https://jira.codehaus.org/browse/MRELEASE-239 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0-beta-6 Reporter: Steve Rowe Assignee: Stephen Connolly Priority: Minor Fix For: 2.2.1 Attachments: ForkedMavenExecutor.patch When I specify a list of goals in my POM that span multiple lines (see an example below), only those goals before the newline are executed when I run mvn release:perform. I have only noticed this for release:perform, but given what the code looks like, I assume it's an issue for release:prepare too. This is a minor problem, but an irritating one, because release:peform claims to successfully complete without actually executing all specified goals. I attach a patch to ForkedMavenExecutor.java that splits the goals list on newlines and carriage returns, in addition to the comma and space split characters that were there already. Here's an example configuration that will trigger the problem: plugin artifactIdmaven-release-plugin/artifactId configuration ... goals package group:first-goal group:second-goal group:third-goal site-deploy changes:announcement-generate changes:announcement-mail /goals /configuration /plugin -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-165) Upgrade to checkstyle 5.5
[
https://jira.codehaus.org/browse/MCHECKSTYLE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283196#comment-283196
]
Falko Modler commented on MCHECKSTYLE-165:
--
You should also remove this dependency exclusion:
{code:title=pom.xml|borderStyle=solid}
!-- checkstyle --
dependency
groupIdcom.puppycrawl.tools/groupId
artifactIdcheckstyle/artifactId
version${checkstyleVersion}/version
exclusions
!-- MCHECKSTYLE-156 --
exclusion
groupIdcom.sun/groupId
artifactIdtools/artifactId
/exclusion
/exclusions
/dependency
{code}
because since 5.4, checkstyle does not depend on com.sun.tools anymore!
Upgrade to checkstyle 5.5
-
Key: MCHECKSTYLE-165
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-165
Project: Maven 2.x Checkstyle Plugin
Issue Type: Improvement
Reporter: Michael Pellaton
Checkstyle 5.5 has bean released [1] recently. I suggest updating to that new
version to allow for Java 7 based projects to make use of the
maven-checkstyle-plugin.
[1] http://checkstyle.sourceforge.net/releasenotes.html
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-643) release:branch in mercurial provider updates the version in the new branch
release:branch in mercurial provider updates the version in the new branch -- Key: SCM-643 URL: https://jira.codehaus.org/browse/SCM-643 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-mercurial (hg) Affects Versions: 1.5, 1.6 Reporter: Jared Bunting Attachments: hg-scm-branch-fix.patch When running release:branch with a mercurial repository, and having all properties set to defaults, I would expect the current version to be carried over to the new branch, and the new developmentVersion to be set on the original branch. This is the behavior that I have always seen in the subversion provider (which is the only other one that I really have experience with), and what I believe the documentation states. However, that is not the behavior that I am seeing. I see the branch created, then the new version set on the branch. I believe the issue is that HgBranchCommand not only creates a new branch, but updates the working copy to the new branch. This seems to be counter to the behavior expected by maven-release-plugin, differs from the behavior in the subversion provider, and also seems to not be the behavior described in the ScmProvider interface. Since this updating to the new branch behavior is inherent to mercurial, I've written a patch that saves the original branch name prior to branching, and after branching is complete updates to the original branch. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5198) Error in starting maven - nullpointerexception
Error in starting maven - nullpointerexception -- Key: MNG-5198 URL: https://jira.codehaus.org/browse/MNG-5198 Project: Maven 2 3 Issue Type: Bug Components: Errors Affects Versions: 2.2.1 Environment: windows XP Reporter: pgp skr Attachments: maven_error.bmp When I run mvn --version I am getting the following error. java.lang.NullPointerException: key can't be null at java.lang.System.checkKey(System.java:773) at java.lang.System.getProperty(System.java:649) at org.codehaus.classworlds.Configurator.configure(Configurator.java:240 ) at org.codehaus.classworlds.Launcher.configure(Launcher.java:156) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:426) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) The following are the settings done for Maven set JAVA_HOME=D:/java/jdk1.6.0_02 set M2_HOME=D:/ReadNew/apache-maven-2.2.1 set M2=%M2_HOME%/bin After referring to the link (http://maven.40175.n5.nabble.com/Created-MNG-4865-mvn-fails-because-of-null-property-td3211656.html) I added the following entry in m2.conf set MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=256m But still the error persists. Could someone help me in resolving the same. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHECKSTYLE-165) Upgrade to checkstyle 5.5
[ https://jira.codehaus.org/browse/MCHECKSTYLE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCHECKSTYLE-165. Resolution: Fixed Fix Version/s: 2.9 Assignee: Olivier Lamy fixed r1200329. Upgrade to checkstyle 5.5 - Key: MCHECKSTYLE-165 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-165 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Reporter: Michael Pellaton Assignee: Olivier Lamy Fix For: 2.9 Checkstyle 5.5 has bean released [1] recently. I suggest updating to that new version to allow for Java 7 based projects to make use of the maven-checkstyle-plugin. [1] http://checkstyle.sourceforge.net/releasenotes.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
Return back org.apache.maven.user-settings and org.apache.maven.global-settings
properties
--
Key: MNG-5199
URL: https://jira.codehaus.org/browse/MNG-5199
Project: Maven 2 3
Issue Type: New Feature
Components: Settings
Affects Versions: 3.0.3
Reporter: Karel Piwko
According to discussion at
http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html,
I'm sure there is a valid use case for the property:
Imagine following:
{code}
mvn -s setting.xml test
{code}
Surefire has no way how to pass the path of the settings.xml in the spawned
process. If the test in spawned process want to for example access remote
repository defined in settings.xml, user has to specify settings.xml path in
the test itself.
However, for the following:
{code}
mvn -Dorg.apache.maven.user-settings=settings.xml test
{code}
This system property can be passed to surefire configuration and propagated to
the Surefire spawned process later on.
Having a system property removes duplication of the environment settings.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-786) JUnit @Category are not taken into account if forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nkeywal updated SUREFIRE-786: - Attachment: surefire786_trunk.patch The patch fixes the issue for the classes. Only the needed class tests will be executed. This do not cover the case when only a subset of tests should be executed. It seems that the filters are lost during the fork when forkMode=always (while it works for forkMode=once). For us, as we use tags on classes and all classes are tagged, it's enough anyway. JUnit @Category are not taken into account if forkMode=always - Key: SUREFIRE-786 URL: https://jira.codehaus.org/browse/SUREFIRE-786 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.11 Reporter: nkeywal Attachments: JUnit48TestCategoriesForkIT.java, surefire786_trunk.patch Selection by groups works if forkMode=once or none. Whith forkMode=always, it seems that all tests are executed. See attachment for a test case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-786) JUnit @Category are not taken into account if forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283206#comment-283206 ] nkeywal edited comment on SUREFIRE-786 at 11/10/11 8:28 AM: The patch fixes the issue for the classes. Only the needed class tests will be executed. This do not cover the case when only a subset of test methods should be executed within a class test: all methods will be executed. It seems that the filters are lost during the fork when forkMode=always (while it works with forkMode=once). For us, as we use tags on classes and all classes are tagged, it's enough anyway. was (Author: nkeywal): The patch fixes the issue for the classes. Only the needed class tests will be executed. This do not cover the case when only a subset of tests should be executed. It seems that the filters are lost during the fork when forkMode=always (while it works for forkMode=once). For us, as we use tags on classes and all classes are tagged, it's enough anyway. JUnit @Category are not taken into account if forkMode=always - Key: SUREFIRE-786 URL: https://jira.codehaus.org/browse/SUREFIRE-786 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.11 Reporter: nkeywal Attachments: JUnit48TestCategoriesForkIT.java, surefire786_trunk.patch Selection by groups works if forkMode=once or none. Whith forkMode=always, it seems that all tests are executed. See attachment for a test case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-642) GitSatusConsumer does not report deleted file
[ https://jira.codehaus.org/browse/SCM-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-642. Resolution: Fixed fixed r1200357. Thanks! GitSatusConsumer does not report deleted file - Key: SCM-642 URL: https://jira.codehaus.org/browse/SCM-642 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.5 Reporter: Bertrand Paquet Assignee: Olivier Lamy Priority: Minor Fix For: 1.6 Attachments: patch Take a git reposistory. Delete a file with git rm. Launche GitStatusCommand : the deleted file will not be reported by the GitStatusConsumer Bug is located around line 139 in GitStatusConsumer.java, the file cannot exists if status == ScmFileStatus.DELETED Patch attached -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-629) parsing server path starting with digit
[ https://jira.codehaus.org/browse/SCM-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-629. Resolution: Duplicate Fix Version/s: 1.6 Assignee: Olivier Lamy (was: Mark Struberg) parsing server path starting with digit --- Key: SCM-629 URL: https://jira.codehaus.org/browse/SCM-629 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.5 Reporter: Xavier Jodoin Assignee: Olivier Lamy Fix For: 1.6 Attachments: Capture.png, fix_repoPath_with_digit.patch scm:git:g...@github.com:360-Innovations/FJPAQuery.git it will get 360 as the server port -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGES-269) Move anchor location in changes.xml to header
Move anchor location in changes.xml to header - Key: MCHANGES-269 URL: https://jira.codehaus.org/browse/MCHANGES-269 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: changes.xml Affects Versions: 2.6 Reporter: Philip Maher Priority: Minor When navigating to one of the anchor links for a particular version on the page, the browser will take you past the header and directly to the table under the header such that the header is no longer visible. It would be a little bit better if the anchor link was tied to the header so that it's immediately clear that the navigation took you to the correct set of changes without needing to scroll back up the page. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-786) JUnit @Category are not taken into account if forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-786: Fix Version/s: 2.11 JUnit @Category are not taken into account if forkMode=always - Key: SUREFIRE-786 URL: https://jira.codehaus.org/browse/SUREFIRE-786 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.11 Reporter: nkeywal Assignee: Kristian Rosenvold Fix For: 2.11 Attachments: JUnit48TestCategoriesForkIT.java, surefire786_trunk.patch Selection by groups works if forkMode=once or none. Whith forkMode=always, it seems that all tests are executed. See attachment for a test case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-786) JUnit @Category are not taken into account if forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-786. --- Resolution: Fixed Assignee: Kristian Rosenvold Fixed in r1200541, thanks a lot for the patch! I added support testcase for methods too, and these are now also respected inside the fork, which was a long-standing serious bug JUnit @Category are not taken into account if forkMode=always - Key: SUREFIRE-786 URL: https://jira.codehaus.org/browse/SUREFIRE-786 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.11 Reporter: nkeywal Assignee: Kristian Rosenvold Attachments: JUnit48TestCategoriesForkIT.java, surefire786_trunk.patch Selection by groups works if forkMode=once or none. Whith forkMode=always, it seems that all tests are executed. See attachment for a test case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-329) Support for JUNIT extensions
[ https://jira.codehaus.org/browse/SUREFIRE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-329: Fix Version/s: (was: Backlog) 2.11 Support for JUNIT extensions Key: SUREFIRE-329 URL: https://jira.codehaus.org/browse/SUREFIRE-329 Project: Maven Surefire Issue Type: Wish Components: Junit 4.x support Reporter: Anuj Kathuria Assignee: Kristian Rosenvold Fix For: 2.11 Attachments: SUREFIRE329_branch329.patch, surefire-329.txt, surefire-329.txt Is there any plan to support using JUNIT extensions such as @Category,@PreRequisite with Maven2 SureFire plugin? The JUNIT EXTENSION URL: http://www.junitext.org/ We would like to specify the categories to run via a configurable option in the maven surefire plugin that supports JUNIT extensions See example Java Code: The following runs only tests with Category - Z. //In JUnit4 JUnitCore core = new JUnitCore(); // use for categories special listener, give some statistics core.addListener(new CategoryTextListener(System.out)); Request req = Request.aClass(SpcfTest.class); core.run(req.filterWith(new CategoryFilter(Z))); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-549) TestNg provider does not run junit tests correctly when forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-549. --- Resolution: Fixed Fix Version/s: 2.11 Assignee: Kristian Rosenvold As of r1200541, all the configuration properties are now properly sent to testng in forkmode always, this solves this issue too. In fact, I seem to be running into trouble if I *supply* the TestNG parameter, which I suppose might be related to junit version. Removing junit parameter works fine TestNg provider does not run junit tests correctly when forkMode=always --- Key: SUREFIRE-549 URL: https://jira.codehaus.org/browse/SUREFIRE-549 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.4.3 Reporter: Michael Pigg Assignee: Kristian Rosenvold Priority: Minor Fix For: 2.11 Attachments: SurefireJunitViaTestngProblem.zip We have both TestNG-based tests for unit testing and Junit-based tests (that use Spring OSGi test framework) for integration testing. When running the JUnit tests we would like to use forkMode=always to force the OSGi container to be created for each test. However, when forkMode=always is set, the TestNG provider does not properly run the JUnit test. In the default forkMode of once, the JUnit tests are executed. The problem is that the TestNGDirectoryTestSuite.execute method is coded to run both TestNG and JUnit tests when run for multiple test sets (which is executed for forkMode=once), but when run for one test it seems to assume that the test is a TestNG test. I think it should check for JUnit tests in either mode of execution. The work-around for the problem is to add the TestNG junit property to the surefire configuration when running the JUnit tests: properties property namejunit/name valuetrue/value /property /properties -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-656) JUnit 4.8 @Category support
[
https://jira.codehaus.org/browse/SUREFIRE-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-656.
---
Resolution: Fixed
Fix Version/s: 2.11
Assignee: Kristian Rosenvold
This issue is technically a duplicate of SUREFIRE-329, which is now fixed.
JUnit 4.8 @Category support
---
Key: SUREFIRE-656
URL: https://jira.codehaus.org/browse/SUREFIRE-656
Project: Maven Surefire
Issue Type: Improvement
Components: Junit 4.x support
Affects Versions: 2.7
Environment: any
Reporter: The Alchemist
Assignee: Kristian Rosenvold
Fix For: 2.11
I am interested in adding JUnit's {{@Category}} support. TestNG already has
group support in Surefire, so this would be a nice addition.
I'm wondering if someone could point me in the right direction.
Unfortunately, I'm not familiar with the Surefire source code.
1. Do I need to add another provider or something?
1. Should I just subclass {{SurefireTestSuite}} in the same manner as
{{JUnitCoreDirectoryTestSuite}}?
1. Should I model
Any help would be greatly appreciated. I have some free time and I'd love to
submit a patch this week.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-784) Surefire plugin cannot be debugged remotely by eclipse
[
https://jira.codehaus.org/browse/SUREFIRE-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283239#comment-283239
]
Kristian Rosenvold commented on SUREFIRE-784:
-
Exactly /why/ does the extract from ForkConfiguration explain anything ?
I have tried to reproduce /any/ of the symptoms/problems you describe here, and
try as I may I can't reproduce any of the problems you have. All is not lost,
though:
Make the necessary changes to demonstrate failure in an isolated example and
then upload the diff as a patch.
I somehow sense that your main problem is escape from the confines of the
isolated classloader, which is covered in the documentation
https://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/additional-classpath/
Unless you can produce a working isolated failing example, this issue will be
closed as cannot reproduce. If the problem would have been solved by improving
the documentation, do let us know what you think should be added.
Surefire plugin cannot be debugged remotely by eclipse
--
Key: SUREFIRE-784
URL: https://jira.codehaus.org/browse/SUREFIRE-784
Project: Maven Surefire
Issue Type: Story
Components: process forking
Affects Versions: 2.10
Environment: Eclipse indigo 20110916-0149
jdk1.6.0_27
Apache Maven 3.0.3 r1075438
Reporter: lisak
I'm talking about debugging the plugin/mojo, not tests.
Running maven with
{noformat}-Xdebug -Xnoagent
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000{noformat}
allows eclipse debugger to connect to the process of all maven plugins I
tried, except for surefire-plugin.
The breakpoint in AbstractSurefireMojo just isn't triggered.
I tried everything possible
-DforkMode=once
-DforkMode=never
mvnDebug
etc.
Any idea how to deal with this ?
I would need to add 200 jars on classpath to boot up Liferay portal :
{noformat}
additionalClasspathElements
additionalClasspathElement
/opt/liferay/portal/lib/development/*
/additionalClasspathElement
additionalClasspathElement
/opt/liferay/portal/lib/global/*
/additionalClasspathElement
additionalClasspathElement
/opt/liferay/portal/lib/portal/*
/additionalClasspathElement
/additionalClasspathElements
{noformat}
but it doesn't work. Neither *.jar wildcard ... Although
{noformat}/opt/liferay/portal/lib/portal/c3p0.jar{noformat}
works.
It is hard to figure out what is going on without debugging it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-336) dependency:get goal will always check the central repository for artifacts
dependency:get goal will always check the central repository for artifacts -- Key: MDEP-336 URL: https://jira.codehaus.org/browse/MDEP-336 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: get Affects Versions: 2.4 Reporter: Carlos Sanchez Assignee: Brian Fox dependency:get will always check the central repository defined in the super pom. The only solution right now is to use a mirror entry in your settings.xml org.apache.maven.project.artifact.MavenMetadataSource#aggregateRepositoryLists will always add the repository from the super pom -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-784) Surefire plugin cannot be debugged remotely by eclipse
[
https://jira.codehaus.org/browse/SUREFIRE-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283245#comment-283245
]
lisak commented on SUREFIRE-784:
It explains that you cannot useManifestOnlyJar if you need to append stuff with
wildcards to your overall classpath, see how Class-Path attribute is made in
createJar method.
And if you use Isolated classloader and the code you put on classpath via
additionalClasspathElements calls
{noformat}currentThread.getContextClassLoader(){noformat} the classloader
returned doesn't contained those classes from additionalClasspathElements...
Moreover TestNG and Junit behave differently
Surefire plugin cannot be debugged remotely by eclipse
--
Key: SUREFIRE-784
URL: https://jira.codehaus.org/browse/SUREFIRE-784
Project: Maven Surefire
Issue Type: Story
Components: process forking
Affects Versions: 2.10
Environment: Eclipse indigo 20110916-0149
jdk1.6.0_27
Apache Maven 3.0.3 r1075438
Reporter: lisak
I'm talking about debugging the plugin/mojo, not tests.
Running maven with
{noformat}-Xdebug -Xnoagent
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000{noformat}
allows eclipse debugger to connect to the process of all maven plugins I
tried, except for surefire-plugin.
The breakpoint in AbstractSurefireMojo just isn't triggered.
I tried everything possible
-DforkMode=once
-DforkMode=never
mvnDebug
etc.
Any idea how to deal with this ?
I would need to add 200 jars on classpath to boot up Liferay portal :
{noformat}
additionalClasspathElements
additionalClasspathElement
/opt/liferay/portal/lib/development/*
/additionalClasspathElement
additionalClasspathElement
/opt/liferay/portal/lib/global/*
/additionalClasspathElement
additionalClasspathElement
/opt/liferay/portal/lib/portal/*
/additionalClasspathElement
/additionalClasspathElements
{noformat}
but it doesn't work. Neither *.jar wildcard ... Although
{noformat}/opt/liferay/portal/lib/portal/c3p0.jar{noformat}
works.
It is hard to figure out what is going on without debugging it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MWAR-147) add the possibility to use the inplace goal with a specific out directory
[ https://jira.codehaus.org/browse/MWAR-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MWAR-147. Resolution: Won't Fix See previous comments. add the possibility to use the inplace goal with a specific out directory - Key: MWAR-147 URL: https://jira.codehaus.org/browse/MWAR-147 Project: Maven 2.x WAR Plugin Issue Type: Improvement Affects Versions: 2.1-alpha-1 Reporter: Dominique Jean-Prost I actually use war:exploded to speed up my development. I configured the webappDirectory so that the war gets produced in my jboss deploy directory. As war:exploded is bound to package phase, when I use mvn package, I then get a .war in my target dir and the exploded war in my jboss dir which not what I want. So I tried to use war:inplace, as it does what exploded does, but not bound to the package lifecycle. But inplace does not allow to override the out directory. So what I would like is to have a goal that allows me to have the exploded war in a specific directory, but I would like this goal to be not bound to the package lifecycle. Could you add this feature to the inplace goal ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
