[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
>
>
>
> src/main/resources
> true
>
> **/*.txt
>
>
>
> src/main/resources
> false
>
> **/*.txt
>
>
>
> 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
[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] 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-tabpanel&focusedCommentId=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}
org.apache.maven.plugins
maven-changes-plugin
2.3
...
your/org/plugins/announcement
your.org
maven-build-tools
1.0-SNAPSHOT
{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-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=revision&revision=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] 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] 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-tabpanel&focusedCommentId=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 > > ... > true > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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] 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 always. 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: (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] 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] 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] Commented: (DOXIA-365) reStructuredText (RST) support
[ http://jira.codehaus.org/browse/DOXIA-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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}
> 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";>
>
> Changes report Project
> Mr Zloug
>
>
>
>due-to-email="oth...@users.com">
>
>
>
>
> Uploaded documentation on how to use the plugin.
>
>
>
>
> {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 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.(ChangesXML.java:65)
> at
> org.apache.maven.plugin.changes.ChangesReportGenerator.(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
> 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.launch
[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-tabpanel&focusedCommentId=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] 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 pro
[jira] Issue Comment Edited: (MDEP-257) seems to have no effect
[
http://jira.codehaus.org/browse/MDEP-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
> 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}
>
> maven-dependency-plugin
> 2.1
>
>
> izpack
> generate-resources
>
> unpack-dependencies
>
>
> ${project.build.directory}/staging
> izpack
>
>
>
>
> {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-tabpanel&focusedCommentId=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.HashMap) {}
> 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] Commented: (MDEP-257) seems to have no effect
[
http://jira.codehaus.org/browse/MDEP-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
> 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}
>
> maven-dependency-plugin
> 2.1
>
>
> izpack
> generate-resources
>
> unpack-dependencies
>
>
> ${project.build.directory}/staging
> izpack
>
>
>
>
> {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: (MNG-2570) Maven needs to support multiple logging levels
[ http://jira.codehaus.org/browse/MNG-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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] 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] 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=revision&revision=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] 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 upgra
[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. > > > > dist > deps > pom > 4.0.4-SNAPSHOT > import > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-tabpanel&focusedCommentId=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] Commented: (MWAR-245) overlay feature rejects .tar.gz
[ http://jira.codehaus.org/browse/MWAR-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 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] 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] 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] 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-tabpanel&focusedCommentId=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.ReportDocumentRender
[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-tabpanel&focusedCommentId=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(Repo
[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-tabpanel&focusedCommentId=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 org.codehaus.plexus.util.cli.StreamPumper.consum
[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-tabpanel&focusedCommentId=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:
[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] 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] 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 > > maven-surefire-plugin > 2.4.2 > > true > always > > > 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
