[jira] Closed: (SUREFIRE-506) Maven runs suite() methods of all junit 3.x tests for each unit test even when forkMode is set to always
[ http://jira.codehaus.org/browse/SUREFIRE-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-506. --- Resolution: Fixed Fix Version/s: 2.7 Assignee: Kristian Rosenvold This should at least be fixed for 2.7. Possibly even earlier versions. Maven runs suite() methods of all junit 3.x tests for each unit test even when forkMode is set to always Key: SUREFIRE-506 URL: http://jira.codehaus.org/browse/SUREFIRE-506 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Affects Versions: 2.4.2 Environment: Windows XP, Java 1.6 Doesn't seem like an environment specific issue Reporter: anshul Assignee: Kristian Rosenvold Priority: Minor Fix For: 2.7 When running unit tests, if a project has junit 3 unit tests, and the pom has forkMode set to always, like so plugin artifactIdmaven-surefire-plugin/artifactId version2.4.2/version configuration disableXmlReporttrue/disableXmlReport forkModealways/forkMode /configuration /plugin the unit test runner invokes the suite() method of all the junit 3 unit tests, even though they will not be run within the specific fork of thats running just one unit tests. This can be confusing and may cause issues if the unit tests were doing some @BeforeClass style initializations in the suite() method. Moreover this may be inefficient. -- 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-550) Per-test or test group system properties
[ http://jira.codehaus.org/browse/SUREFIRE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-550. --- Resolution: Won't Fix Assignee: Kristian Rosenvold If you need to set -Dfile.encoding use forkMode=once and argLine. If you need to test multiple permutations you can use multiple executions of the surefire plugin with different settings. As for other common properties, common practice is to use a common base class for your tests. I'm marking this issue as won't fix, but feel free to reopen with additional information/argumentation. Per-test or test group system properties Key: SUREFIRE-550 URL: http://jira.codehaus.org/browse/SUREFIRE-550 Project: Maven Surefire Issue Type: Improvement Components: process forking Affects Versions: 2.4.3 Reporter: Benson Margulies Assignee: Kristian Rosenvold As a user of surefire, I want to be able to specify different system properties for different tests, so that I don't have to make extra projects just to organize these tests. For example, if I need to run a particular test with -Dfile.encoding set to a non-default value, I currently appear to need to create an entire maven project to contain this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-645) Meaningful message when test has no runnable methods
[ http://jira.codehaus.org/browse/SUREFIRE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-645: Fix Version/s: 2.7.1 Meaningful message when test has no runnable methods Key: SUREFIRE-645 URL: http://jira.codehaus.org/browse/SUREFIRE-645 Project: Maven Surefire Issue Type: Improvement Affects Versions: Backlog Reporter: Stefan Birkner Fix For: 2.7.1 Attachments: extendedErrorMessage.patch If there's a test class without any runnable methods, the test fails with an error. The output to the command line is: Tests in error: initializationError(EmptyTest) The supplied patch extends this message for all errors. For the error at hand, the output to the command line will be: Tests in error: initializationError(EmptyTest): No runnable methods -- 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: (MPIR-212) src/main/java does not exist for non-jar project
[
http://jira.codehaus.org/browse/MPIR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=247817#action_247817
]
Francis De Brabandere commented on MPIR-212:
could you point me to the snapshot repo?
src/main/java does not exist for non-jar project
Key: MPIR-212
URL: http://jira.codehaus.org/browse/MPIR-212
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: ubuntu linux maven 2.2.1
Reporter: Francis De Brabandere
Assignee: Lukas Theussl
Priority: Critical
Fix For: 2.4
We have our own custom packaging that does not compile java code.
Since the 2.3 plugin we get this issue while running mvn clean install site:
...
[INFO] [site:site {execution: default-site}]
[INFO] Not executing cobertura:report as the cobertura data file
(xxx/cobertura/cobertura.ser) could not be found
[INFO] Parent project loaded from repository: xxx-parent:pom:8-SNAPSHOT
[INFO] Skipped Surefire Report report, file surefire-report.html already
exists for the English version.
[INFO] Generating Continuous Integration report.
[INFO] Generating Project Summary report.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error during page generation
Embedded error: Error rendering Maven report: error while invoking generate
basedir xxx/src/main/java does not exist
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error during page
generation
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page
generation
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:123)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
rendering Maven report: error while invoking generate
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:171)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:330)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:154)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:118)
... 19 more
Caused by: org.apache.maven.reporting.MavenReportException: error while
invoking generate
at
org.apache.maven.plugins.site.ReportDocumentRenderer.generateMultiPage(ReportDocumentRenderer.java:248)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:157)
... 23 more
Caused by: java.lang.reflect.InvocationTargetException
at
[jira] Commented: (SUREFIRE-665) Output to file stops after a while
[ http://jira.codehaus.org/browse/SUREFIRE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=247818#action_247818 ] Tom Baeyens commented on SUREFIRE-665: -- The results with 2.7-SNAPSHOT are different, but still not OK. The first -output.txt files --this time in alfabetical order-- now contain the logging. The last file that contains logging is a big one (4,051,585 bytes) Console output: ... Running org.activiti.standalone.initialization.ProcessEnginesTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.255 sec Running org.activiti.standalone.interceptor.CommandContextTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.238 sec Results : Tests run: 465, Failures: 0, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error while executing forked tests.; nested exception is org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error while executing forked tests.; nested exception is org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) 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:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error while executing forked tests.; nested exception is org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:614) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) ... 17 more Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: Error while executing forked tests.; nested exception is org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:227) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnce(ForkStarter.java:118) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:102) at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:600) ... 19 more Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:227) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:114) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:223) ... 22 more Caused by: java.lang.NullPointerException at org.apache.maven.plugin.surefire.booterclient.output.FileOutputConsumerProxy.consumeOutputLine(FileOutputConsumerProxy.java:125) at org.apache.maven.plugin.surefire.booterclient.ForkingStreamConsumer.consumeLine(ForkingStreamConsumer.java:75) at
[jira] Commented: (MPIR-212) src/main/java does not exist for non-jar project
[
http://jira.codehaus.org/browse/MPIR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=247823#action_247823
]
Lukas Theussl commented on MPIR-212:
See
http://maven.apache.org/guides/development/guide-testing-development-plugins.html,
the version is 2.4-SNAPSHOT.
src/main/java does not exist for non-jar project
Key: MPIR-212
URL: http://jira.codehaus.org/browse/MPIR-212
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: ubuntu linux maven 2.2.1
Reporter: Francis De Brabandere
Assignee: Lukas Theussl
Priority: Critical
Fix For: 2.4
We have our own custom packaging that does not compile java code.
Since the 2.3 plugin we get this issue while running mvn clean install site:
...
[INFO] [site:site {execution: default-site}]
[INFO] Not executing cobertura:report as the cobertura data file
(xxx/cobertura/cobertura.ser) could not be found
[INFO] Parent project loaded from repository: xxx-parent:pom:8-SNAPSHOT
[INFO] Skipped Surefire Report report, file surefire-report.html already
exists for the English version.
[INFO] Generating Continuous Integration report.
[INFO] Generating Project Summary report.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error during page generation
Embedded error: Error rendering Maven report: error while invoking generate
basedir xxx/src/main/java does not exist
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error during page
generation
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page
generation
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:123)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
rendering Maven report: error while invoking generate
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:171)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:330)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:154)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:118)
... 19 more
Caused by: org.apache.maven.reporting.MavenReportException: error while
invoking generate
at
org.apache.maven.plugins.site.ReportDocumentRenderer.generateMultiPage(ReportDocumentRenderer.java:248)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:157)
... 23 more
Caused by:
[jira] Commented: (MPIR-212) src/main/java does not exist for non-jar project
[
http://jira.codehaus.org/browse/MPIR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=247825#action_247825
]
Francis De Brabandere commented on MPIR-212:
found it: https://repository.apache.org/content/repositories/snapshots
I just tested the snapshot and the problem is fixed.
src/main/java does not exist for non-jar project
Key: MPIR-212
URL: http://jira.codehaus.org/browse/MPIR-212
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: ubuntu linux maven 2.2.1
Reporter: Francis De Brabandere
Assignee: Lukas Theussl
Priority: Critical
Fix For: 2.4
We have our own custom packaging that does not compile java code.
Since the 2.3 plugin we get this issue while running mvn clean install site:
...
[INFO] [site:site {execution: default-site}]
[INFO] Not executing cobertura:report as the cobertura data file
(xxx/cobertura/cobertura.ser) could not be found
[INFO] Parent project loaded from repository: xxx-parent:pom:8-SNAPSHOT
[INFO] Skipped Surefire Report report, file surefire-report.html already
exists for the English version.
[INFO] Generating Continuous Integration report.
[INFO] Generating Project Summary report.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error during page generation
Embedded error: Error rendering Maven report: error while invoking generate
basedir xxx/src/main/java does not exist
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error during page
generation
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page
generation
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:123)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
rendering Maven report: error while invoking generate
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:171)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:330)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:154)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:118)
... 19 more
Caused by: org.apache.maven.reporting.MavenReportException: error while
invoking generate
at
org.apache.maven.plugins.site.ReportDocumentRenderer.generateMultiPage(ReportDocumentRenderer.java:248)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:157)
... 23 more
Caused by:
[jira] Updated: (SCM-588) Filehandle leak in AccuRev provider
[ http://jira.codehaus.org/browse/SCM-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-588: - Fix Version/s: 1.5 Assignee: Olivier Lamy Filehandle leak in AccuRev provider --- Key: SCM-588 URL: http://jira.codehaus.org/browse/SCM-588 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-accurev Affects Versions: 1.4 Environment: linux Reporter: Grant Gardner Assignee: Olivier Lamy Fix For: 1.5 Attachments: SCM-588.patch XppStreamConsumer uses a pipe but only closes one side which causes a file handle leak under linux. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-589) Upgrade Plexus Utils to avoid filehandle leak
[ http://jira.codehaus.org/browse/SCM-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-589: - Fix Version/s: 1.5 Assignee: Olivier Lamy Upgrade Plexus Utils to avoid filehandle leak - Key: SCM-589 URL: http://jira.codehaus.org/browse/SCM-589 Project: Maven SCM Issue Type: Bug Affects Versions: 1.4 Environment: linux Reporter: Grant Gardner Assignee: Olivier Lamy Priority: Minor Fix For: 1.5 Plexus-utils 1.5.6 has a bad filehandle leak (non destroyed Runtime.exec) in CommandLine.addSystemEnvironment() which is called by the VSS, svnexe and the AccuRev providers. 2.0.5 seems to work. -- 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: (MPIR-213) Building a non-Java project breaks
[ http://jira.codehaus.org/browse/MPIR-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPIR-213. -- Resolution: Duplicate Assignee: Lukas Theussl Building a non-Java project breaks -- Key: MPIR-213 URL: http://jira.codehaus.org/browse/MPIR-213 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: summary Affects Versions: 2.3 Environment: Max OSX 10.6.5, Maven 3.0.1 (maven-site-plugin:3.0-beta-3) Reporter: Martin Ahrer Assignee: Lukas Theussl Attachments: pom.xml Building a non-Java project causes a build to fail with .../src/main/java does not exist. Eventually this is related to MPIR-212. Here Maven3 is used!!! --- tahiti:TEST martin$ mvn3 clean site [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building TEST 1.0 [INFO] [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ TEST --- [INFO] Deleting /Volumes/Data/Development/eclipse-3.6-workspace/TEST/target [INFO] [INFO] --- maven-site-plugin:3.0-beta-3:site (default-site) @ TEST --- [INFO] configuring report plugin org.apache.maven.plugins:maven-project-info-reports-plugin:2.3 [WARNING] No URL defined for the project - decoration links will not be resolved [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0 skin. [INFO] Generating Project Summary report--- maven-project-info-reports-plugin:2.3 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2.371s [INFO] Finished at: Tue Dec 14 21:17:04 CET 2010 [INFO] Final Memory: 13M/81M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site) on project TEST: Execution default-site of goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site failed: basedir /Volumes/Data/Development/eclipse-3.6-workspace/TEST/src/main/java does not exist - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException -- 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: (MWAR-245) overlay feature rejects .tar.gz
[ http://jira.codehaus.org/browse/MWAR-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=247832#action_247832 ] Benson Margulies commented on MWAR-245: --- What I'm using it for is to add some large resources to a war. Statistical models, that sort of thing. There is doc on just using the dependency plugin, but that leads to an extra copy if I'm not more confused than usual. overlay feature rejects .tar.gz --- Key: MWAR-245 URL: http://jira.codehaus.org/browse/MWAR-245 Project: Maven 2.x WAR Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Benson Margulies Priority: Minor [WARNING] Skip unpacking dependency file [/Users/benson/.m2/repository/com/basistech/coref-model/2/coref-model-2.tar.gz with unknown extension [gz] It seems to me that the war plugin should support all the formats that the assembly plugin can produce. -- 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: (MPIR-143) Wrong scope/phase requirement documented on project-info-reports:dependencies page
[ http://jira.codehaus.org/browse/MPIR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=247838#action_247838 ] Lukas Theussl commented on MPIR-143: There is no package value for requiresDependencyResolution and test already resolves all dependency scopes, see http://maven.apache.org/developers/mojo-api-specification.html. Maybe you can attach a small test project? Wrong scope/phase requirement documented on project-info-reports:dependencies page -- Key: MPIR-143 URL: http://jira.codehaus.org/browse/MPIR-143 Project: Maven 2.x Project Info Reports Plugin Issue Type: Task Affects Versions: 2.1 Environment: maven 2.0.9 Reporter: Stevo Slavic Priority: Minor After discussion on maven user mailing list (see http://markmail.org/search/?q=sslavic%20list%3Aorg.apache.maven.users#query:sslavic%20list%3Aorg.apache.maven.users+page:2+mid:kkzcdmruemiwpeei+state:results ) conclusion was that wrong scope is documented on following page: http://maven.apache.org/plugins/maven-project-info-reports-plugin/dependencies-mojo.html in Attributes section where instead of test in Requires dependency resolution of artifacts in scope: test. it should stand package. -- 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: (MRELEASE-454) The Release-Plugin does not rewrite dependencies in the DependencyManagement with scope import
[ http://jira.codehaus.org/browse/MRELEASE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Rodriguez updated MRELEASE-454: - Attachment: MRELEASE-454.diff A diff file with the documented changes to fix this issue The Release-Plugin does not rewrite dependencies in the DependencyManagement with scope import Key: MRELEASE-454 URL: http://jira.codehaus.org/browse/MRELEASE-454 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-9 Reporter: Jens Mühlenhoff Attachments: MRELEASE-454.diff Add the following node to the pom. Then prepare the release and this section will not be rewriten, because the imported entry will not appear in project.getDependencyManagement().getDependencies(). This methode returns all the resolved dependencies. In this situation the transformDocument method from AbstractRewritePomsPhase could not change the given dependencies, because it is not visible to the method. dependencyManagement dependencies dependency groupIddist/groupId artifactIddeps/artifactId typepom/type version4.0.4-SNAPSHOT/version scopeimport/scope /dependency /dependencies /dependencyManagement -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4935) Filter classloader information in debug output (or create a new debug switch)
Filter classloader information in debug output (or create a new debug switch)
-
Key: MNG-4935
URL: http://jira.codehaus.org/browse/MNG-4935
Project: Maven 2 3
Issue Type: Improvement
Components: Logging
Environment: Maven 2.2.1 all Maven 2 versions tested (don't know
about Maven 3)
Reporter: Costin Caraivan
When running Maven 2 with the -X flag, the debug output contains useful debug
output, like plugin configuration information, various information about the
information, and A LOT of classloading information, which is mostly useful for
Maven developers or plugin developers.
I think it would be good to add an additional flag to the debug mode
(--extra-debug, -xd), which would trigger adding classloading information to
the debug mode. I know this is not a minor issue, since this would require
another debugging level (at least from what I can figure), but it would be VERY
useful for users.
We literally have hundreds of thousands of these lines in a build launched with
-X. Causing all sorts of problems when loading them through a web interface for
example (Hudson).
Compare this:
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-clean-plugin:2.2:clean' --
[DEBUG] (f) directory =
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\target
[DEBUG] (f) failOnError = true
[DEBUG] (f) followSymLinks = false
[DEBUG] (f) outputDirectory =
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\target\classes
[DEBUG] (f) project = MavenProject: com.axway.$project:all-$project:3.6.1-SP6
@
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\pom.xml
[DEBUG] (f) reportDirectory =
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\target\site
[DEBUG] (f) skip = false
[DEBUG] (f) testOutputDirectory =
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\target\test-classes
[DEBUG] (f) verbose = false
[DEBUG] -- end configuration --
[INFO] [clean:clean {execution: default-clean}]
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:11
for project: null:maven-site-plugin:maven-plugin:2.0-beta-7 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:8 for project:
org.apache.maven.plugins:maven-plugins:pom:11 from the repository.
[DEBUG] Configuring mojo
'com.axway.maven2.plugins:axway-timestamp-plugin:1.0.1:timestamp' --
[DEBUG] (s) language = en
[DEBUG] (s) project = MavenProject: com.axway.$project:all-$project:3.6.1-SP6
@
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\pom.xml
[DEBUG] (s) properties = {time.buildtime=-MM-dd HH:mm,
time.timestamp=MMddHHmm}
[DEBUG] (s) session = org.apache.maven.execution.mavensess...@48f675
[DEBUG] -- end configuration --
[INFO] [timestamp:timestamp {execution: timestamp}]
[INFO] Defining new property time.buildtime to 2010-12-15 17:32
[INFO] Defining new property time.timestamp to 201012151732
[DEBUG] Configuring mojo
'com.axway.maven2.plugins:axway-version-plugin:2.0.9:xversion' --
[DEBUG] (s) elementDescriptions = {extensionpack={0} Extension-Pack {1},
patch={0} Patch {2}, servicepack={0} Service-Pack {1}, upgradepack={0}
Upgrade-Pack {1}}
[DEBUG] (s) elementIdentifiers = {extensionpack=EP, patch=Patch,
servicepack=SP, upgradepack=UP}
[DEBUG] (s) elementTypeNames = {extensionpack=EP, patch=PATCH,
servicepack=SP, upgradepack=UP}
[DEBUG] (s) patchDescription = {0} Patch {1}
[DEBUG] (s) patchMark = P
[DEBUG] (s) patchType = PATCH
[DEBUG] (s) project = MavenProject: com.axway.$project:all-$project:3.6.1-SP6
@
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\pom.xml
[DEBUG] (s) servicePackDescription = {0} Service-Pack {1}
[DEBUG] (s) servicePackMark = SP
[DEBUG] (s) servicePackType = SP
[DEBUG] (f) updateTargetVersion = 0.0.0
[DEBUG] (s) usedInBranches = [servicepack]
[DEBUG] (s) usedInValidations = [patch]
[DEBUG] -- end configuration --
[INFO] [axway-version:xversion {execution: version}]
[INFO] Defining new property axway.version.major to 3.6.1
[INFO] Defining new property axway.version.patch to
[INFO] Defining new property axway.version.servicepack.name to SP6
[INFO] Defining new property axway.version.servicepack.number to 6
[INFO] No extensionpack found in project version format
[DEBUG] Skipping already defined property axway.version.patch
[INFO] Defining new property axway.version.extensionpack.name to
[INFO] Defining new property axway.version.extensionpack.number to 0
[INFO] No patch found in project version format
[DEBUG] Skipping already defined property axway.version.patch
[INFO] Defining new property axway.version.patch.name to
[INFO] Defining new property axway.version.patch.number to 0
[INFO] No
[jira] Created: (MINDEXER-4) Upgrade to Lucene 3.0.3
Upgrade to Lucene 3.0.3 --- Key: MINDEXER-4 URL: http://jira.codehaus.org/browse/MINDEXER-4 Project: Maven Indexer Issue Type: Improvement Reporter: Tamás Cservenák Upgrade to Lucene 3.0.3. Indexer already used a lot of deprecated features from it's currently used Lucene 2.4.1, and also we should take advantage of new features (partially present in 2.4.1 too, like RO readers) -- 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: (MINDEXER-4) Upgrade to Lucene 3.0.3
[ http://jira.codehaus.org/browse/MINDEXER-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MINDEXER-4. -- Resolution: Fixed Fix Version/s: 4.0.0 Fixed in trunk, will be in version 4.0.0. The 3.2.0 maintenance branch remains with old 2.4.1 Lucene. http://svn.apache.org/viewvc?view=revisionrevision=1045125 Upgrade to Lucene 3.0.3 --- Key: MINDEXER-4 URL: http://jira.codehaus.org/browse/MINDEXER-4 Project: Maven Indexer Issue Type: Improvement Reporter: Tamás Cservenák Assignee: Tamás Cservenák Fix For: 4.0.0 Upgrade to Lucene 3.0.3. Indexer already used a lot of deprecated features from it's currently used Lucene 2.4.1, and also we should take advantage of new features (partially present in 2.4.1 too, like RO readers) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3463) AsbtractMojo should look for LoggerManager plexus component
[
http://jira.codehaus.org/browse/MNG-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-3463.
--
Resolution: Fixed
Fix Version/s: (was: Issues to be reviewed for 3.x)
2.0.9
Assignee: Benjamin Bentmann
Looking at the {{DefaultPluginManager}}, the mojo logger is already delegating
to a plexus logger since ages.
AsbtractMojo should look for LoggerManager plexus component
---
Key: MNG-3463
URL: http://jira.codehaus.org/browse/MNG-3463
Project: Maven 2 3
Issue Type: Improvement
Components: Logging
Reporter: Robert Egan
Assignee: Benjamin Bentmann
Fix For: 2.0.9
AbstractMojo currently defines it's own Log interface, hard coded to use
System.out. This really restricts the logging capabilities of all plugins. It
would be nice if it attempted to look up the plexus role
org.codehaus.plexus.logging.LoggerManager first and only used System.out if
that failed.
Doing this would also go a long way towards resolving MNG-2570 and MNG-3305.
--
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: (MNG-2570) Maven needs to support multiple logging levels
[ http://jira.codehaus.org/browse/MNG-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=247859#action_247859 ] Costin Caraivan edited comment on MNG-2570 at 12/15/10 10:12 AM: - I'm not sure it's the same thing as mentioned by the original reporter, but from what I saw while working with Maven and from what I see the developers needing, the default mode is ok (verbose). The debug modes could be improved, however, for example: -X, --debug - default debug output, without classloading information (no dependencies, and especially no managed dependencies) -Xd, --extra-debug - extra debug information, the current -X The current debug mode usually has something like 1% useful information while debugging plugin problems, configuration problems. We have hundreds of thousands of lines of lines showing managed/transitive dependencies for big builds, when all we want to see is: what was the real parameter used by Maven when launching the jarsigner (for example)... was (Author: ccaraivan): I'm not sure it's the same thing as mentioned by the original reporter, but from what I saw while working with Maven and from what I see the developers needing, the default mode is ok (verbose). The debug modes should be: -X, --debug - default debug output, without classloading information (no dependencies, and especially no managed dependencies) -Xd, --extra-debug - extra debug information, the current -X The current debug mode usually has something like 1% useful information while debugging plugin problems, configuration problems. We have hundreds of thousands of lines of lines showing managed/transitive dependencies for big builds, when all we want to see is: what was the real parameter used by Maven when launching the jarsigner (for example)... Maven needs to support multiple logging levels -- Key: MNG-2570 URL: http://jira.codehaus.org/browse/MNG-2570 Project: Maven 2 3 Issue Type: Improvement Components: Logging Affects Versions: 2.0.4 Reporter: Brian Fox Fix For: Issues to be reviewed for 3.x The current logging levels are essentially verbose (default) and debug (-X). We need a slightly less verbose output so that things like compiler warnings and other output is actually visable to the developer. Currently it gets buried in all the noise. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2570) Maven needs to support multiple logging levels
[ http://jira.codehaus.org/browse/MNG-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=247859#action_247859 ] Costin Caraivan commented on MNG-2570: -- I'm not sure it's the same thing as mentioned by the original reporter, but from what I saw while working with Maven and from what I see the developers needing, the default mode is ok (verbose). The debug modes should be: -X, --debug - default debug output, without classloading information (no dependencies, and especially no managed dependencies) -Xd, --extra-debug - extra debug information, the current -X The current debug mode usually has something like 1% useful information while debugging plugin problems, configuration problems. We have hundreds of thousands of lines of lines showing managed/transitive dependencies for big builds, when all we want to see is: what was the real parameter used by Maven when launching the jarsigner (for example)... Maven needs to support multiple logging levels -- Key: MNG-2570 URL: http://jira.codehaus.org/browse/MNG-2570 Project: Maven 2 3 Issue Type: Improvement Components: Logging Affects Versions: 2.0.4 Reporter: Brian Fox Fix For: Issues to be reviewed for 3.x The current logging levels are essentially verbose (default) and debug (-X). We need a slightly less verbose output so that things like compiler warnings and other output is actually visable to the developer. Currently it gets buried in all the noise. -- 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-257) includeClassifiers / seems to have no effect
[
http://jira.codehaus.org/browse/MDEP-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=247860#action_247860
]
Wouter Coekaerts commented on MDEP-257:
---
I've got exactly the same problem: it looks like includeClassifiers is simply
ignored in the unpack-dependencies goal.
The linked MDEP-193 ticket is closed with fix version 2.2, but I still have the
problem with 2.2.
includeClassifiers / seems to have no effect
--
Key: MDEP-257
URL: http://jira.codehaus.org/browse/MDEP-257
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack-dependencies
Affects Versions: 2.1
Environment: Windows XP
Reporter: Patrick Aikens
Assignee: Brian Fox
I'm trying to package some installer-related files from a project for use in
a different izpack installer project. I want to unpack them into the
target/staging directory for inclusion in the izpack installer. All of the
dependencies I want to unpack have a classifier of izpack. Using the
following configuration, the dependency plugin unpacks ALL dependencies, not
just the ones with an izpack classifier.
{code:xml}
plugin
artifactIdmaven-dependency-plugin/artifactId
version2.1/version
executions
execution
idizpack/id
phasegenerate-resources/phase
goals
goalunpack-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/staging/outputDirectory
includeClassifiersizpack/includeClassifiers
/configuration
/execution
/executions
/plugin
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-240) archiveClasses and attachClasses in 2.1
[
http://jira.codehaus.org/browse/MWAR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=248188#action_248188
]
Eric Olander commented on MWAR-240:
---
I see the same problem using Maven 3.0.1 and maven-war-plugin 2.1.1
archiveClasses and attachClasses in 2.1
---
Key: MWAR-240
URL: http://jira.codehaus.org/browse/MWAR-240
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_18
Default locale: de_DE, platform encoding: Cp1252
OS name: windows 7 version: 6.1 arch: amd64 Family: windows
Reporter: Sergiy Shyrkov
Attachments: effective-pom.out, mwar-240-test-case.zip
There seems to be a regression between 2.1-beta-1 and 2.1 with regard to
archiveClasses and attachClasses options.
My use case:
I have a WAR project with Java classes and I am setting both archiveClasses
and attachClasses to true.
With 2.1-beta-1 it was working correctly (mvn clean install) -- I got
classes packaged into a JAR and placed into WEB-INF/lib and I got that JAR
artifact deployed to my Maven repository.
Just upgraded to 2.1 and I got the following with the same use case: I got
classes packaged into a JAR and placed into WEB-INF/lib (correct) and I got
an empty JAR artifact (only META-INF/ present) deployed to my Maven
repository (incorrect).
Looking at the code in 2.1 of WarMojo (line 230) I am seeing that the classes
folder (for classes to be included into attached artifact) is empty, because
it was cleared before due to archiveClasses=true
Trying to debug both code branches I am seeing a difference between
2.1-beta-1 and 2.1 in that the
getJarArchiver().getDirs() before the call to packager.packageClasses()
method (line 233/234)
is empty in the 2.1:
(java.util.HashMapK,V) {}
whereas it is not in 2.1-beta-1. It contains a list of all my classes,
perhaps because the same archiver instance was used to package them into JAR
for WEB-INF/lib.
That is why I am getting all my classes in the attached artifact with
2.1-beta-1
I would really need your help in understanding the correct behaviour.
Is this a regression bug for 2.1 or I am completely wrong in my expectations
about archiveClasses and attachClasses used together?
Kind regards
Sergiy Shyrkov
--
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: (MDEP-257) includeClassifiers / seems to have no effect
[
http://jira.codehaus.org/browse/MDEP-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=247860#action_247860
]
Wouter Coekaerts edited comment on MDEP-257 at 12/15/10 10:58 AM:
--
[Edited to remove. My mistake.]
was (Author: coekie):
I've got exactly the same problem: it looks like includeClassifiers is
simply ignored in the unpack-dependencies goal.
The linked MDEP-193 ticket is closed with fix version 2.2, but I still have the
problem with 2.2.
includeClassifiers / seems to have no effect
--
Key: MDEP-257
URL: http://jira.codehaus.org/browse/MDEP-257
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack-dependencies
Affects Versions: 2.1
Environment: Windows XP
Reporter: Patrick Aikens
Assignee: Brian Fox
I'm trying to package some installer-related files from a project for use in
a different izpack installer project. I want to unpack them into the
target/staging directory for inclusion in the izpack installer. All of the
dependencies I want to unpack have a classifier of izpack. Using the
following configuration, the dependency plugin unpacks ALL dependencies, not
just the ones with an izpack classifier.
{code:xml}
plugin
artifactIdmaven-dependency-plugin/artifactId
version2.1/version
executions
execution
idizpack/id
phasegenerate-resources/phase
goals
goalunpack-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/staging/outputDirectory
includeClassifiersizpack/includeClassifiers
/configuration
/execution
/executions
/plugin
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4935) Filter classloader information in debug output (or create a new debug switch)
[
http://jira.codehaus.org/browse/MNG-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4935.
--
Resolution: Duplicate
Assignee: Benjamin Bentmann
Filter classloader information in debug output (or create a new debug switch)
-
Key: MNG-4935
URL: http://jira.codehaus.org/browse/MNG-4935
Project: Maven 2 3
Issue Type: Improvement
Components: Logging
Environment: Maven 2.2.1 all Maven 2 versions tested (don't know
about Maven 3)
Reporter: Costin Caraivan
Assignee: Benjamin Bentmann
When running Maven 2 with the -X flag, the debug output contains useful debug
output, like plugin configuration information, various information about the
information, and A LOT of classloading information, which is mostly useful
for Maven developers or plugin developers.
I think it would be good to add an additional flag to the debug mode
(--extra-debug, -xd), which would trigger adding classloading information to
the debug mode. I know this is not a minor issue, since this would require
another debugging level (at least from what I can figure), but it would be
VERY useful for users.
We literally have hundreds of thousands of these lines in a build launched
with -X. Causing all sorts of problems when loading them through a web
interface for example (Hudson).
Compare this:
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-clean-plugin:2.2:clean' --
[DEBUG] (f) directory =
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\target
[DEBUG] (f) failOnError = true
[DEBUG] (f) followSymLinks = false
[DEBUG] (f) outputDirectory =
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\target\classes
[DEBUG] (f) project = MavenProject:
com.axway.$project:all-$project:3.6.1-SP6 @
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\pom.xml
[DEBUG] (f) reportDirectory =
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\target\site
[DEBUG] (f) skip = false
[DEBUG] (f) testOutputDirectory =
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\target\test-classes
[DEBUG] (f) verbose = false
[DEBUG] -- end configuration --
[INFO] [clean:clean {execution: default-clean}]
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:11
for project: null:maven-site-plugin:maven-plugin:2.0-beta-7 from the
repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:8 for
project: org.apache.maven.plugins:maven-plugins:pom:11 from the repository.
[DEBUG] Configuring mojo
'com.axway.maven2.plugins:axway-timestamp-plugin:1.0.1:timestamp' --
[DEBUG] (s) language = en
[DEBUG] (s) project = MavenProject:
com.axway.$project:all-$project:3.6.1-SP6 @
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\pom.xml
[DEBUG] (s) properties = {time.buildtime=-MM-dd HH:mm,
time.timestamp=MMddHHmm}
[DEBUG] (s) session = org.apache.maven.execution.mavensess...@48f675
[DEBUG] -- end configuration --
[INFO] [timestamp:timestamp {execution: timestamp}]
[INFO] Defining new property time.buildtime to 2010-12-15 17:32
[INFO] Defining new property time.timestamp to 201012151732
[DEBUG] Configuring mojo
'com.axway.maven2.plugins:axway-version-plugin:2.0.9:xversion' --
[DEBUG] (s) elementDescriptions = {extensionpack={0} Extension-Pack {1},
patch={0} Patch {2}, servicepack={0} Service-Pack {1}, upgradepack={0}
Upgrade-Pack {1}}
[DEBUG] (s) elementIdentifiers = {extensionpack=EP, patch=Patch,
servicepack=SP, upgradepack=UP}
[DEBUG] (s) elementTypeNames = {extensionpack=EP, patch=PATCH,
servicepack=SP, upgradepack=UP}
[DEBUG] (s) patchDescription = {0} Patch {1}
[DEBUG] (s) patchMark = P
[DEBUG] (s) patchType = PATCH
[DEBUG] (s) project = MavenProject:
com.axway.$project:all-$project:3.6.1-SP6 @
D:\costin\ci\main\$projectcore-main\mnt-S43\$projectcore-S43\all-$project\pom.xml
[DEBUG] (s) servicePackDescription = {0} Service-Pack {1}
[DEBUG] (s) servicePackMark = SP
[DEBUG] (s) servicePackType = SP
[DEBUG] (f) updateTargetVersion = 0.0.0
[DEBUG] (s) usedInBranches = [servicepack]
[DEBUG] (s) usedInValidations = [patch]
[DEBUG] -- end configuration --
[INFO] [axway-version:xversion {execution: version}]
[INFO] Defining new property axway.version.major to 3.6.1
[INFO] Defining new property axway.version.patch to
[INFO] Defining new property axway.version.servicepack.name to SP6
[INFO] Defining new property axway.version.servicepack.number to 6
[INFO] No extensionpack found in project version format
[DEBUG] Skipping already defined property axway.version.patch
[INFO]
[jira] Commented: (WAGON-297) Wagon SCM does not automatically create missing directories during deployment
[ http://jira.codehaus.org/browse/WAGON-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=248620#action_248620 ] luke w patterson commented on WAGON-297: mvn-svn-wagon is the way to go: http://code.google.com/p/maven-svn-wagon/ Wagon SCM does not automatically create missing directories during deployment - Key: WAGON-297 URL: http://jira.codehaus.org/browse/WAGON-297 Project: Maven Wagon Issue Type: Bug Components: wagon-scm Affects Versions: 1.0-beta-6 Reporter: Maria Odea Ching Attachments: WAGON-297.patch, WAGON-297.patch -- 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: (MCHANGES-208) XmlPullParserException with changes.xml file
[
http://jira.codehaus.org/browse/MCHANGES-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MCHANGES-208:
-
Component/s: changes-report
Environment: Linux (Ubuntu) (was: Linux (Ubunutu))
XmlPullParserException with changes.xml file
Key: MCHANGES-208
URL: http://jira.codehaus.org/browse/MCHANGES-208
Project: Maven 2.x Changes Plugin
Issue Type: Bug
Components: changes-report
Affects Versions: 2.3
Environment: Linux (Ubuntu)
Reporter: Karl Heinz Marbaise
Attachments: problem-changes-file.diff
I have observed a strange behaviour in case of the following.
Given the following changes.xml file:
{code:xml}
document xmlns=http://maven.apache.org/changes/1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/changes/1.0.0
http://maven.apache.org/xsd/changes-1.0.0.xsd;
properties
titleChanges report Project/title
author email=zl...@toto.comMr Zloug/author
/properties
body
release version=1.0 date=2005-01-01 description=First release
action dev=me type=update issue=MCHANGES-47 due-to=others
due-to-email=oth...@users.com
fixes issue=MCHANGES-88/
fixes issue=JIRA-YYY/
dueto name=John Doe email=j...@doe.com/
dueto name=Jane Doe/
Uploaded documentation on how to use the plugin.
/action
/release
/body
/document
{code}
This will produce the following problem during site generation:
{code}
[ERROR] An error occured when parsing the changes.xml file:
org.codehaus.plexus.util.xml.pull.XmlPullParserException: expected START_TAG
or END_TAG not TEXT (position: TEXT seen ...\nUploaded documentation
on how to use the plugin.\n /... @35:9)
at
org.codehaus.plexus.util.xml.pull.MXParser.nextTag(MXParser.java:1083)
at
org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.parseAction(ChangesXpp3Reader.java:479)
at
org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.parseRelease(ChangesXpp3Reader.java:802)
at
org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.parseBody(ChangesXpp3Reader.java:587)
at
org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.parseChangesDocument(ChangesXpp3Reader.java:640)
at
org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.read(ChangesXpp3Reader.java:1104)
at
org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.read(ChangesXpp3Reader.java:1135)
at org.apache.maven.plugin.changes.ChangesXML.init(ChangesXML.java:65)
at
org.apache.maven.plugin.changes.ChangesReportGenerator.init(ChangesReportGenerator.java:75)
at
org.apache.maven.plugin.changes.ChangesMojo.executeReport(ChangesMojo.java:256)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:135)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:170)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:330)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:159)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:122)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
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:316)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
[jira] Commented: (DOXIA-365) reStructuredText (RST) support
[ http://jira.codehaus.org/browse/DOXIA-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=248622#action_248622 ] Pablo I. Lalloni commented on DOXIA-365: Project JRst has a doxia module available at http://maven-site.nuiton.org/jrst/doxia-module-jrst/index.html reStructuredText (RST) support -- Key: DOXIA-365 URL: http://jira.codehaus.org/browse/DOXIA-365 Project: Maven Doxia Issue Type: New Feature Components: Modules Environment: Any Reporter: Eric Chatellier Priority: Minor Features request to add reStructuredText (RST) support for doxia. Site: http://docutils.sourceforge.net/rst.html QuickStart format : http://docutils.sourceforge.net/docs/user/rst/quickstart.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] Updated: (MCHANGES-209) Checking the changes.xml file for release date and current version and fail if it is not
[ http://jira.codehaus.org/browse/MCHANGES-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MCHANGES-209: - Component/s: changes.xml Checking the changes.xml file for release date and current version and fail if it is not Key: MCHANGES-209 URL: http://jira.codehaus.org/browse/MCHANGES-209 Project: Maven 2.x Changes Plugin Issue Type: New Feature Components: changes.xml Environment: all Reporter: Karl Heinz Marbaise I would like to know if anybody has thought about the possibility to do some checks on the changes.xml file during a release process or before. My ideas are as follows: First check if a release entry does exist which contains a date of today (day of release) and a version which is relationship with the pom from where the changes-plugin is used. -- 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: (MCHANGES-207) Jira-Report: Allow specification of a version-prefix
[ http://jira.codehaus.org/browse/MCHANGES-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MCHANGES-207: - Component/s: jira Jira-Report: Allow specification of a version-prefix Key: MCHANGES-207 URL: http://jira.codehaus.org/browse/MCHANGES-207 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: jira Reporter: Michael Wenig Currently it is possible to auto-suggest the version in jira. Therefore the version of the pom is used with '-SNAPSHOT' stripped. If you have a product in jira with several components it is a often used pattern to prefix the version (e.g. component1-2.0, component2-1.0 etc.) Currently these versions are not auto-recognized. It would be better if it would be possible to optionally define a prefix (in this case 'component1-'). This would allow to use this feature also in prefixed-version-numbers -- 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: (MCHANGES-159) Publish the schema with the JAR file
[ http://jira.codehaus.org/browse/MCHANGES-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MCHANGES-159: - Component/s: changes.xml Publish the schema with the JAR file Key: MCHANGES-159 URL: http://jira.codehaus.org/browse/MCHANGES-159 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: changes.xml Reporter: Trygve Laugstol Use something like the build helper plugin to attach the generated .xsd to the build so that others can use the schema format. -- 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: (MCHANGES-160) Support creating a plain text version of the report
[ http://jira.codehaus.org/browse/MCHANGES-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MCHANGES-160: - Component/s: announcement Support creating a plain text version of the report --- Key: MCHANGES-160 URL: http://jira.codehaus.org/browse/MCHANGES-160 Project: Maven 2.x Changes Plugin Issue Type: New Feature Components: announcement Reporter: Trygve Laugstol Useful when the change log is to be included in a native package or in a WAR as documentation. -- 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: (MCHANGES-165) Using type=update but the result says Fixes [bug...]
[ http://jira.codehaus.org/browse/MCHANGES-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-165. Resolution: Won't Fix Assignee: (was: Olivier Lamy) Se my previous comment for the reason to close this as won't fix. Using type=update but the result says Fixes [bug...] Key: MCHANGES-165 URL: http://jira.codehaus.org/browse/MCHANGES-165 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: changes.xml Affects Versions: 2.1 Environment: All Reporter: Karl Heinz Marbaise Priority: Minor If i use the type=updated in an entry of the changes.xml file the result site will show the word Fixes . IMHO it should be Refs or something different than Fixes cause that issue is not fixed yet it is updated instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-665) Output to file stops after a while
[
http://jira.codehaus.org/browse/SUREFIRE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-665.
---
Resolution: Fixed
Fix Version/s: 2.7.1
Assignee: Kristian Rosenvold
Fixed in r1049669. It's the redirectOutputToFile that is buggy and can have
race conditions.
Output to file stops after a while
--
Key: SUREFIRE-665
URL: http://jira.codehaus.org/browse/SUREFIRE-665
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.6
Reporter: Tom Baeyens
Assignee: Kristian Rosenvold
Fix For: 2.7.1
After some tests of proper behavior, surefire stops logging the console
output (stderr stdout) to the files. For the first tests that are
executed, the X-output.txt files contain the correct console output. But
from some test in the test suite, all those files are blank.
My environment: Mac with
Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200)
Java version: 1.6.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: mac os x version: 10.6.4 arch: x86_64 Family: mac
Using Surefire 2.6
I've done following observations:
* The exact test where the console capturing stops can vary a couple of
tests, but it always happens. Could it be related to memory? Increasing
from MAVEN_OPTS=-Xmx1024m -Xms512m to MAVEN_OPTS=-Xmx2048m -Xms512m
didn't have an effect
* When debugging, as long as the output is ok, System.err.checkError()
returns false. Once the output files get blank, System.err.checkError()
returns true.
* The problem doesn't occur when running the same test suite in eclipse.
* When I didn't specify surefire version, I got 2.4.something. When I
explicitely set the version to 2.6, then the test suite started failing half
way with out of memory exceptions.
* Then I configured forkModealways/forkMode. That made the whole test
suite run fine (no memory exceptions and all log files being produced) but
then it takes a very long time.
* I traced closing of the system err stream until SystemStreamCapturer
76 public void restoreStreams()
77 {
78 // Note that the fields can be null if the test hasn't even
started yet (an early error)
79 if ( oldOut != null )
80 {
81 System.setOut( oldOut );
82 }
83 if ( oldErr != null )
84 {
85 System.setErr( oldErr );
86 }
87
88 IOUtil.close( newOut );
89 IOUtil.close( newErr );
90 }
But there I couldn't find how to trace it further and gave up.
To reproduce: (only tested on mac)
check out https://svn.codehaus.org/activiti/activiti/trunk and then on the
root do
mvn clean install
only the first executed tests will contain properly captured output in
modules/activiti-engine/target/surefire-reports/*-output.txt
--
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-543) Expose the name of test suite class used as a sure-fire plugin property so that in can be specified in the project XML
[
http://jira.codehaus.org/browse/SUREFIRE-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-543.
---
Resolution: Won't Fix
Assignee: Kristian Rosenvold
Given that SUREFIRE-141 is fixed, this issue can now be achieved in a number of
ways. Watch SUREFIRE-141 for details and the 2.7 website.
Expose the name of test suite class used as a sure-fire plugin property so
that in can be specified in the project XML
--
Key: SUREFIRE-543
URL: http://jira.codehaus.org/browse/SUREFIRE-543
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Surefire Plugin
Affects Versions: 2.4.3
Environment: Does not matter.
Reporter: anshul
Assignee: Kristian Rosenvold
The SurefirePlugin currently hardcodes the name of the test suite class used
for figuring out the list of tests within
SurefirePlugin.constructSurefireBooter(). It will be very useful if the
plugin exposes the name of these test suites as plugin properties, so that
custom ones can be supplied in the XML.
The default value for these properties can be set to the current hardcoded
values.
{{org.apache.maven.surefire.testng.TestNGDirectoryTestSuite,
org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite,
org.apache.maven.surefire.junit.JUnitDirectoryTestSuite}}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2315) Add option to exclude all transitive dependencies for a particular one
[ http://jira.codehaus.org/browse/MNG-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=248632#action_248632 ] Blaine Simpson commented on MNG-2315: - Always years behind Ivy for anything to do with dependency specifications. Add option to exclude all transitive dependencies for a particular one -- Key: MNG-2315 URL: http://jira.codehaus.org/browse/MNG-2315 Project: Maven 2 3 Issue Type: New Feature Components: Dependencies Affects Versions: 2.0.4 Reporter: Carlos Sanchez Priority: Critical Fix For: 3.1 Something like dependency ... excludeTransitivetrue/excludeTransitive /dependency -- 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: (MCHANGES-206) announcement-generate doesn't use configuration of webUser, webPassword and filter for downloading the jira-issues
[ http://jira.codehaus.org/browse/MCHANGES-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MCHANGES-206: - Component/s: jira Affects Version/s: (was: 2.4) 2.3 announcement-generate doesn't use configuration of webUser, webPassword and filter for downloading the jira-issues -- Key: MCHANGES-206 URL: http://jira.codehaus.org/browse/MCHANGES-206 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: announcement, jira Affects Versions: 2.3 Environment: Maven 2.2.1, Windows XP, SpringSource Tool Suite Reporter: Manuel Doninger Priority: Critical Attachments: patch_jira_announcement.txt When creating a jira-announcement, the announcement-mojo doesn't use the configurations for webUser, webPassword and filter to download the jira-issues. Thus the generation of a mail with announcement-mail also fails. I created a patch for the class AnnouncementMojo to include those configurations. -- 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: (MCHANGES-206) announcement-generate doesn't use configuration of webUser, webPassword and filter for downloading the jira-issues
[ http://jira.codehaus.org/browse/MCHANGES-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-206. Resolution: Fixed Fix Version/s: 2.4 Assignee: Dennis Lundberg Patch applied in [r1049713|http://svn.apache.org/viewvc?view=revisionrevision=1049713] with modifications. 2.4-SNAPSHOT deployed. Thanks! announcement-generate doesn't use configuration of webUser, webPassword and filter for downloading the jira-issues -- Key: MCHANGES-206 URL: http://jira.codehaus.org/browse/MCHANGES-206 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: announcement, jira Affects Versions: 2.3 Environment: Maven 2.2.1, Windows XP, SpringSource Tool Suite Reporter: Manuel Doninger Assignee: Dennis Lundberg Priority: Critical Fix For: 2.4 Attachments: patch_jira_announcement.txt When creating a jira-announcement, the announcement-mojo doesn't use the configurations for webUser, webPassword and filter to download the jira-issues. Thus the generation of a mail with announcement-mail also fails. I created a patch for the class AnnouncementMojo to include those configurations. -- 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: (MCHANGES-154) Using an URL for the email template instead of the proiect local file
[
http://jira.codehaus.org/browse/MCHANGES-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=248639#action_248639
]
Dennis Lundberg commented on MCHANGES-154:
--
You can do this today using the standard Maven way of sharing resources.
First create a separate Maven project called maven-build-tools to house your
shared reqources. It can consist of only 2 files: a pom.xml and the template
itself at /src/main/resources/your/org/plugins/announcement/announcement.vm
Put this in your project's POM:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version2.3/version
configuration
...
templateDirectoryyour/org/plugins/announcement/templateDirectory
/configuration
dependencies
dependency
groupIdyour.org/groupId
artifactIdmaven-build-tools/artifactId
version1.0-SNAPSHOT/version
/dependency
/dependencies
/plugin
{code}
Using an URL for the email template instead of the proiect local file
-
Key: MCHANGES-154
URL: http://jira.codehaus.org/browse/MCHANGES-154
Project: Maven 2.x Changes Plugin
Issue Type: New Feature
Components: announcement
Affects Versions: 2.1
Environment: Maven 2.0.9
Java 6
WinXP
Reporter: Jean-Paul GUIGUI
Today the plugin needs a local templateOutputDirectoy which is under the
basedir of the project.
Actually, I'd like to share the same template for all my projects.
The template should be an URL so it will be possible to share 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] Closed: (MCHANGES-209) Checking the changes.xml file for release date and current version and fail if it is not
[ http://jira.codehaus.org/browse/MCHANGES-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-209. Resolution: Duplicate Checking the changes.xml file for release date and current version and fail if it is not Key: MCHANGES-209 URL: http://jira.codehaus.org/browse/MCHANGES-209 Project: Maven 2.x Changes Plugin Issue Type: New Feature Components: changes.xml Environment: all Reporter: Karl Heinz Marbaise I would like to know if anybody has thought about the possibility to do some checks on the changes.xml file during a release process or before. My ideas are as follows: First check if a release entry does exist which contains a date of today (day of release) and a version which is relationship with the pom from where the changes-plugin is used. -- 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: (MRESOURCES-104) while filtering resources the token replacement stops at the character @
[
http://jira.codehaus.org/browse/MRESOURCES-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Dunsmore updated MRESOURCES-104:
--
Attachment: m3-resource-filtering.zip
Agree with Daniel. Stumbled upon this myself, has taken two hours to get here.
Attached is another repro case, showing what works with the default
configuration and what does not.
while filtering resources the token replacement stops at the character @
-
Key: MRESOURCES-104
URL: http://jira.codehaus.org/browse/MRESOURCES-104
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows XP, Java 1.6.0_16
Reporter: Thomas Fahrmeyer
Assignee: Arnaud Heritier
Priority: Critical
Fix For: 2.5
Attachments: m3-resource-filtering.zip, MRESOURCES-104.zip
Create a simple file hello.txt under src/main/resources with following
content:
This property ${testProperty} was replaced
but the one behind a @ will not be processed, as you
see: ${testProperty}. You shouldn't see a property reference.
define a build section in your pom.xml like this
build
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
includes
include**/*.txt/include
/includes
/resource
resource
directorysrc/main/resources/directory
filteringfalse/filtering
excludes
exclude**/*.txt/exclude
/excludes
/resource
/resources
Run the command:
mvn process-resources -DtestProperty=IwasReplaced
this produces the output
This property IwasReplaced was replaced
but the one behind a @ will not be processed, as you
see: ${testProperty}. You shouldn't see a property reference.
As you see, the second property reference was not resolved. The replacement
just stops after the @ character.
--
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
