[jira] Commented: (MRESOURCES-61) PluginDescriptor not found
[ http://jira.codehaus.org/browse/MRESOURCES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128645#action_128645 ] Benjamin Bentmann commented on MRESOURCES-61: - bq. The point of not locking it is that you get updates If you ever cared about reproducible builds, then I can only emphasize to follow Oliver's suggestion and lock plugin versions. While auto-update originally seemed like a convenient feature, it makes your build dependent on current time and machine/developer. The key point to keep in mind is that a new plugin version simply might not be backwards compatible, may it for a new bug or some refactoring to better support new/other use cases. Last but not least, be warned that Maven 2.0.9 will lock down core plugins in its super POM, see MNG-3395. > PluginDescriptor not found > -- > > Key: MRESOURCES-61 > URL: http://jira.codehaus.org/browse/MRESOURCES-61 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Reporter: Brill Pappin > Attachments: maven-eclipse-integration-plugin.txt > > > The following error, every time I run a build has been ongoing for quite some > time now. > 3/21/08 3:34:06 PM EDT: Build error for /aleixo-console/pom.xml; > java.lang.IllegalStateException: The PluginDescriptor for the plugin > org.apache.maven.plugins:maven-resources-plugin was not found > It seems to go away if I run with a -U to update the plugins but comes back > regularly. > Can somebody please fix whatever issue is causing this to occur? -- 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: (MAVENUPLOAD-1971) Please sync com.capgemini.platina groupId with central
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128653#action_128653 ] nicolas de loof commented on MAVENUPLOAD-1971: -- According to http://svn.apache.org/repos/asf/maven/archiva/tools/trunk/maven-meeper/src/bin/synchronize/m2-sync/sync.csv my sync script has a %!$#!! windows-style EOL for the repository folder name, that breaks the configuration > Please sync com.capgemini.platina groupId with central > -- > > Key: MAVENUPLOAD-1971 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1971 > Project: maven-upload-requests > Issue Type: Wish >Reporter: nicolas de loof >Assignee: Carlos Sanchez > Attachments: platina.sh > > > I've created for my company (capgemini) some maven components and corporate > POM. > They're distributed under apache license, so I'd like them to get deployed on > central. -- 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: (MECLIPSE-409) Build path omits generated test resources
[ http://jira.codehaus.org/browse/MECLIPSE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson closed MECLIPSE-409. Resolution: Duplicate Thought this issue sounded familiar.. > Build path omits generated test resources > - > > Key: MECLIPSE-409 > URL: http://jira.codehaus.org/browse/MECLIPSE-409 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path >Affects Versions: 2.5 >Reporter: Mark Hobson > Attachments: MECLIPSE-409.patch > > > eclipse:eclipse only executes up to the generate-resources phase, hence any > generated test resources are not included in the build path. This means that > tests that rely on these generated test resources will fail in the IDE. -- 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: (MECLIPSE-411) maifest property usage is only for ogsi maifests
maifest property usage is only for ogsi maifests Key: MECLIPSE-411 URL: http://jira.codehaus.org/browse/MECLIPSE-411 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: OSGi, Manifest, WTP support Affects Versions: 2.5 Environment: any Reporter: Richard van Nieuwenhoven Attachments: manifest.patch the manifest property of the eclipse plugin is only for the osgi writer and not for the wtp manifest, because the wtp manifest is a special case that will not be included in the maven build just in the eclipse classpath. The problem is that the property has a default value and by that deacivates the WTP classpath! included a patch for the 2.5 release, including some renaming so it won't happen again. please release a 2.5.1 version with this 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] Commented: (MCOMPILER-68) Command line is too long, java.IO.Exception
[ http://jira.codehaus.org/browse/MCOMPILER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128659#action_128659 ] geoff simpson commented on MCOMPILER-68: I've got a similar issue but the error returned is different, but mine is caused by the classpath being too long. I guess the compiler should be using the java API to access the compiler options via tools.jar rather than using the command line. > Command line is too long, java.IO.Exception > > > Key: MCOMPILER-68 > URL: http://jira.codehaus.org/browse/MCOMPILER-68 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Win XP SP2 >Reporter: David Heimann > > Hi there, > i have the same problem again, like in ticket MCOMPILER-22. I am using maven > in version 2.0.8. > [java] Caused by: java.io.IOException: CreateProcess: > C:\Programme\Java\jdk > 1.5.0_09\jre\bin\java.exe -Djava.awt.headless=true -classpath "C:\Dokumente > und > Einstellungen\david.heimann\.m2\repository\ant\ant-launcher\1.6.5\ant-launcher-1 > .6.5.jar;C:\Dokumente und > Einstellungen\david.heimann\.m2\repository\ant\ant\1.6 > .5\ant-1.6.5.jar;C:\Dokumente und > Einstellungen\david.heimann\.m2\repository\ant > lr\antlr\2.7.6\antlr-2.7.6-sources.jar;C:\Dokumente und > Einstellungen\david.heim > ann\.m2\repository\antlr\antlr\2.7.6\antlr-2.7.6.jar;C:\Dokumente und > Einstellun > gen\david.heimann\.m2\repository\asm\asm-attrs\1.5.3\asm-attrs-1.5.3.jar;C:\Doku > mente und > Einstellungen\david.heimann\.m2\repository\asm\asm-commons\2.2.1\asm-c > ommons-2.2.1.jar;C:\Dokumente und > Einstellungen\david.heimann\.m2\repository\asm > \asm\1.5.3\asm-1.5.3.jar;C:\Dokumente und > Einstellungen\david.heimann\.m2\reposi > tory\asm\asm\2.2.1\asm-2.2.1.jar;C:\Dokumente und > Einstellungen\david.heimann\.m > 2\repository\asm\asm\3.0\asm-3.0.jar;C:\Dokumente und > Einstellungen\david.heiman > n\.m2\repository\aspectj\aspö > [java] at java.lang.ProcessImpl.create(Native Method) > [java] at java.lang.ProcessImpl.(ProcessImpl.java:81) > [java] at java.lang.ProcessImpl.start(ProcessImpl.java:30) > [java] at java.lang.ProcessBuilder.start(ProcessBuilder.java:451) > [java] at java.lang.Runtime.exec(Runtime.java:591) > [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [java] at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces > sorImpl.java:39) > [java] at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet > hodAccessorImpl.java:25) > [java] at java.lang.reflect.Method.invoke(Method.java:585) > [java] at > org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.e > xec(Execute.java:834) > [java] at > org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:435 > ) > [java] at > org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:44 > 9) > [java] at org.apache.tools.ant.taskdefs.Java.fork(Java.java:751) > [java] ... 25 more > > I have a ant-task in the pom.xml creating that long command. For a solution > for this i would be very thankful. Sorry for my bad english... -- 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: (MCHANGELOG-83) avoid a build fail when there are specific characters in a filename
avoid a build fail when there are specific characters in a filename
---
Key: MCHANGELOG-83
URL: http://jira.codehaus.org/browse/MCHANGELOG-83
Project: Maven 2.x Changelog Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: Windows/Linux , maven 2.0.8
Reporter: Guimiot Isabelle
Priority: Minor
When I commit a file from a windows platform on CVS, with a name containing
specific characters (for example : "schéma.xml", containing character "é"),
the "cvs log" command is ok on windows (iso-8859-1) and it contains just some
"warning line" on linux (utf-8) which says "cvs server: nothing known about
sch?ma.xml". This warning line doesn't make the cvs log command fail, I have
all the information I need about every file that changed during the last
month...
When I run the changelog:changelog goal, if I run maven with
"MAVEN_OPTS=-Dfile.encoding=ISO-8859-1" (JVM option), everything's ok, but if I
run the same goal with "MAVEN_OPTS=-Dfile.encoding=UTF-8", the warning line
that I could read on linux ("nothing known about...") makes my whole build fail
!
[ERROR] Provider message:
[ERROR] The cvs command failed.
[ERROR] Command output:
[ERROR] cvs server: nothing known about sch�ma.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An error has occurred in Change Log report generation.
Embedded error: An error has occurred during changelog command :
Command failed.
Could you resolve this problem with some cvs error parsing that could detect
what king of error is serious, and what kind of error is just a small warning ?
many thanks !
--
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: (MCOMPILER-68) Command line is too long, java.IO.Exception
[
http://jira.codehaus.org/browse/MCOMPILER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128661#action_128661
]
Benjamin Bentmann commented on MCOMPILER-68:
bq. I have a ant-task in the pom.xml creating that long command.
Why Ant, what is your special use case to not use the Maven Compiler Plugin?
Could you please attach your {{pom.xml}}. Also, please don't post long log
output into your description, it's hardly readable, especially with the
artificial line breaks. On Windows, simply run
{noformat}
mvn compile -X > build.log
{noformat}
and attach the resulting log file to the issue.
> Command line is too long, java.IO.Exception
>
>
> Key: MCOMPILER-68
> URL: http://jira.codehaus.org/browse/MCOMPILER-68
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
> Environment: Win XP SP2
>Reporter: David Heimann
>
> Hi there,
> i have the same problem again, like in ticket MCOMPILER-22. I am using maven
> in version 2.0.8.
> [java] Caused by: java.io.IOException: CreateProcess:
> C:\Programme\Java\jdk
> 1.5.0_09\jre\bin\java.exe -Djava.awt.headless=true -classpath "C:\Dokumente
> und
> Einstellungen\david.heimann\.m2\repository\ant\ant-launcher\1.6.5\ant-launcher-1
> .6.5.jar;C:\Dokumente und
> Einstellungen\david.heimann\.m2\repository\ant\ant\1.6
> .5\ant-1.6.5.jar;C:\Dokumente und
> Einstellungen\david.heimann\.m2\repository\ant
> lr\antlr\2.7.6\antlr-2.7.6-sources.jar;C:\Dokumente und
> Einstellungen\david.heim
> ann\.m2\repository\antlr\antlr\2.7.6\antlr-2.7.6.jar;C:\Dokumente und
> Einstellun
> gen\david.heimann\.m2\repository\asm\asm-attrs\1.5.3\asm-attrs-1.5.3.jar;C:\Doku
> mente und
> Einstellungen\david.heimann\.m2\repository\asm\asm-commons\2.2.1\asm-c
> ommons-2.2.1.jar;C:\Dokumente und
> Einstellungen\david.heimann\.m2\repository\asm
> \asm\1.5.3\asm-1.5.3.jar;C:\Dokumente und
> Einstellungen\david.heimann\.m2\reposi
> tory\asm\asm\2.2.1\asm-2.2.1.jar;C:\Dokumente und
> Einstellungen\david.heimann\.m
> 2\repository\asm\asm\3.0\asm-3.0.jar;C:\Dokumente und
> Einstellungen\david.heiman
> n\.m2\repository\aspectj\aspö
> [java] at java.lang.ProcessImpl.create(Native Method)
> [java] at java.lang.ProcessImpl.(ProcessImpl.java:81)
> [java] at java.lang.ProcessImpl.start(ProcessImpl.java:30)
> [java] at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
> [java] at java.lang.Runtime.exec(Runtime.java:591)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
> sorImpl.java:39)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
> hodAccessorImpl.java:25)
> [java] at java.lang.reflect.Method.invoke(Method.java:585)
> [java] at
> org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.e
> xec(Execute.java:834)
> [java] at
> org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:435
> )
> [java] at
> org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:44
> 9)
> [java] at org.apache.tools.ant.taskdefs.Java.fork(Java.java:751)
> [java] ... 25 more
>
> I have a ant-task in the pom.xml creating that long command. For a solution
> for this i would be very thankful. Sorry for my bad english...
--
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: (MCOMPILER-68) Command line is too long, java.IO.Exception
[
http://jira.codehaus.org/browse/MCOMPILER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128662#action_128662
]
Benjamin Bentmann commented on MCOMPILER-68:
bq. I guess the compiler should be using the java API to access the compiler
options via tools.jar rather than using the command line.
Both the Maven Compiler Plugin and the Ant task have an option named
{{[fork|http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#fork]}}
exactly for this purpose.
> Command line is too long, java.IO.Exception
>
>
> Key: MCOMPILER-68
> URL: http://jira.codehaus.org/browse/MCOMPILER-68
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
> Environment: Win XP SP2
>Reporter: David Heimann
>
> Hi there,
> i have the same problem again, like in ticket MCOMPILER-22. I am using maven
> in version 2.0.8.
> [java] Caused by: java.io.IOException: CreateProcess:
> C:\Programme\Java\jdk
> 1.5.0_09\jre\bin\java.exe -Djava.awt.headless=true -classpath "C:\Dokumente
> und
> Einstellungen\david.heimann\.m2\repository\ant\ant-launcher\1.6.5\ant-launcher-1
> .6.5.jar;C:\Dokumente und
> Einstellungen\david.heimann\.m2\repository\ant\ant\1.6
> .5\ant-1.6.5.jar;C:\Dokumente und
> Einstellungen\david.heimann\.m2\repository\ant
> lr\antlr\2.7.6\antlr-2.7.6-sources.jar;C:\Dokumente und
> Einstellungen\david.heim
> ann\.m2\repository\antlr\antlr\2.7.6\antlr-2.7.6.jar;C:\Dokumente und
> Einstellun
> gen\david.heimann\.m2\repository\asm\asm-attrs\1.5.3\asm-attrs-1.5.3.jar;C:\Doku
> mente und
> Einstellungen\david.heimann\.m2\repository\asm\asm-commons\2.2.1\asm-c
> ommons-2.2.1.jar;C:\Dokumente und
> Einstellungen\david.heimann\.m2\repository\asm
> \asm\1.5.3\asm-1.5.3.jar;C:\Dokumente und
> Einstellungen\david.heimann\.m2\reposi
> tory\asm\asm\2.2.1\asm-2.2.1.jar;C:\Dokumente und
> Einstellungen\david.heimann\.m
> 2\repository\asm\asm\3.0\asm-3.0.jar;C:\Dokumente und
> Einstellungen\david.heiman
> n\.m2\repository\aspectj\aspö
> [java] at java.lang.ProcessImpl.create(Native Method)
> [java] at java.lang.ProcessImpl.(ProcessImpl.java:81)
> [java] at java.lang.ProcessImpl.start(ProcessImpl.java:30)
> [java] at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
> [java] at java.lang.Runtime.exec(Runtime.java:591)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
> sorImpl.java:39)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
> hodAccessorImpl.java:25)
> [java] at java.lang.reflect.Method.invoke(Method.java:585)
> [java] at
> org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.e
> xec(Execute.java:834)
> [java] at
> org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:435
> )
> [java] at
> org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:44
> 9)
> [java] at org.apache.tools.ant.taskdefs.Java.fork(Java.java:751)
> [java] ... 25 more
>
> I have a ant-task in the pom.xml creating that long command. For a solution
> for this i would be very thankful. Sorry for my bad english...
--
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: (MPIR-88) Wrong homepage link in project-summary.html when processing staging
Wrong homepage link in project-summary.html when processing staging --- Key: MPIR-88 URL: http://jira.codehaus.org/browse/MPIR-88 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Vincent Siveton Attachments: maven-plugin-plugin-2.4.PNG See the screenshot http://maven.apache.org/plugin-tools/maven-plugin-tools-api/project-summary.html http://maven.apache.org/plugin-tools/maven-plugin-tools-api-2.4/project-summary.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPIR-89) Bad spelling in Project Information => Overview => Dependencies
Bad spelling in Project Information => Overview => Dependencies --- Key: MPIR-89 URL: http://jira.codehaus.org/browse/MPIR-89 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Michael Osipov Priority: Minor The text says: "This document lists the projects dependencies and provides information on each dependency." It has to be actually: "This document lists the project dependencies and provides information on each dependency." (project in singular) The dependencies report says: "The following is a list of compile dependencies for this project. These dependencies are required to compile and run the application:" (singular too which is correct) -- 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: (MPIR-90) Bad style in text "Access from behind a firewall"
Bad style in text "Access from behind a firewall" - Key: MPIR-90 URL: http://jira.codehaus.org/browse/MPIR-90 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Michael Osipov Priority: Minor The text says "Refer to the documentation of the SCM used for more information about an access behind a firewall." which is stylistically bad. A better text would be either "Refer to the documentation of the SCM used for more information on access behind a firewall." or "Refer to the documentation of the SCM used for more information on accessibility behind a firewall." -- 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: (MPIR-91) Bad spelling in text "Access through a proxy"
Bad spelling in text "Access through a proxy" - Key: MPIR-91 URL: http://jira.codehaus.org/browse/MPIR-91 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Michael Osipov Priority: Minor The text says "[...]First, edit your "servers" configuration file to indicate which proxy to use. The files location depends on your operating system.[...]" An apostrophe is actually missing. The correct text would be "First, edit your "servers" configuration file to indicate which proxy to use. The file's location depends on your operating system." -- 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: (ARCHETYPE-152) sources in archetype.xml will not work outside of src/main/java dir.
[ http://jira.codehaus.org/browse/ARCHETYPE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128672#action_128672 ] thomas bruyelle commented on ARCHETYPE-152: --- archetype.xml is obsolete in version 2.0 isn't it ? Now plugin use archetype-metadata.xml in the same directory > sources in archetype.xml will not work outside of src/main/java dir. > > > Key: ARCHETYPE-152 > URL: http://jira.codehaus.org/browse/ARCHETYPE-152 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 2.0-alpha-2 > Environment: MacOSX and WindowsXP >Reporter: Zemian Deng > > If source is not in src/main/java with ".java" files, the or > elements in META-INF/archetype.xml will cause errors of "files > not found" when run. This used to work on 1.0-alpha-7. > Example of failed Testcase in the META-INF/archetype.xml file: > > src/main/scala/App.scala > > > src/test/scala/AppTest.scala > -- 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: (MECLIPSE-412) Generation of jst.java Facet for EAR packaging kills my RAD workspace
Generation of jst.java Facet for EAR packaging kills my RAD workspace - Key: MECLIPSE-412 URL: http://jira.codehaus.org/browse/MECLIPSE-412 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: RAD support, WTP support Affects Versions: 2.5 Environment: Windows, RAD 7.0.0.5 Reporter: Kuno Baeriswyl Attachments: EclipseWtpFacetsWriter-RAD-patch.txt The eclipse:eclipse or eclipse:rad goals generate jst.java Facets like : This facets aren't necessary for EAR artifacts in RAD, brings it in a strange state and kills my workspace. The side effects are particularly annoying in the debug mode, where on every step an error message pop-ups. The maven-eclipse-plugin must avoid this facets and generate them like following: I think you have done a great work with the recent 2.5 release. Just need to have fixed this. Thanks for everything. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-36) resource copy to target/classes: empty directories are ignored
[ http://jira.codehaus.org/browse/MRESOURCES-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128679#action_128679 ] Jonathan Ramsey commented on MRESOURCES-36: --- Until this issue is fixed, here is a workaround I've been using successfully. Add this plugin element into project/build/plugins in your pom.xml, and change the dir in the mkdir task. You can have multiple elements for multiple directories. The mkdir task does nothing if the directory has already been copied by the resources plugin. org.apache.maven.plugins maven-antrun-plugin create-empty-directory process-classes run This originally came from the openejb-standalone pom.xml in the openejb project. http://svn.apache.org/repos/asf/openejb/trunk/openejb3/assembly/openejb-standalone/pom.xml > resource copy to target/classes: empty directories are ignored > -- > > Key: MRESOURCES-36 > URL: http://jira.codehaus.org/browse/MRESOURCES-36 > Project: Maven 2.x Resources Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Martin Vysny > Fix For: 2.3 > > Attachments: patchfile > > > Hi, > I have several directories located in the src/test/resources and I > need them to be copied to target/test-classes. This is of course handled > by maven-resources-plugin, however it does not copy empty directories. I > know it sounds insane to access empty dirs using classloader but I have > my reasons ;) -- 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: (ARCHETYPE-150) New maven-archetype-plugin ignores the remoteRepositories system property
[ http://jira.codehaus.org/browse/ARCHETYPE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated ARCHETYPE-150: Assignee: Raphaël Piéroni (was: Jason van Zyl) Affects Version/s: (was: 2.0-alpha-2) 2.0-alpha-3 > New maven-archetype-plugin ignores the remoteRepositories system property > -- > > Key: ARCHETYPE-150 > URL: http://jira.codehaus.org/browse/ARCHETYPE-150 > Project: Maven Archetype > Issue Type: Bug >Affects Versions: 2.0-alpha-3 >Reporter: Bruce Snyder >Assignee: Raphaël Piéroni > > When executing the latest maven-archetype-plugin using the archetype:create > goal with the -DremoteRepositories system property, the remoteRepositories > property is ignored. See an example of this below with full debug output: > $ mvn -X archetype:create -DarchetypeGroupId=org.apache.servicemix.tooling > -DarchetypeArtifactId=servicemix-service-unit -DarchetypeVersion=3.3.0.7-fuse > -DgroupId=com.mycompany -DartifactId=my-su > -DremoteRepositories=http://repo.open.iona.com/maven2/ > + Error stacktraces are turned on. > Maven version: 2.0.8 > Java version: 1.5.0_13 > OS name: "mac os x" version: "10.4.11" arch: "i386" Family: "unix" > [DEBUG] Building Maven user-level plugin registry from: > '/Users/bsnyder/.m2/plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > '/Users/bsnyder/apache-maven-2.0.8/conf/plugin-registry.xml' > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'archetype'. > [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins > [DEBUG] Loading plugin prefixes from group: org.codehaus.mojo > [DEBUG] maven-archetype-plugin: resolved to version 2.0-alpha-2 from > repository central > [DEBUG] Retrieving parent-POM: > org.apache.maven.archetype:maven-archetype::2.0-alpha-2 for project: > org.apache.maven.plugins:maven-archetype-plugin:maven-plugin:null from the > repository. > [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for project: > org.apache.maven.archetype:maven-archetype:pom:2.0-alpha-2 from the > repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.maven:maven-parent:pom:7 from the repository. > [DEBUG] Adding managed dependencies for > org.apache.maven.plugins:maven-archetype-plugin > [DEBUG] junit:junit:jar:3.8.1:test > [DEBUG] commons-io:commons-io:jar:1.3.1 > [DEBUG] commons-collections:commons-collections:jar:3.2 > [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-6:test > [DEBUG] org.apache.maven:maven-model:jar:2.0.8 > [DEBUG] dom4j:dom4j:jar:1.6.1 > [DEBUG] org.codehaus.plexus:plexus-velocity:jar:1.1.3 > [DEBUG] > org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1 > [DEBUG] org.apache.maven:maven-project:jar:2.0.8 > [DEBUG] org.apache.maven:maven-core:jar:2.0.8 > [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.8 > [DEBUG] jdom:jdom:jar:1.0 > [DEBUG] org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-5 > [DEBUG] > org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0-beta-1:test > [DEBUG] velocity:velocity:jar:1.4 > [DEBUG] net.sourceforge.jchardet:jchardet:jar:1.0 > [DEBUG] org.apache.maven.archetype:archetype-common:jar:2.0-alpha-2 > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.4.6 > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [archetype:create] (aggregator-style) > [INFO] > > [DEBUG] > org.apache.maven.plugins:maven-archetype-plugin:maven-plugin:2.0-alpha-2:runtime > (selected for runtime) > [DEBUG] Adding managed dependencies for unknown:archetype-common > [DEBUG] junit:junit:jar:3.8.1:test > [DEBUG] commons-io:commons-io:jar:1.3.1 > [DEBUG] commons-collections:commons-collections:jar:3.2 > [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-6:test > [DEBUG] org.apache.maven:maven-model:jar:2.0.8 > [DEBUG] dom4j:dom4j:jar:1.6.1 > [DEBUG] org.codehaus.plexus:plexus-velocity:jar:1.1.3 > [DEBUG] > org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1 > [DEBUG] org.apache.maven:maven-project:jar:2.0.8 > [DEBUG] org.apache.maven:maven-core:jar:2.0.8 > [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.8 > [DEBUG] jdom:jdom:jar:1.0 > [DEBUG] org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-5 > [DEBUG] net.sourceforge.jchardet:jchardet:jar:1.0 > [DEBUG] velocity:velocity:jar:1.4 > [DEBUG] > org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0-beta-1:test > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.4.6 > [DEBUG] org.apache.maven.arch
[jira] Commented: (MASSEMBLY-302) Maven assembly plugin should use plexus-archiver version
[ http://jira.codehaus.org/browse/MASSEMBLY-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128683#action_128683 ] John Casey commented on MASSEMBLY-302: -- Might as well; I'd hate to break the tradition of having the assembly plugin require a new release of plexus-archiver, after all. :-) > Maven assembly plugin should use plexus-archiver version > - > > Key: MASSEMBLY-302 > URL: http://jira.codehaus.org/browse/MASSEMBLY-302 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Reporter: James William Dumay > > From the original bug report: > "Untarring any Maven releases (1.0.2, 2.0-alpha-X) on Solaris 10 or Mac OS X > with gtar yields an error about "lone block at end", though it is successful." > This bug has been fixed in PLXCOMP-38 revision 7256. > Could we get a release of plexus-archiver out and included with the next > assembly release? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1984) please upload scannotations
please upload scannotations --- Key: MAVENUPLOAD-1984 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1984 Project: maven-upload-requests Issue Type: Task Reporter: nicolas de loof Scannotation allow to retrieve a set of annotated classes from classpath This bundle was create from the project POM.xml, with addition for required metadatas to build the bundle. -- 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-76) Dependencies report is incorrect
[
http://jira.codehaus.org/browse/MPIR-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128684#action_128684
]
Jim Christenson commented on MPIR-76:
-
This morning I ran the dependency:tree goal -- this view is correct and is
different than the project-info-reports:dependencies list. I would think that
these are getting their information from the same place...
> Dependencies report is incorrect
>
>
> Key: MPIR-76
> URL: http://jira.codehaus.org/browse/MPIR-76
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: Maven 2.0.7, SUN JVM 1.5.0_12, Windows XP
>Reporter: Duncan Doyle
>
> When generating a site from the following POM, the Dependencies report is
> incorrect.
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> test
> Test
> jar
> 0.0.1-SNAPSHOT
> Test
> Test Dependency Graphs
>
>
> commons-logging
> commons-logging
> 1.1
> compile
>
>
>
> javax.servlet
> servlet-api
> 2.4
> compile
>
>
>
>
> TestDependencyGraph
> file://${site.distribution.directory}/TestDependencyGraph
>
>
>
> {code}
> The Dependencies report of this project's generated site doesn't show the
> javax.servlet:servlet-api 2.4 as a compile dependency. Instead it shows it as
> a transitivie dependency. My guess is that it finds the servlet-api 2.3
> transitive dependency of commons-logging. However, the strange thing is that
> it does show the 2.4 version number in the report.
> The Dependency Graph has the same error, it shows the servlet-api as a
> transitive dependency of commons-logging instead of a compile dependency of
> my own project.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-137) Problem when setting default values for archetype-metadata.xml
[ http://jira.codehaus.org/browse/ARCHETYPE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jean-Prost updated ARCHETYPE-137: --- Attachment: archetype-jar.zip An archetype that shows that even if a couple of properties are defined, then not prompted when configuration occurs, an error is raised telling archetype is not configured > Problem when setting default values for archetype-metadata.xml > -- > > Key: ARCHETYPE-137 > URL: http://jira.codehaus.org/browse/ARCHETYPE-137 > Project: Maven Archetype > Issue Type: Bug >Affects Versions: 2.0-alpha-2 >Reporter: Dominique Jean-Prost > Attachments: archetype-jar.zip > > > I have an archetype-metadata.xml like this : > > > ... > > > > com.dexia.sofaxis > > < requiredProperty key="version"> > 1.0.0-SNAPSHOT > > > > If I try to use this archetype, groupId and version are not asked on command > line, but I then get the exception. If I remove the requiredProperty > elements, I don't get it. > [ERROR] The archetype is not configured > org.apache.maven.archetype.exception.ArchetypeNotConfigured: The archetype is > not configured > at > org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.generateArchetype(DefaultFilesetArchetypeGenerator.java:98) > at > org.apache.maven.archetype.generator.DefaultArchetypeGenerator.processFileSetArchetype(DefaultArchetypeGenerator.java:215) > at > org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype(DefaultArchetypeGenerator.java:130) > at > org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype(DefaultArchetypeGenerator.java:290) > at > org.apache.maven.archetype.DefaultArchetype.generateProjectFromArchetype(DefaultArchetype.java:75) > at > org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute(CreateProjectFromArchetypeMojo.java:169) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > 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) -- 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-3473) site generation with 2.0.9 and plugin:report (2.4 ONLY) is broken
[ http://jira.codehaus.org/browse/MNG-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3473. -- Resolution: Fixed this was resolved by releasing plugin tools 2.4.1 and reporting impl 2.0.4.1 > site generation with 2.0.9 and plugin:report (2.4 ONLY) is broken > - > > Key: MNG-3473 > URL: http://jira.codehaus.org/browse/MNG-3473 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.9 >Reporter: Brian Fox >Assignee: John Casey > Fix For: 2.0.9 > > > Generating a site that works in 2.0.8 breaks in 2.0.9 with an exception: > Caused by: java.lang.NoClassDefFoundError: > org/apache/maven/doxia/module/site/manager/SiteModuleNotFoundException > There is already a committed IT for this. It may be related to issues with > MPLUGIN-104, however in this case the 2.4 version of the plugin does work in > 2.0.8 so we need to investigate it in the core as well. -- 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: (MPMD-64) verbose output not useful for inner classes
[ http://jira.codehaus.org/browse/MPMD-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128772#action_128772 ] Xavier Le Vourch commented on MPMD-64: -- The just released pmd 4.2 fixes this problem as the inner classes names are not correctly generated in the xml reports. Updating the pmd-jdk14 version required in pom.xml to 4.2 is all that's needed... Xavier Index: pom.xml === --- pom.xml (revision 641455) +++ pom.xml (working copy) @@ -156,7 +156,7 @@ pmd pmd-jdk14 - 4.1.1 + 4.2 > verbose output not useful for inner classes > --- > > Key: MPMD-64 > URL: http://jira.codehaus.org/browse/MPMD-64 > Project: Maven 2.x PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 2.2 >Reporter: Sean Bridges >Priority: Minor > > With verbose output on, a pmd error in an inner class will produce output > like, > [INFO] PMD Failure: foo.bar.Anonymous$1:182 > Rule:SignatureDeclareThrowsException Priority:3 A method/constructor > shouldn't explicitly throw java.lang.Exception. > Rather than printing the class name, it would be more useful to print out the > file name. -- 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: (MPMD-64) verbose output not useful for inner classes
[ http://jira.codehaus.org/browse/MPMD-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128772#action_128772 ] xlv edited comment on MPMD-64 at 3/26/08 1:26 PM: --- The just released pmd 4.2 fixes this problem as the inner classes names are not correctly generated in the xml reports. Updating the pmd-jdk14 version required in pom.xml to 4.2 is all that's needed... Xavier was (Author: xlv): The just released pmd 4.2 fixes this problem as the inner classes names are not correctly generated in the xml reports. Updating the pmd-jdk14 version required in pom.xml to 4.2 is all that's needed... Xavier Index: pom.xml === --- pom.xml (revision 641455) +++ pom.xml (working copy) @@ -156,7 +156,7 @@ pmd pmd-jdk14 - 4.1.1 + 4.2 > verbose output not useful for inner classes > --- > > Key: MPMD-64 > URL: http://jira.codehaus.org/browse/MPMD-64 > Project: Maven 2.x PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 2.2 >Reporter: Sean Bridges >Priority: Minor > Attachments: version_update.txt > > > With verbose output on, a pmd error in an inner class will produce output > like, > [INFO] PMD Failure: foo.bar.Anonymous$1:182 > Rule:SignatureDeclareThrowsException Priority:3 A method/constructor > shouldn't explicitly throw java.lang.Exception. > Rather than printing the class name, it would be more useful to print out the > file name. -- 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: (MPMD-64) verbose output not useful for inner classes
[ http://jira.codehaus.org/browse/MPMD-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Le Vourch updated MPMD-64: - Attachment: version_update.txt > verbose output not useful for inner classes > --- > > Key: MPMD-64 > URL: http://jira.codehaus.org/browse/MPMD-64 > Project: Maven 2.x PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 2.2 >Reporter: Sean Bridges >Priority: Minor > Attachments: version_update.txt > > > With verbose output on, a pmd error in an inner class will produce output > like, > [INFO] PMD Failure: foo.bar.Anonymous$1:182 > Rule:SignatureDeclareThrowsException Priority:3 A method/constructor > shouldn't explicitly throw java.lang.Exception. > Rather than printing the class name, it would be more useful to print out the > file name. -- 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: (MAVENUPLOAD-1971) Please sync com.capgemini.platina groupId with central
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1971. --- Resolution: Fixed > Please sync com.capgemini.platina groupId with central > -- > > Key: MAVENUPLOAD-1971 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1971 > Project: maven-upload-requests > Issue Type: Wish >Reporter: nicolas de loof >Assignee: Carlos Sanchez > Attachments: platina.sh > > > I've created for my company (capgemini) some maven components and corporate > POM. > They're distributed under apache license, so I'd like them to get deployed on > central. -- 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: (MRESOURCES-61) PluginDescriptor not found
[ http://jira.codehaus.org/browse/MRESOURCES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128775#action_128775 ] Brill Pappin commented on MRESOURCES-61: I'm not saying its a bad idea (in fact I think it might be a good one). however its more complicated than that... for instance I *do* want reproducible builds, however the plugin should fix problems it has... otherwise the build is only as reproducible as the bug I worked around. Reproducible means to me that my code compiles, tests and packages as expected the same way, every time, not that the resources plugin uses a different route to do what it needs to do (if thats the case, I've written some very poor code indeed). Maybe the answer is to have maven warn when it detects an update and give you the option of installing... I don't know... however thats not the issues here, this is not MNG-3395. As for Maven locking down versions, it should have at least shipped with released versions of plugins... which apparently the resources plugin was not. What I am saying: a) i shouldn't have to worry about the resources plugin failing my build or not. b) even if I don't specifically lock down, i still shouldn't get the error I have been getting. c) all other plugins work without all that noise, including third party plugins (and my own plugins). I can't tell from my perspective if its an issue with maven dependency system or the resources plugin descriptor (which is what the error is) however, regardless of how I use it, there is still something that the developers of the resources plugin need to address. > PluginDescriptor not found > -- > > Key: MRESOURCES-61 > URL: http://jira.codehaus.org/browse/MRESOURCES-61 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Reporter: Brill Pappin > Attachments: maven-eclipse-integration-plugin.txt > > > The following error, every time I run a build has been ongoing for quite some > time now. > 3/21/08 3:34:06 PM EDT: Build error for /aleixo-console/pom.xml; > java.lang.IllegalStateException: The PluginDescriptor for the plugin > org.apache.maven.plugins:maven-resources-plugin was not found > It seems to go away if I run with a -U to update the plugins but comes back > regularly. > Can somebody please fix whatever issue is causing this to occur? -- 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-1968) allow disabling of plugin version discovery
[ http://jira.codehaus.org/browse/MNG-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128776#action_128776 ] Brill Pappin commented on MNG-1968: --- Actually I like this, but I'd turn it around, so that plugins don't update unless specifically told to do so... It would be nice to be able to rollback a plugin update as well. > allow disabling of plugin version discovery > --- > > Key: MNG-1968 > URL: http://jira.codehaus.org/browse/MNG-1968 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Plugins and Lifecycle >Reporter: Brett Porter > Fix For: 2.1 > > > for verifying reproducibility (and enable it on release:perform) -- 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: (MSITE-310) Macro in url of parent project is not expanded if only the site for a subproject is built
Macro in url of parent project is not expanded if only the site for a
subproject is built
-
Key: MSITE-310
URL: http://jira.codehaus.org/browse/MSITE-310
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-5
Reporter: Mike Hanafey
Priority: Minor
The parent POM has:
{code:xml}
${gxSite}/${project.build.finalName}
{code}
where "gxSite" is defined in settings.xml as "http://dna.dupont.com/site";
The module POM has:
{code:xml}
../MavenRoot/pom.xml
genomix
LeadTracker
0.1
...
${project.artifactId}
{code}
and the "site.xml" in the module includes a menu with ref="parent".
If goals "site site:deploy" is run from the parent, the link back to the parent
is fine, but if the same goal is run from the module, the link back to the
parent is generated as follows:
{code}
http://dna.dupont.com/site/LeadTracker-0.1/${gxSite}/LeadTracker-0.1/index.html
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-471) Infinite loop when ERROR is detected
[ http://jira.codehaus.org/browse/SUREFIRE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-471. - Resolution: Incomplete I can't reproduce this issue yet, so please reopen the bug with a reproducible test case when you've got one. > Infinite loop when ERROR is detected > > > Key: SUREFIRE-471 > URL: http://jira.codehaus.org/browse/SUREFIRE-471 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4.2 > Environment: Windows XP, Maven 2.0.8, Spring 1.2.8, JDK 1.6 >Reporter: Paul Benedict > > I can't supply a test case, but I will try to describe in detail exactly what > occurs so you can reproduce it: > My hibernate integration tests are in a separate profile named "itest". My > integration tests load Hibernate via Spring. I had a Hibernate mapping > configuration error in which my element was missing its element. > Now usually a mapping error causes the testing to immediately quit, but here > it didn't. Instead it reported the error and reran the whole phase again, and > again, etc. > > > > My debug output: > [DEBUG] Using JVM: D:\jdk1.6.0_01\jre\bin\java > [INFO] Surefire report directory: > D:\workspace\myproject\target\surefire-reports > Forking command line: cmd.exe /X /C '"D:\jdk1.6.0_01\jre\bin\java -jar > c:\temp\surefirebooter4340.jar c:\temp\surefire4338tmp > c:\temp\surefire4339tmp"' > .. test output. > 31876 [main] ERROR org.hibernate.util.XMLHelper - Error parsing XML: XML > InputStream(23) The content of element type "set" must match > "(meta*,subselect?,cache?,synchronize*,comment?,key,(element|one-to-many|many-to-many|composite-element|many-to-any),loader?,sql-insert?,sql-update?,sql-delete?,sql-delete-all?,filter*)" > .. test output.. > ..repeat. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-478) Specifying true plus an results in an empty surefire-report.html file
[
http://jira.codehaus.org/browse/SUREFIRE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128793#action_128793
]
Robert Shanahan commented on SUREFIRE-478:
--
I worked around this by setting false. Apparently each
submodule ran the same surefire-report plugin config and the last to run was
the ear module, which has no test results, hence the empty surefire-report.html
file. The following configuration works.
{code:xml}
org.apache.maven.plugins
maven-surefire-report-plugin
false
/data/reports
true
{code}
> Specifying true plus an results in
> an empty surefire-report.html file
> --
>
> Key: SUREFIRE-478
> URL: http://jira.codehaus.org/browse/SUREFIRE-478
> Project: Maven Surefire
> Issue Type: Bug
> Components: report plugin
>Affects Versions: 2.4.2
> Environment: Windows XP SP2; jdk1.5.0_14; Maven 2.0.8
>Reporter: Robert Shanahan
>
> The following configuration snippet, from the parent pom of a multi-module
> project, results in an empty surefire-report.html file. Using default output
> directory works just fine with aggregate set to true. Setting aggregate to
> false with a specified output directory has the same result as specifying no
> output directory and aggregate to false, i.e. a non-empty
> surefire-report.html file is created, but it has no test results since it is
> the top level pom.
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
>
> org.apache.maven.plugins
> maven-surefire-report-plugin
>
> /data/reports
> true
>
>
>
> test
>
> report-only
>
>
>
>
>
>
--
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-478) Specifying true plus an results in an empty surefire-report.html file
[ http://jira.codehaus.org/browse/SUREFIRE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Shanahan closed SUREFIRE-478. Resolution: Fixed Fix Version/s: 2.4.2 > Specifying true plus an results in > an empty surefire-report.html file > -- > > Key: SUREFIRE-478 > URL: http://jira.codehaus.org/browse/SUREFIRE-478 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.4.2 > Environment: Windows XP SP2; jdk1.5.0_14; Maven 2.0.8 >Reporter: Robert Shanahan > Fix For: 2.4.2 > > > The following configuration snippet, from the parent pom of a multi-module > project, results in an empty surefire-report.html file. Using default output > directory works just fine with aggregate set to true. Setting aggregate to > false with a specified output directory has the same result as specifying no > output directory and aggregate to false, i.e. a non-empty > surefire-report.html file is created, but it has no test results since it is > the top level pom. > > > > org.apache.maven.plugins > maven-surefire-plugin > > > org.apache.maven.plugins > maven-surefire-report-plugin > > /data/reports > true > > > > test > > report-only > > > > > > -- 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-469) test environment is not share between dependent modules
[ http://jira.codehaus.org/browse/SUREFIRE-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-469. - Resolution: Incomplete This bug description doesn't contain enough information for me to reproduce the bug. Please provide a reduced test case demonstrating the problem, ideally in the form of a minimal Maven project exhibiting the problem > test environment is not share between dependent modules > --- > > Key: SUREFIRE-469 > URL: http://jira.codehaus.org/browse/SUREFIRE-469 > Project: Maven Surefire > Issue Type: Bug > Components: plugin >Affects Versions: 2.3 > Environment: Windows XP > Maven version: 2.0.7 > Java version: 1.5.0_12 > OS name: "windows xp" version: "5.1" arch: "x86" >Reporter: Bogdan Serban > > I have to dependent modules which have some special dependencies for testing. > 1. Let say the first one has a JDBC driver specified > 2. When i test the second the test fails because the test dependency from the > first module is not included. > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-475) Classloader getResource() returns resource from wrong directory
[
http://jira.codehaus.org/browse/SUREFIRE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich updated SUREFIRE-475:
--
Description:
In upgrading from version 2.3 to 2.4.2, we encountered a different behaviour in
classloading. We have a classes/ and a test-classes/ folder under target, and
both contain the same package, "foo":
{noformat}
|-- target/test-classes
| `-- foo
`-- some file
|-- target/classes
`-- foo
{noformat}
In 2.3, a Classloader.getResource() call in our app returns the
target/test-classes/foo folder, in which we find some file.
In 2.4.2, the same code returns the target/classes/foo folder, and so some file
cannot be found. Note that there are two actual directories that resolve to
from same classpath location.
To get the classes folder in the classpath when running tests, we are using
this testResources in the pom:
src/test/resources
src/main/resources
Perhaps SUREFIRE-443 can provide a way to correctly copy resources between the
classes and test-classes folders, so that there is only one location on the
disk for each classpath URI.
was:
In upgrading from version 2.3 to 2.4.2, we encountered a different behaviour in
classloading. We have a classes/ and a test-classes/ folder under target, and
both contain the same package, "foo":
|-- target/test-classes
| `-- foo
`-- some file
|-- target/classes
`-- foo
In 2.3, a Classloader.getResource() call in our app returns the
target/test-classes/foo folder, in which we find some file.
In 2.4.2, the same code returns the target/classes/foo folder, and so some file
cannot be found. Note that there are two actual directories that resolve to
from same classpath location.
To get the classes folder in the classpath when running tests, we are using
this testResources in the pom:
src/test/resources
src/main/resources
Perhaps SUREFIRE-443 can provide a way to correctly copy resources between the
classes and test-classes folders, so that there is only one location on the
disk for each classpath URI.
I had a long thread about this issue on the Maven users list.
http://www.nabble.com/Surefire-2.4.1-classpath-order-tt15498825s177.html
Here's a summary:
The resource retrieved is the one that appears first in the test classpath; if
you're getting the "wrong" resource, it's because your classpath is in the
wrong order, which is often due to a Maven bug, but it's often very non-obvious
why that would be.
Take a look at http://jira.codehaus.org/browse/MNG-3118. That bug was fixed in
Maven 2.0.8 and called out in the release announcement as a backwards
compatibility risk:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00432.html
As noted in MNG-3118, Surefire 2.3 had a bizarre classpath ordering bug that
made the test classpath appear to be correct (test-classes first) under Maven
2.0.7 for some users with large classpaths:
http://jira.codehaus.org/browse/SUREFIRE-61
SUREFIRE-61 was fixed in Surefire 2.3.1. Notably, it would make the "Test
Classpath" output in -X look correct, while secretly under the hood it would
munge the classpath incorrectly!
As a result, for at least one project here at my work, we've seen:
Maven 2.0.7 + Surefire 2.3: test-classes before classes
Maven 2.0.8 + Surefire 2.3: classes before test-classes
Maven 2.0.7 + Surefire 2.3.1 or higher: classes before test-classes
Maven 2.0.8 + Surefire 2.3.1 or higher: test-classes before classes
Benjamin checked in a classpath ordering test in the Surefire trunk that we now
run with every release. It's currently passing for me with Surefire 2.4.1 (and
2.4.2-SNAPSHOT) and Maven 2.0.8, and failing with Maven 2.0.7.
Finally, note that your "real" classpath is being output in your
target/surefire-reports/*.xml files as the "surefire.test.classpath" property;
that may be useful for debugging purposes.
> Classloader getResource() returns resource from wrong directory
> ---
>
> Key: SUREFIRE-475
> URL: http://jira.codehaus.org/browse/SUREFIRE-475
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.4.2
>Reporter: Alex Eagle
>
> In upgrading from version 2.3 to 2.4.2, we encountered a different behaviour
> in classloading. We have a classes/ and a test-classes/ folder under target,
> and both contain the same package, "foo":
> {noformat}
> |-- target/test-classes
> | `-- foo
> `-- some file
> |-- target/classes
> `-- foo
> {noformat}
> In 2.3, a Classloader.getResource() call in our app returns the
> target/test-classes/foo folder, in which we find some file.
> In 2.4.2, the same code returns the target/classes/foo folde
[jira] Closed: (SUREFIRE-475) Classloader getResource() returns resource from wrong directory
[
http://jira.codehaus.org/browse/SUREFIRE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed SUREFIRE-475.
-
Resolution: Cannot Reproduce
As mentioned, we've got an integration test checked in that verifies this
behavior explicitly. If it's not working for you, then please reopen this bug
and provide a reduced test case demonstrating the problem, ideally in the form
of a minimal Maven project that has the bug.
> Classloader getResource() returns resource from wrong directory
> ---
>
> Key: SUREFIRE-475
> URL: http://jira.codehaus.org/browse/SUREFIRE-475
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.4.2
>Reporter: Alex Eagle
>
> In upgrading from version 2.3 to 2.4.2, we encountered a different behaviour
> in classloading. We have a classes/ and a test-classes/ folder under target,
> and both contain the same package, "foo":
> {noformat}
> |-- target/test-classes
> | `-- foo
> `-- some file
> |-- target/classes
> `-- foo
> {noformat}
> In 2.3, a Classloader.getResource() call in our app returns the
> target/test-classes/foo folder, in which we find some file.
> In 2.4.2, the same code returns the target/classes/foo folder, and so some
> file cannot be found. Note that there are two actual directories that resolve
> to from same classpath location.
> To get the classes folder in the classpath when running tests, we are using
> this testResources in the pom:
>
>
>
>
> src/test/resources
>
>
>
> src/main/resources
>
>
>
> Perhaps SUREFIRE-443 can provide a way to correctly copy resources between
> the classes and test-classes folders, so that there is only one location on
> the disk for each classpath URI.
--
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-466) IsolatedClassLoader should also delegate resource loading
[ http://jira.codehaus.org/browse/SUREFIRE-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-466. - Resolution: Incomplete What are the symptoms of this bug? Can you provide an example minimal Maven project that demonstrates the problem? > IsolatedClassLoader should also delegate resource loading > - > > Key: SUREFIRE-466 > URL: http://jira.codehaus.org/browse/SUREFIRE-466 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.4.2 >Reporter: Mark Hobson > > IsolatedClassLoader currently delegates class loading according to whether it > is configured to use parent- or child-delegation, but resource loading does > not follow the same rules. Need to override getResource and getResources > accordingly. -- 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-478) Specifying true plus an results in an empty surefire-report.html file
[ http://jira.codehaus.org/browse/SUREFIRE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed SUREFIRE-478. -- Resolution: Won't Fix > Specifying true plus an results in > an empty surefire-report.html file > -- > > Key: SUREFIRE-478 > URL: http://jira.codehaus.org/browse/SUREFIRE-478 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.4.2 > Environment: Windows XP SP2; jdk1.5.0_14; Maven 2.0.8 >Reporter: Robert Shanahan > Fix For: 2.4.2 > > > The following configuration snippet, from the parent pom of a multi-module > project, results in an empty surefire-report.html file. Using default output > directory works just fine with aggregate set to true. Setting aggregate to > false with a specified output directory has the same result as specifying no > output directory and aggregate to false, i.e. a non-empty > surefire-report.html file is created, but it has no test results since it is > the top level pom. > > > > org.apache.maven.plugins > maven-surefire-plugin > > > org.apache.maven.plugins > maven-surefire-report-plugin > > /data/reports > true > > > > test > > report-only > > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (SUREFIRE-478) Specifying true plus an results in an empty surefire-report.html file
[ http://jira.codehaus.org/browse/SUREFIRE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann reopened SUREFIRE-478: > Specifying true plus an results in > an empty surefire-report.html file > -- > > Key: SUREFIRE-478 > URL: http://jira.codehaus.org/browse/SUREFIRE-478 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.4.2 > Environment: Windows XP SP2; jdk1.5.0_14; Maven 2.0.8 >Reporter: Robert Shanahan > Fix For: 2.4.2 > > > The following configuration snippet, from the parent pom of a multi-module > project, results in an empty surefire-report.html file. Using default output > directory works just fine with aggregate set to true. Setting aggregate to > false with a specified output directory has the same result as specifying no > output directory and aggregate to false, i.e. a non-empty > surefire-report.html file is created, but it has no test results since it is > the top level pom. > > > > org.apache.maven.plugins > maven-surefire-plugin > > > org.apache.maven.plugins > maven-surefire-report-plugin > > /data/reports > true > > > > test > > report-only > > > > > > -- 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-340) Resource classpaths differ if project has flat structure, causing MappingExceptions and more.
[ http://jira.codehaus.org/browse/SUREFIRE-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-340. - Resolution: Cannot Reproduce Yup, just tried it with Maven 2.0.8 and Surefire 2.4.2. (All I did was change the Surefire version in surefire-bug-nested-structure/pom.xml and surefire-bug-flat-structure/parent/pom.xml.) I ran "mvn test" in s-b-n-s and in s-b-f-s/parent. The test passed in both cases. Maven version: 2.0.8 Java version: 1.5.0_12 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" > Resource classpaths differ if project has flat structure, causing > MappingExceptions and more. > - > > Key: SUREFIRE-340 > URL: http://jira.codehaus.org/browse/SUREFIRE-340 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.6, > IBM 1.4.2 JDK on RHEL 4 on an HP Itanium, and also Apple 1.5.0 on Mac OSX >Reporter: Barrett Nuzum > Attachments: surefire-bug-testcases.tar.gz > > > We have heavy dependence on Spring and Hibernate. > We maintain a flat project structure as this is a great deal easier to manage > in an IDE. > We have tests that pass if you build them from a leaf-level application. > If run from the parent project, as a multimodule build, the tests fail. > Root >\- Parent Build >\- Child1 Build > The exact same project can pass a multimodule build if the project structure > is nested. > Root > \- Parent Build >\- Child1 Build > Both scenarios are included in the attached file. > The child builds correctly under both scenarios if you cd directly to it's > directory and run install or test. > Both builds display an appropriate classpath if run with -X, but the flat > structure cannot find the resource. > I believe this to be an incompatibility with Spring and it's methods for > getting a ResourceLoader. > All permutations and combinations of: > , and > also have no effect. -- 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: (MECLIPSE-411) maifest property usage is only for ogsi maifests
[ http://jira.codehaus.org/browse/MECLIPSE-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-411: - Fix Version/s: 2.5.1 > maifest property usage is only for ogsi maifests > > > Key: MECLIPSE-411 > URL: http://jira.codehaus.org/browse/MECLIPSE-411 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: OSGi, Manifest, WTP support >Affects Versions: 2.5 > Environment: any >Reporter: Richard van Nieuwenhoven >Assignee: Arnaud Heritier > Fix For: 2.5.1 > > Attachments: manifest.patch > > > the manifest property of the eclipse plugin is only for the osgi writer and > not for the wtp manifest, because the wtp manifest is a special case that > will not be included in the maven build just in the eclipse classpath. The > problem is that the property has a default value and by that deacivates the > WTP classpath! > included a patch for the 2.5 release, including some renaming so it won't > happen again. > please release a 2.5.1 version with this 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: (MECLIPSE-412) Generation of jst.java Facet for EAR packaging kills my RAD workspace
[ http://jira.codehaus.org/browse/MECLIPSE-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-412: - Fix Version/s: 2.5.1 > Generation of jst.java Facet for EAR packaging kills my RAD workspace > - > > Key: MECLIPSE-412 > URL: http://jira.codehaus.org/browse/MECLIPSE-412 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: RAD support, WTP support >Affects Versions: 2.5 > Environment: Windows, RAD 7.0.0.5 >Reporter: Kuno Baeriswyl > Fix For: 2.5.1 > > Attachments: EclipseWtpFacetsWriter-RAD-patch.txt > > > The eclipse:eclipse or eclipse:rad goals generate jst.java Facets like : > > > > > > > > > > This facets aren't necessary for EAR artifacts in RAD, brings it in a strange > state and kills my workspace. The side effects are particularly annoying in > the debug mode, where on every step an error message pop-ups. The > maven-eclipse-plugin must avoid this facets and generate them like following: > > > > > > > > I think you have done a great work with the recent 2.5 release. Just need to > have fixed this. Thanks for everything. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-266) plugin applies java facet to ear project
[ http://jira.codehaus.org/browse/MECLIPSE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-266: - Fix Version/s: 2.5.1 > plugin applies java facet to ear project > > > Key: MECLIPSE-266 > URL: http://jira.codehaus.org/browse/MECLIPSE-266 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.3 > Environment: Windows XP >Reporter: Srepfler Srgjan > Fix For: 2.5.1 > > Attachments: MECLIPSE-266-2.5.patch, > MECLIPSE-266-maven-eclipse-plugin.patch, MECLIPSE-266.patch > > > In .settings/org.eclipse.wst.common.project.facet.core.xml of the EAR module > I'm getting this: > > > > > > > This is a wrong facet on a EAR module and I can't compile if I don't edit > this file manually (I can't do it from the project properties - facets dialog) -- 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: (MECLIPSE-411) manifest property usage is only for ogsi maifests
[ http://jira.codehaus.org/browse/MECLIPSE-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-411: - Summary: manifest property usage is only for ogsi maifests (was: maifest property usage is only for ogsi maifests) > manifest property usage is only for ogsi maifests > - > > Key: MECLIPSE-411 > URL: http://jira.codehaus.org/browse/MECLIPSE-411 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: OSGi, Manifest, WTP support >Affects Versions: 2.5 > Environment: any >Reporter: Richard van Nieuwenhoven >Assignee: Arnaud Heritier > Fix For: 2.5.1 > > Attachments: manifest.patch > > > the manifest property of the eclipse plugin is only for the osgi writer and > not for the wtp manifest, because the wtp manifest is a special case that > will not be included in the maven build just in the eclipse classpath. The > problem is that the property has a default value and by that deacivates the > WTP classpath! > included a patch for the 2.5 release, including some renaming so it won't > happen again. > please release a 2.5.1 version with this 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] Commented: (MDEPLOY-48) deploy:deploy-file does not support deploying sources jars too
[ http://jira.codehaus.org/browse/MDEPLOY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128806#action_128806 ] James Kingsbery commented on MDEPLOY-48: Is there progress on this? I got the same behavior as Arik. My company will need this feature, so I'd be willing to fix it if no one's started working on it. > deploy:deploy-file does not support deploying sources jars too > -- > > Key: MDEPLOY-48 > URL: http://jira.codehaus.org/browse/MDEPLOY-48 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Geoffrey De Smet > > deploy:deploy does, but deploy:deploy-file doesn't have a parameter to tell > him where the sources jar is: > mvn deploy:deploy-file -Dfile=$artifactFile -DpomFile=$pomFile -Durl=$toRepo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-156) dependency:analyze mistakenly reports an implemented interface as an unused, declared dependency
dependency:analyze mistakenly reports an implemented interface as an unused, declared dependency Key: MDEP-156 URL: http://jira.codehaus.org/browse/MDEP-156 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: analyze Affects Versions: 2.0 Reporter: Elliot Metsger Assignee: Brian Fox When executing dependency:analyze on my project, analyze mistakenly identifies a compile time dependency as unused. When I remove the dependency from the POM, the compile fails. When I add it back in the compile succeeds. The POM in question is located at: http://dspace.svn.sourceforge.net/svnroot/dspace/branches/dspace-1_5_x/dspace-xmlui/dspace-xmlui-wing/pom.xml The artifact that is mistakenly identified as "declared but unused" is: org.dspace.xmlui.excalibur excalibur-pool-api 2.1 The compile fails like so: /Users/esm/idea/workspace/dspace-1.5.x/dspace-xmlui/dspace-xmlui-wing/src/main/java/org/dspace/app/xmlui/wing/AbstractWingTransformer.java:[68,16] cannot access org.apache.avalon.excalibur.pool.Recyclable file org/apache/avalon/excalibur/pool/Recyclable.class not found public abstract class AbstractWingTransformer extends AbstractTransformer org.apache.avalon.excalibur.pool.Recyclable is an interface implemented by org.dspace.app.xmlui.wing.BitstreamReader and org.dspace.app.xmlui.cocoon.DSpaceFeedGenerator. -- 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-156) dependency:analyze mistakenly reports an implemented interface as an unused, declared dependency
[ http://jira.codehaus.org/browse/MDEP-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128807#action_128807 ] Elliot Metsger commented on MDEP-156: - Let me dig into this a little more and I'll report back. The pom in question has a lot of stuff in it, and in my local working copy it is modified - different from - the link given in the description.So I'll dig more and if i need to i'll attach it. > dependency:analyze mistakenly reports an implemented interface as an unused, > declared dependency > > > Key: MDEP-156 > URL: http://jira.codehaus.org/browse/MDEP-156 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.0 >Reporter: Elliot Metsger >Assignee: Brian Fox > > When executing dependency:analyze on my project, analyze mistakenly > identifies a compile time dependency as unused. > When I remove the dependency from the POM, the compile fails. When I add it > back in the compile succeeds. > The POM in question is located at: > http://dspace.svn.sourceforge.net/svnroot/dspace/branches/dspace-1_5_x/dspace-xmlui/dspace-xmlui-wing/pom.xml > The artifact that is mistakenly identified as "declared but unused" is: > >org.dspace.xmlui.excalibur >excalibur-pool-api >2.1 > > The compile fails like so: > /Users/esm/idea/workspace/dspace-1.5.x/dspace-xmlui/dspace-xmlui-wing/src/main/java/org/dspace/app/xmlui/wing/AbstractWingTransformer.java:[68,16] > cannot access org.apache.avalon.excalibur.pool.Recyclable > file org/apache/avalon/excalibur/pool/Recyclable.class not found > public abstract class AbstractWingTransformer extends AbstractTransformer > org.apache.avalon.excalibur.pool.Recyclable is an interface implemented by > org.dspace.app.xmlui.wing.BitstreamReader and > org.dspace.app.xmlui.cocoon.DSpaceFeedGenerator. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-463) ClassCastException when using testng suiteXmlFile
[ http://jira.codehaus.org/browse/SUREFIRE-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128811#action_128811 ] Dan Fabulich commented on SUREFIRE-463: --- Well, I think I like the idea of this patch, but I'm a bit creeped out by it, because I can't reproduce your example. We've got a sample integration test that uses suiteXmlFile and it passes (and, more generally, I use that feature all the time). I tried just pasting your snippet into that test and running it with "-P browser", hoping that maybe the problem was with the use of a profile, but no, the test ran just fine on my machine. Can you provide a minimal example Maven project that reproduces the problem? We can check that into the integration test suite to make sure that issues like this don't crop up again in the future. > ClassCastException when using testng suiteXmlFile > - > > Key: SUREFIRE-463 > URL: http://jira.codehaus.org/browse/SUREFIRE-463 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4.2 > Environment: linux 2.6.22-1-mepis-smp >Reporter: Andreas Andreou > Attachments: SUREFIRE-463__handle_TestNG_xmlTestSuites.patch > > > The related pom part is: > > browser > > > > org.apache.maven.plugins > maven-surefire-plugin > > > > src/test/resources/testng-browser.xml > > > > > > > Issuing mvn -Pbrowser test results in the exception: > java.lang.ClassCastException: java.io.File cannot be cast to java.lang.String > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesForkPerTestSet(SurefireBooter.java:403) > at > org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:249) > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:492) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Any workarounds for this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-150) New maven-archetype-plugin ignores the remoteRepositories system property
[ http://jira.codehaus.org/browse/ARCHETYPE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128810#action_128810 ] Bruce Snyder commented on ARCHETYPE-150: The reason I created this issue is because the archetype:create goal in the maven-archetype-plugin version 2.0-alpha-2 ignores the remoteRepositories property, not the archetype:generate goal. > New maven-archetype-plugin ignores the remoteRepositories system property > -- > > Key: ARCHETYPE-150 > URL: http://jira.codehaus.org/browse/ARCHETYPE-150 > Project: Maven Archetype > Issue Type: Bug >Affects Versions: 2.0-alpha-2 >Reporter: Bruce Snyder >Assignee: Raphaël Piéroni > > When executing the latest maven-archetype-plugin using the archetype:create > goal with the -DremoteRepositories system property, the remoteRepositories > property is ignored. See an example of this below with full debug output: > $ mvn -X archetype:create -DarchetypeGroupId=org.apache.servicemix.tooling > -DarchetypeArtifactId=servicemix-service-unit -DarchetypeVersion=3.3.0.7-fuse > -DgroupId=com.mycompany -DartifactId=my-su > -DremoteRepositories=http://repo.open.iona.com/maven2/ > + Error stacktraces are turned on. > Maven version: 2.0.8 > Java version: 1.5.0_13 > OS name: "mac os x" version: "10.4.11" arch: "i386" Family: "unix" > [DEBUG] Building Maven user-level plugin registry from: > '/Users/bsnyder/.m2/plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > '/Users/bsnyder/apache-maven-2.0.8/conf/plugin-registry.xml' > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'archetype'. > [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins > [DEBUG] Loading plugin prefixes from group: org.codehaus.mojo > [DEBUG] maven-archetype-plugin: resolved to version 2.0-alpha-2 from > repository central > [DEBUG] Retrieving parent-POM: > org.apache.maven.archetype:maven-archetype::2.0-alpha-2 for project: > org.apache.maven.plugins:maven-archetype-plugin:maven-plugin:null from the > repository. > [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for project: > org.apache.maven.archetype:maven-archetype:pom:2.0-alpha-2 from the > repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: > org.apache.maven:maven-parent:pom:7 from the repository. > [DEBUG] Adding managed dependencies for > org.apache.maven.plugins:maven-archetype-plugin > [DEBUG] junit:junit:jar:3.8.1:test > [DEBUG] commons-io:commons-io:jar:1.3.1 > [DEBUG] commons-collections:commons-collections:jar:3.2 > [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-6:test > [DEBUG] org.apache.maven:maven-model:jar:2.0.8 > [DEBUG] dom4j:dom4j:jar:1.6.1 > [DEBUG] org.codehaus.plexus:plexus-velocity:jar:1.1.3 > [DEBUG] > org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1 > [DEBUG] org.apache.maven:maven-project:jar:2.0.8 > [DEBUG] org.apache.maven:maven-core:jar:2.0.8 > [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.8 > [DEBUG] jdom:jdom:jar:1.0 > [DEBUG] org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-5 > [DEBUG] > org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0-beta-1:test > [DEBUG] velocity:velocity:jar:1.4 > [DEBUG] net.sourceforge.jchardet:jchardet:jar:1.0 > [DEBUG] org.apache.maven.archetype:archetype-common:jar:2.0-alpha-2 > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.4.6 > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [archetype:create] (aggregator-style) > [INFO] > > [DEBUG] > org.apache.maven.plugins:maven-archetype-plugin:maven-plugin:2.0-alpha-2:runtime > (selected for runtime) > [DEBUG] Adding managed dependencies for unknown:archetype-common > [DEBUG] junit:junit:jar:3.8.1:test > [DEBUG] commons-io:commons-io:jar:1.3.1 > [DEBUG] commons-collections:commons-collections:jar:3.2 > [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-6:test > [DEBUG] org.apache.maven:maven-model:jar:2.0.8 > [DEBUG] dom4j:dom4j:jar:1.6.1 > [DEBUG] org.codehaus.plexus:plexus-velocity:jar:1.1.3 > [DEBUG] > org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1 > [DEBUG] org.apache.maven:maven-project:jar:2.0.8 > [DEBUG] org.apache.maven:maven-core:jar:2.0.8 > [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.8 > [DEBUG] jdom:jdom:jar:1.0 > [DEBUG] org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-5 > [DEBUG] net.sourceforge.jchardet:jchardet:jar:1.0 > [DEBUG] velocity:velocity:jar:1.4 > [DEBUG] > org.apache.maven.shared:maven-plugin-testing-harn
[jira] Created: (JXR-59) speed up AbstractJxrReport.hasSources()
speed up AbstractJxrReport.hasSources() --- Key: JXR-59 URL: http://jira.codehaus.org/browse/JXR-59 Project: Maven JXR Issue Type: Improvement Components: maven2 jxr plugin Affects Versions: 2.1 Reporter: Sean Bridges Priority: Minor The method AbstractJxrReport.hasSources( File dir ) spends a lot of time scanning .svn directories when I do my build. If you replace the line, else if ( currentFile.isDirectory() ) with the lines else if ( currentFile.isDirectory() && Character.isJavaIdentifierStart(currentFile.getName().charAt(0)) ) You will speed this up. If the first character in the directory is not a valid java identifier start, then the directory cannot contain java code. '.' is not a valid java identifier start, so .svn directories are ignored when scanning for sources. -- 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-3482) merging managed dependencies happens before managed-dependency versions are interpolated
merging managed dependencies happens before managed-dependency versions are interpolated Key: MNG-3482 URL: http://jira.codehaus.org/browse/MNG-3482 Project: Maven 2 Issue Type: Bug Components: POM Affects Versions: 2.0.9, 2.1-alpha-1 Reporter: John Casey mergeManagedDependencies(..) happens ahead of processProjectLogic(..) inside the DefaultMavenProjectBuilder.buildInternal(..) method. This means that, if the current POM specifies an expression for one of the managed dependencies that have scope == import, the artifact resolver will fail to resolve the managed dependency with an uninterpolated version. -- 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-3483) merging managed dependencies should ONLY work when scope == import explicitly
merging managed dependencies should ONLY work when scope == import explicitly - Key: MNG-3483 URL: http://jira.codehaus.org/browse/MNG-3483 Project: Maven 2 Issue Type: Bug Components: POM Affects Versions: 2.0.9, 2.1-alpha-1 Reporter: John Casey dependencies of type == pom are useful for standardizing a set of dependencies for use in multiple projects that don't share a dependencyManagement section or a common parent POM. Limiting their use to import operations will severely curtail this option, and can cause a lot of problems with existing builds where modules have a type == pom, and are listed in dependencyManagement so they can be referenced elsewhere. This is related to MNG-3391, so I'll also link them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3483) merging managed dependencies should ONLY work when scope == import explicitly
[ http://jira.codehaus.org/browse/MNG-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3483: Affects Version/s: (was: 2.0.9) > merging managed dependencies should ONLY work when scope == import explicitly > - > > Key: MNG-3483 > URL: http://jira.codehaus.org/browse/MNG-3483 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.1-alpha-1 >Reporter: John Casey > > dependencies of type == pom are useful for standardizing a set of > dependencies for use in multiple projects that don't share a > dependencyManagement section or a common parent POM. Limiting their use to > import operations will severely curtail this option, and can cause a lot of > problems with existing builds where modules have a type == pom, and are > listed in dependencyManagement so they can be referenced elsewhere. > This is related to MNG-3391, so I'll also link them. -- 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-3483) merging managed dependencies should ONLY work when scope == import explicitly
[ http://jira.codehaus.org/browse/MNG-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128816#action_128816 ] John Casey commented on MNG-3483: - code is in place, but needs a unit test to complete it. > merging managed dependencies should ONLY work when scope == import explicitly > - > > Key: MNG-3483 > URL: http://jira.codehaus.org/browse/MNG-3483 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Assignee: John Casey > > dependencies of type == pom are useful for standardizing a set of > dependencies for use in multiple projects that don't share a > dependencyManagement section or a common parent POM. Limiting their use to > import operations will severely curtail this option, and can cause a lot of > problems with existing builds where modules have a type == pom, and are > listed in dependencyManagement so they can be referenced elsewhere. > This is related to MNG-3391, so I'll also link them. -- 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-3482) merging managed dependencies happens before managed-dependency versions are interpolated
[ http://jira.codehaus.org/browse/MNG-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128817#action_128817 ] John Casey commented on MNG-3482: - fix is in place on both 2.0.x and trunk branches, but needs a unit test for completeness. > merging managed dependencies happens before managed-dependency versions are > interpolated > > > Key: MNG-3482 > URL: http://jira.codehaus.org/browse/MNG-3482 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.9, 2.1-alpha-1 >Reporter: John Casey >Assignee: John Casey > > mergeManagedDependencies(..) happens ahead of processProjectLogic(..) inside > the DefaultMavenProjectBuilder.buildInternal(..) method. This means that, if > the current POM specifies an expression for one of the managed dependencies > that have scope == import, the artifact resolver will fail to resolve the > managed dependency with an uninterpolated version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-463) ClassCastException when using testng suiteXmlFile
[ http://jira.codehaus.org/browse/SUREFIRE-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128821#action_128821 ] Andreas Andreou commented on SUREFIRE-463: -- Took me a while to recreate this in a simple project, but i consistently get it when configuring surefire to use a pertest forkMode and defining the profile (and surefire extra configurations) in a child project... I'm attaching a zip for you to recreate this, from the top level try: mvn test and then mvn -Pbrowser test > ClassCastException when using testng suiteXmlFile > - > > Key: SUREFIRE-463 > URL: http://jira.codehaus.org/browse/SUREFIRE-463 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4.2 > Environment: linux 2.6.22-1-mepis-smp >Reporter: Andreas Andreou > Attachments: SUREFIRE-463__handle_TestNG_xmlTestSuites.patch > > > The related pom part is: > > browser > > > > org.apache.maven.plugins > maven-surefire-plugin > > > > src/test/resources/testng-browser.xml > > > > > > > Issuing mvn -Pbrowser test results in the exception: > java.lang.ClassCastException: java.io.File cannot be cast to java.lang.String > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesForkPerTestSet(SurefireBooter.java:403) > at > org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:249) > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:492) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Any workarounds for this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-463) ClassCastException when using testng suiteXmlFile
[ http://jira.codehaus.org/browse/SUREFIRE-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Andreou updated SUREFIRE-463: - Attachment: surefire-bug.zip > ClassCastException when using testng suiteXmlFile > - > > Key: SUREFIRE-463 > URL: http://jira.codehaus.org/browse/SUREFIRE-463 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4.2 > Environment: linux 2.6.22-1-mepis-smp >Reporter: Andreas Andreou > Attachments: SUREFIRE-463__handle_TestNG_xmlTestSuites.patch, > surefire-bug.zip > > > The related pom part is: > > browser > > > > org.apache.maven.plugins > maven-surefire-plugin > > > > src/test/resources/testng-browser.xml > > > > > > > Issuing mvn -Pbrowser test results in the exception: > java.lang.ClassCastException: java.io.File cannot be cast to java.lang.String > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesForkPerTestSet(SurefireBooter.java:403) > at > org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:249) > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:492) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Any workarounds for this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-3119) Duplicate attached artifacts should not be allowed.
[ http://jira.codehaus.org/browse/MNG-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox reopened MNG-3119: This exception is propagating up and stopping the build, which is not the intended behavior > Duplicate attached artifacts should not be allowed. > --- > > Key: MNG-3119 > URL: http://jira.codehaus.org/browse/MNG-3119 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.7 >Reporter: Paul Gier >Assignee: John Casey > Fix For: 2.0.9, 2.1-alpha-1 > > Attachments: MNG-3119-maven-project-r558713.patch > > > Currently, a project allows duplicate artifacts to be attached. This causes > the second and other additional artifacts to overwrite the first attached > artifact. This occurs during the package, install, and deploy phases. > This can be reproduced by adding three instances of the source plugin (with > different ids) to a project build configuration. The 2nd plugin will > overwrite the first, and the third will overwrite the second. > The desired behaviour is that the user should receive a warning or error when > this happens. -- 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-2174) do not propogate to child POM plugins (potentially scoped to only affecting child POM plugins that live within a
[ http://jira.codehaus.org/browse/MNG-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128823#action_128823 ] Erick Dovale commented on MNG-2174: --- I am hitting this bug. In my case I have profiles defined in the parent pom of a multi-module project. In the profile's pluginManagement section (db profiles) I defined dependencies for the plugins (db drivers). In the parent pom's pluginManagement section I wanted to defined the version of the plugin to avoid having to repeat this information on every single DB profile. As soon as I did this the dependency defined in the pluginManagement section of the profile got lost in translation. The solution is then to live with the repeated version for now. The prags would be disappointed. > do not propogate to child > POM plugins (potentially scoped to only affecting child POM plugins that live > within a ) > - > > Key: MNG-2174 > URL: http://jira.codehaus.org/browse/MNG-2174 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation, Plugins and Lifecycle >Reporter: John Allen > Fix For: 2.1 > > > do not propogate to child > POM plugins. > Kenny believe this works OKAY if the childs are using the parent > preconfigured plugins in their main section > however it does NOT work if the childs are trying to use those preconfigured > plugins via their own . Configuration propogates through okay but > dependencies are missing and have to be respecified in the child POMs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3119) Duplicate attached artifacts should not be allowed.
[ http://jira.codehaus.org/browse/MNG-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3119: --- Attachment: build.log See the attached build log for the exception. The notable thing here is that the duplicated attachment is coming from a forked lifecycle. IMO the user can't control this and it shouldn't even be a warning in that case. They'll be looking for something they can't do anything about. We may want to consider not doing this. > Duplicate attached artifacts should not be allowed. > --- > > Key: MNG-3119 > URL: http://jira.codehaus.org/browse/MNG-3119 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.7 >Reporter: Paul Gier >Assignee: John Casey > Fix For: 2.0.9, 2.1-alpha-1 > > Attachments: build.log, MNG-3119-maven-project-r558713.patch > > > Currently, a project allows duplicate artifacts to be attached. This causes > the second and other additional artifacts to overwrite the first attached > artifact. This occurs during the package, install, and deploy phases. > This can be reproduced by adding three instances of the source plugin (with > different ids) to a project build configuration. The 2nd plugin will > overwrite the first, and the third will overwrite the second. > The desired behaviour is that the user should receive a warning or error when > this happens. -- 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-3119) Duplicate attached artifacts should not be allowed.
[ http://jira.codehaus.org/browse/MNG-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128825#action_128825 ] Paul Gier commented on MNG-3119: I don't have a problem with the changes from this being reverted and rescheduling this for a future release, since IMO it's a relatively low priority issue. The idea was just to warn the user in case a plugin attaches an artifact with the same name as an existing attached artifact and overwriting it. > Duplicate attached artifacts should not be allowed. > --- > > Key: MNG-3119 > URL: http://jira.codehaus.org/browse/MNG-3119 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.7 >Reporter: Paul Gier >Assignee: John Casey > Fix For: 2.0.9, 2.1-alpha-1 > > Attachments: build.log, MNG-3119-maven-project-r558713.patch > > > Currently, a project allows duplicate artifacts to be attached. This causes > the second and other additional artifacts to overwrite the first attached > artifact. This occurs during the package, install, and deploy phases. > This can be reproduced by adding three instances of the source plugin (with > different ids) to a project build configuration. The 2nd plugin will > overwrite the first, and the third will overwrite the second. > The desired behaviour is that the user should receive a warning or error when > this happens. -- 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-3484) INT_MAVEN_OPTS are not quoted in mvnDebug which causes issues on some shells
INT_MAVEN_OPTS are not quoted in mvnDebug which causes issues on some shells Key: MNG-3484 URL: http://jira.codehaus.org/browse/MNG-3484 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.8 Reporter: James William Dumay Attachments: maven-2.0.9-fix-quotes-for-leopard.patch INT_MAVEN_OPTS are not quoted in mvnDebug which causes issues on some shells I ran into this problem for 2.0.8 on Leopard. -- 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-3119) Duplicate attached artifacts should not be allowed.
[
http://jira.codehaus.org/browse/MNG-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128827#action_128827
]
Sejal Patel commented on MNG-3119:
--
Not sure what the heck is happening here but it seems related to this issue. I
just tried to do a release with maven 2.0.9RC3. The goals defined for a release
are
source:jar deploy site site:deploy
emarketing-changes:announcement-mail
However, it looks like it is breaking during the source:jar portion of the
release:perform process.
Here is the snippet from the console
[INFO] [source:jar {execution: attach-sources}]
[INFO] Building jar:
/home/sepatel/workspace/webflow-utils/target/checkout/target/webflow-utils-0.3-sources.jar
[WARNING] Duplicate artifact attachment detected. (project:
com.turner.emarketing.webflow:webflow-utils:jar:0.3; illegal attachment:
com.turner.emarketing.webflow:webflow-utils:java-source:sources:0.3)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error attaching artifact to project: Duplicate attachment.
Embedded error: Duplicate artifact attachment detected. (project:
com.turner.emarketing.webflow:webflow-utils:jar:0.3; illegal attachment:
com.turner.emarketing.webflow:webflow-utils:java-source:sources:0.3)
> Duplicate attached artifacts should not be allowed.
> ---
>
> Key: MNG-3119
> URL: http://jira.codehaus.org/browse/MNG-3119
> Project: Maven 2
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.0.7
>Reporter: Paul Gier
>Assignee: John Casey
> Fix For: 2.0.9, 2.1-alpha-1
>
> Attachments: build.log, MNG-3119-maven-project-r558713.patch
>
>
> Currently, a project allows duplicate artifacts to be attached. This causes
> the second and other additional artifacts to overwrite the first attached
> artifact. This occurs during the package, install, and deploy phases.
> This can be reproduced by adding three instances of the source plugin (with
> different ids) to a project build configuration. The 2nd plugin will
> overwrite the first, and the third will overwrite the second.
> The desired behaviour is that the user should receive a warning or error when
> this happens.
--
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-3484) INT_MAVEN_OPTS are not quoted in mvnDebug which causes issues on some shells
[ http://jira.codehaus.org/browse/MNG-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3484. -- Assignee: Brian Fox Resolution: Fixed Fix Version/s: 2.0.9 > INT_MAVEN_OPTS are not quoted in mvnDebug which causes issues on some shells > > > Key: MNG-3484 > URL: http://jira.codehaus.org/browse/MNG-3484 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.8 >Reporter: James William Dumay >Assignee: Brian Fox > Fix For: 2.0.9 > > Attachments: maven-2.0.9-fix-quotes-for-leopard.patch > > > INT_MAVEN_OPTS are not quoted in mvnDebug which causes issues on some shells > I ran into this problem for 2.0.8 on Leopard. -- 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-3119) Duplicate attached artifacts should not be allowed.
[ http://jira.codehaus.org/browse/MNG-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128828#action_128828 ] Brian Fox commented on MNG-3119: I'll revert then and we can rethink this. The forked lifecycle must be dealt with before we can do this accurately. If we can detect multiple duplicate attachments from the same lifecycle, then that's probably bad...which is what you meant. But if a build forks and repeats the same thing, well there's not much to be done about that in 2.0.x i think. > Duplicate attached artifacts should not be allowed. > --- > > Key: MNG-3119 > URL: http://jira.codehaus.org/browse/MNG-3119 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.7 >Reporter: Paul Gier >Assignee: John Casey > Fix For: 2.0.9, 2.1-alpha-1 > > Attachments: build.log, MNG-3119-maven-project-r558713.patch > > > Currently, a project allows duplicate artifacts to be attached. This causes > the second and other additional artifacts to overwrite the first attached > artifact. This occurs during the package, install, and deploy phases. > This can be reproduced by adding three instances of the source plugin (with > different ids) to a project build configuration. The 2nd plugin will > overwrite the first, and the third will overwrite the second. > The desired behaviour is that the user should receive a warning or error when > this happens. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3119) Duplicate attached artifacts should not be allowed.
[ http://jira.codehaus.org/browse/MNG-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3119: --- Fix Version/s: (was: 2.0.9) reverted from 2.0.9 > Duplicate attached artifacts should not be allowed. > --- > > Key: MNG-3119 > URL: http://jira.codehaus.org/browse/MNG-3119 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.7 >Reporter: Paul Gier >Assignee: John Casey > Fix For: 2.1-alpha-1 > > Attachments: build.log, MNG-3119-maven-project-r558713.patch > > > Currently, a project allows duplicate artifacts to be attached. This causes > the second and other additional artifacts to overwrite the first attached > artifact. This occurs during the package, install, and deploy phases. > This can be reproduced by adding three instances of the source plugin (with > different ids) to a project build configuration. The 2nd plugin will > overwrite the first, and the third will overwrite the second. > The desired behaviour is that the user should receive a warning or error when > this happens. -- 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: (MECLIPSE-411) manifest property usage is only for ogsi maifests
[ http://jira.codehaus.org/browse/MECLIPSE-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MECLIPSE-411. Resolution: Fixed Patch applied. thx. Sorry for the inconvenience. I deployed a new SNAPSHOT : 2.5.1-20080326.235643-1 > manifest property usage is only for ogsi maifests > - > > Key: MECLIPSE-411 > URL: http://jira.codehaus.org/browse/MECLIPSE-411 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: OSGi, Manifest, WTP support >Affects Versions: 2.5 > Environment: any >Reporter: Richard van Nieuwenhoven >Assignee: Arnaud Heritier > Fix For: 2.5.1 > > Attachments: manifest.patch > > > the manifest property of the eclipse plugin is only for the osgi writer and > not for the wtp manifest, because the wtp manifest is a special case that > will not be included in the maven build just in the eclipse classpath. The > problem is that the property has a default value and by that deacivates the > WTP classpath! > included a patch for the 2.5 release, including some renaming so it won't > happen again. > please release a 2.5.1 version with this 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] Created: (MAVENUPLOAD-1985) JetS3t 0.6.0
JetS3t 0.6.0 Key: MAVENUPLOAD-1985 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1985 Project: maven-upload-requests Issue Type: Wish Reporter: James Murty http://jets3t.s3.amazonaws.com/jets3t-0.6.0-repository-submission.jar http://jets3t.s3.amazonaws.com/index.html http://jets3t.s3.amazonaws.com/support.html Please add the latest release of JetS3t (0.6.0) to the public repository. I am James Murty, the developer and project owner of JetS3t. I can be contacted via [EMAIL PROTECTED] (the email address listed in an obfuscated form in the support page http://jets3t.s3.amazonaws.com/support.html) Thanks! -- 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
