[jira] Commented: (MJAR-41) Cannot specify additional classpath entries in jar manifest when using addClasspath
[ http://jira.codehaus.org/browse/MJAR-41?page=comments#action_71897 ] Fredrik Vraalsen commented on MJAR-41: -- This has now been fixed in maven-archiver 2.2-SNAPSHOT, so the dependencies in maven-jar-plugin should be updated accordingly. Cannot specify additional classpath entries in jar manifest when using addClasspath --- Key: MJAR-41 URL: http://jira.codehaus.org/browse/MJAR-41 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.0, 2.1 Environment: Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK 1.5.0_06, Windows XP Reporter: Fredrik Vraalsen The plugin configuration snippet below leads to the generation of an illegal jar manifest file, as it contains two Class-Path entries. This works in Maven 1.1b2 by adding the following to project.properties: maven.jar.manifest.classpath.add=true maven.jar.classpath=help/ resources/ For more information, please see http://www.nabble.com/classpath-in-jar-manifest-t1582724.html plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest addClasspathtrue/addClasspath /manifest manifestEntries Class-Pathhelp/ resources//Class-Path /manifestEntries /archive /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAR-41) Cannot specify additional classpath entries in jar manifest when using addClasspath
[ http://jira.codehaus.org/browse/MJAR-41?page=all ] Fredrik Vraalsen updated MJAR-41: - Attachment: MJAR-41.patch patch to update maven-archiver dependency to 2.2-SNAPSHOT Cannot specify additional classpath entries in jar manifest when using addClasspath --- Key: MJAR-41 URL: http://jira.codehaus.org/browse/MJAR-41 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.0, 2.1 Environment: Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK 1.5.0_06, Windows XP Reporter: Fredrik Vraalsen Attachments: MJAR-41.patch The plugin configuration snippet below leads to the generation of an illegal jar manifest file, as it contains two Class-Path entries. This works in Maven 1.1b2 by adding the following to project.properties: maven.jar.manifest.classpath.add=true maven.jar.classpath=help/ resources/ For more information, please see http://www.nabble.com/classpath-in-jar-manifest-t1582724.html plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest addClasspathtrue/addClasspath /manifest manifestEntries Class-Pathhelp/ resources//Class-Path /manifestEntries /archive /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2284) Cannot specify additional classpath entries in manifest when using addClasspath
[ http://jira.codehaus.org/browse/MNG-2284?page=all ] Fredrik Vraalsen updated MNG-2284: -- Attachment: MNG-2284-fix-addClasspath-and-user-specified-classpath-2.patch Cannot specify additional classpath entries in manifest when using addClasspath --- Key: MNG-2284 URL: http://jira.codehaus.org/browse/MNG-2284 Project: Maven 2 Type: Bug Components: maven-archiver Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4 Environment: Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK 1.5.0_06, Windows XP Reporter: Fredrik Vraalsen Assignee: Mike Perham Fix For: 2.0.5 Attachments: MNG-2284-addClasspath-and-user-specified-classpath.patch, MNG-2284-fix-addClasspath-and-user-specified-classpath-2.patch, MNG-archiver-classpath.patch, pom.xml When using addClasspath, e.g. in the maven-jar-plugin, it is not possible to add additional classpath entries using manifestEntries, as this generates an illegal manifest file (contains two Class-Path entries). Please see http://jira.codehaus.org/browse/MJAR-41 I have been looking through the code, and it seems this might need to be resolved in MavenArchiver? I've attached a simple fix that solves the problem for me, but a more thorough solution might be needed of course. ;-) -- 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-2426) Artifact copied to local repository with wrong file extension when using jboss-packaging plugin
Artifact copied to local repository with wrong file extension when using jboss-packaging plugin --- Key: MNG-2426 URL: http://jira.codehaus.org/browse/MNG-2426 Project: Maven 2 Type: Bug Components: Artifacts and Repositories, Artifacts Versions: 2.0.4 Environment: jdk 1.5.0_06, maven 2.0.4, jboss-package-maven-plugin 2.0-SNAPSHOT (from mojo-sandbox SVN r2088) Reporter: Fredrik Vraalsen When using the jboss-packaging plugin and setting packaging to jboss-sar in my pom, the artifact is copied into the local repository with the wrong file extension (.jboss-sar instead of .sar). The jboss-packaging components.xml has extension set to sar. The file in the build target directory has the correct .sar extension. Here's the relevant excerpt from my pom.xml: packagingjboss-sar/packaging ... build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId version2.0-SNAPSHOT/version extensionstrue/extensions ... -- 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-2284) Cannot specify additional classpath entries in manifest when using addClasspath
[ http://jira.codehaus.org/browse/MNG-2284?page=all ] Fredrik Vraalsen reopened MNG-2284: --- see previous comment Cannot specify additional classpath entries in manifest when using addClasspath --- Key: MNG-2284 URL: http://jira.codehaus.org/browse/MNG-2284 Project: Maven 2 Type: Bug Components: maven-archiver Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4 Environment: Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK 1.5.0_06, Windows XP Reporter: Fredrik Vraalsen Assignee: Mike Perham Fix For: 2.0.5 Attachments: MNG-archiver-classpath.patch When using addClasspath, e.g. in the maven-jar-plugin, it is not possible to add additional classpath entries using manifestEntries, as this generates an illegal manifest file (contains two Class-Path entries). Please see http://jira.codehaus.org/browse/MJAR-41 I have been looking through the code, and it seems this might need to be resolved in MavenArchiver? I've attached a simple fix that solves the problem for me, but a more thorough solution might be needed of course. ;-) -- 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-2284) Cannot specify additional classpath entries in manifest when using addClasspath
[ http://jira.codehaus.org/browse/MNG-2284?page=comments#action_69265 ] Fredrik Vraalsen commented on MNG-2284: --- Hi, I'm still having problems with this, but of a different sort now. If I have a configuration such as the following: manifest addClasspathtrue/addClasspath /manifest manifestEntries Class-Pathresources//Class-Path /manifestEntries I now get the following in my manifest.mf: Class-Path: resources/ Class-Path: resources/ In other words, still two Class-Path entries in the manifest file, only this time they both have the value 'resources/', and the classpath created by addClasspath is gone. This is with latest maven-jar-plugin 2.1-SNAPSHOT (maven-archiver 2.1). I'm trying to create a JUnit test-case for maven-archiver, but I'm still trying to work out the details of how to set this up. ;-) In the meanwhile, I'll attach a simple stand-alone pom file which shows the problem. Cannot specify additional classpath entries in manifest when using addClasspath --- Key: MNG-2284 URL: http://jira.codehaus.org/browse/MNG-2284 Project: Maven 2 Type: Bug Components: maven-archiver Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4 Environment: Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK 1.5.0_06, Windows XP Reporter: Fredrik Vraalsen Assignee: Mike Perham Fix For: 2.0.5 Attachments: MNG-archiver-classpath.patch When using addClasspath, e.g. in the maven-jar-plugin, it is not possible to add additional classpath entries using manifestEntries, as this generates an illegal manifest file (contains two Class-Path entries). Please see http://jira.codehaus.org/browse/MJAR-41 I have been looking through the code, and it seems this might need to be resolved in MavenArchiver? I've attached a simple fix that solves the problem for me, but a more thorough solution might be needed of course. ;-) -- 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-2284) Cannot specify additional classpath entries in manifest when using addClasspath
[ http://jira.codehaus.org/browse/MNG-2284?page=all ] Fredrik Vraalsen updated MNG-2284: -- Attachment: pom.xml Cannot specify additional classpath entries in manifest when using addClasspath --- Key: MNG-2284 URL: http://jira.codehaus.org/browse/MNG-2284 Project: Maven 2 Type: Bug Components: maven-archiver Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4 Environment: Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK 1.5.0_06, Windows XP Reporter: Fredrik Vraalsen Assignee: Mike Perham Fix For: 2.0.5 Attachments: MNG-archiver-classpath.patch, pom.xml When using addClasspath, e.g. in the maven-jar-plugin, it is not possible to add additional classpath entries using manifestEntries, as this generates an illegal manifest file (contains two Class-Path entries). Please see http://jira.codehaus.org/browse/MJAR-41 I have been looking through the code, and it seems this might need to be resolved in MavenArchiver? I've attached a simple fix that solves the problem for me, but a more thorough solution might be needed of course. ;-) -- 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: (MEJB-13) Add support for configuring exclusion filter for main ejb jar
[ http://jira.codehaus.org/browse/MEJB-13?page=all ] Fredrik Vraalsen updated MEJB-13: - Attachment: maven-ejb-plugin-configure-main-jar-excludes.patch Add support for configuring exclusion filter for main ejb jar - Key: MEJB-13 URL: http://jira.codehaus.org/browse/MEJB-13 Project: Maven 2.x Ejb Plugin Type: New Feature Versions: 2.1, 2.0 Environment: Maven 2.0.4, maven-ejb-plugin 2.1-SNAPSHOT, JBoss 4.0.3sp1 Reporter: Fredrik Vraalsen Attachments: MEJB-configure-excludes.patch, maven-ejb-plugin-configure-main-jar-excludes.patch In my ejb project I have certain files that must only be included in the ejb-client jar and not the main ejb jar (jboss-client.xml, application-client.xml and jndi.properties). When these files are present in the main ejb jar, JBoss refuses to deploy my ejbs. Thus, I need a way to configure the exclusion filter for the main ejb jar. This is currently hardcoded in EjbMojo.java. I am attaching a patch to make this configurable in the same way as clientExcludes. Below is an example of the kind of configuration I am using: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ejb-plugin/artifactId version2.1-SNAPSHOT/version configuration excludes excludejndi.properties/exclude excludeMETA-INF/*-client.xml/exclude exclude**/interfaces//exclude exclude**/assetrepository/Asset.class/exclude /excludes generateClienttrue/generateClient clientExcludes clientExcludeMETA-INF/ejb-jar.xml/clientExclude clientExcludeMETA-INF/jboss.xml/clientExclude clientExclude**/dao//clientExclude clientExclude**/entity//clientExclude clientExclude**/jaxb//clientExclude clientExclude**/session//clientExclude clientExclude**/xmldb//clientExclude /clientExcludes /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEJB-13) Add support for configuring exclusion filter for main ejb jar
[ http://jira.codehaus.org/browse/MEJB-13?page=all ] Fredrik Vraalsen updated MEJB-13: - Attachment: maven-ejb-plugin-configure-main-jar-excludes-2.patch Add support for configuring exclusion filter for main ejb jar - Key: MEJB-13 URL: http://jira.codehaus.org/browse/MEJB-13 Project: Maven 2.x Ejb Plugin Type: New Feature Versions: 2.1, 2.0 Environment: Maven 2.0.4, maven-ejb-plugin 2.1-SNAPSHOT, JBoss 4.0.3sp1 Reporter: Fredrik Vraalsen Attachments: MEJB-configure-excludes.patch, maven-ejb-plugin-configure-main-jar-excludes-2.patch, maven-ejb-plugin-configure-main-jar-excludes.patch In my ejb project I have certain files that must only be included in the ejb-client jar and not the main ejb jar (jboss-client.xml, application-client.xml and jndi.properties). When these files are present in the main ejb jar, JBoss refuses to deploy my ejbs. Thus, I need a way to configure the exclusion filter for the main ejb jar. This is currently hardcoded in EjbMojo.java. I am attaching a patch to make this configurable in the same way as clientExcludes. Below is an example of the kind of configuration I am using: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ejb-plugin/artifactId version2.1-SNAPSHOT/version configuration excludes excludejndi.properties/exclude excludeMETA-INF/*-client.xml/exclude exclude**/interfaces//exclude exclude**/assetrepository/Asset.class/exclude /excludes generateClienttrue/generateClient clientExcludes clientExcludeMETA-INF/ejb-jar.xml/clientExclude clientExcludeMETA-INF/jboss.xml/clientExclude clientExclude**/dao//clientExclude clientExclude**/entity//clientExclude clientExclude**/jaxb//clientExclude clientExclude**/session//clientExclude clientExclude**/xmldb//clientExclude /clientExcludes /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-7) [dependency-maven-plugin] ClassCastException caused by DefaultArtifact vs. ActiveProjectArtifact
[ http://jira.codehaus.org/browse/MDEP-7?page=comments#action_69055 ] Fredrik Vraalsen commented on MDEP-7: - I'm also seeing this problem in the 2.0-SNAPSHOT version of the maven-dependency-plugin during a multiproject build. The patch already attached to this issue fixes the problem for me. [dependency-maven-plugin] ClassCastException caused by DefaultArtifact vs. ActiveProjectArtifact Key: MDEP-7 URL: http://jira.codehaus.org/browse/MDEP-7 Project: Maven 2.x Dependency Plugin Type: Bug Reporter: Christian Schulte Assignee: Brian Fox Priority: Trivial Attachments: ActiveProjectArtifact.patch I reproducible got a ClassCastException during copy-dependencies goal. There is a cast to DefaultArtifact which fails if the actual instance is ActiveProjectArtifact which does not extend DefaultArtifact. After patching the plugin and trying the old version again to verify reproducibility the exception magically never appeared again so I cannot reproduce the stacktrace somehow. However, the cast to DefaultArtifact can be changed to Artifact, I think. -- 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-979) Please upload jgraph 5.8.3.1
Please upload jgraph 5.8.3.1 Key: MAVENUPLOAD-979 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-979 Project: maven-upload-requests Type: Task Reporter: Fredrik Vraalsen http://www.jgraph.com/ http://sourceforge.net/projects/jgraph/ JGraph is a Graph Visualization and Layout library licensed under the LGPL. The newest version found on ibiblio is v.5.5.1 which was released in May 2005. The latest release on Sourceforge is 5.8.3.1 (June 21st 2006): http://sourceforge.net/project/shownotes.php?release_id=426575group_id=43118 -- 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: (MEJB-13) Add support for configuring exclusion filter for main ejb jar
[ http://jira.codehaus.org/browse/MEJB-13?page=comments#action_69121 ] Fredrik Vraalsen commented on MEJB-13: -- Trygve, Remember that the ejb plugin generates _two_ artifacts from the _same_ pom, but both artifacts should not necessarily contain the same resources. If I'm understanding you correctly, you are suggesting that the ejb plugin should be configured with two resources sections in the pom, one for the ejb jar and one for the ejb-client jar? But as far as I can tell, you can only have one resources section in the pom? The ejb plugin already contains clientExcludes/clientIncludes parameters which are used to further filter the resources to be included in the ejb-client jar. These filters are applied on top of the include and exclude filters specified in the resources section in the pom, as far as I know. What I'm asking for is a similar way to configure what should be excluded from the ejb jar, instead of accepting the default exclude filter (hardcoded in the ejb plugin). If there is a way to do this using the resources section in the pom instead, could someone please provide an example? Then it should also be possible to get rid of the clientExcludes and clientIncludes properties of the ejb plugin... Add support for configuring exclusion filter for main ejb jar - Key: MEJB-13 URL: http://jira.codehaus.org/browse/MEJB-13 Project: Maven 2.x Ejb Plugin Type: New Feature Versions: 2.1, 2.0 Environment: Maven 2.0.4, maven-ejb-plugin 2.1-SNAPSHOT, JBoss 4.0.3sp1 Reporter: Fredrik Vraalsen Attachments: MEJB-configure-excludes.patch, maven-ejb-plugin-configure-main-jar-excludes-2.patch, maven-ejb-plugin-configure-main-jar-excludes.patch In my ejb project I have certain files that must only be included in the ejb-client jar and not the main ejb jar (jboss-client.xml, application-client.xml and jndi.properties). When these files are present in the main ejb jar, JBoss refuses to deploy my ejbs. Thus, I need a way to configure the exclusion filter for the main ejb jar. This is currently hardcoded in EjbMojo.java. I am attaching a patch to make this configurable in the same way as clientExcludes. Below is an example of the kind of configuration I am using: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ejb-plugin/artifactId version2.1-SNAPSHOT/version configuration excludes excludejndi.properties/exclude excludeMETA-INF/*-client.xml/exclude exclude**/interfaces//exclude exclude**/assetrepository/Asset.class/exclude /excludes generateClienttrue/generateClient clientExcludes clientExcludeMETA-INF/ejb-jar.xml/clientExclude clientExcludeMETA-INF/jboss.xml/clientExclude clientExclude**/dao//clientExclude clientExclude**/entity//clientExclude clientExclude**/jaxb//clientExclude clientExclude**/session//clientExclude clientExclude**/xmldb//clientExclude /clientExcludes /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-41) Cannot specify additional classpath entries in jar manifest when using addClasspath
[ http://jira.codehaus.org/browse/MJAR-41?page=comments#action_67156 ] Fredrik Vraalsen commented on MJAR-41: -- It seems the spec and the implementation are not quite in agreement, unfortunately. I've tested with multiple Class-Path entries in the manifest file, and this does not seem to work with JDK 1.5.0 update 6 on Windows XP at least. It gives the following output: $ java -jar test.jar 12.jun.2006 11:48:10 java.util.jar.Attributes read WARNING: Duplicate name in Manifest: Class-Path 12.jun.2006 11:48:10 java.util.jar.Attributes read WARNING: Duplicate name in Manifest: Class-Path and then I get a NoClassDefFoundError on one of the classes from the first Class-Path entry. $ java -version java version 1.5.0_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode) Cannot specify additional classpath entries in jar manifest when using addClasspath --- Key: MJAR-41 URL: http://jira.codehaus.org/browse/MJAR-41 Project: Maven 2.x Jar Plugin Type: Bug Versions: 2.1, 2.0 Environment: Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK 1.5.0_06, Windows XP Reporter: Fredrik Vraalsen The plugin configuration snippet below leads to the generation of an illegal jar manifest file, as it contains two Class-Path entries. This works in Maven 1.1b2 by adding the following to project.properties: maven.jar.manifest.classpath.add=true maven.jar.classpath=help/ resources/ For more information, please see http://www.nabble.com/classpath-in-jar-manifest-t1582724.html plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest addClasspathtrue/addClasspath /manifest manifestEntries Class-Pathhelp/ resources//Class-Path /manifestEntries /archive /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTRUN-37) Antrun breaks on multi-module builds
[ http://jira.codehaus.org/browse/MANTRUN-37?page=comments#action_65181 ]
Fredrik Vraalsen commented on MANTRUN-37:
-
I'm also seeing this problem with maven 2.0.4 and antrun 1.1 in a multiproject
build. Environment is JDK 1.5.0_06, Windows XP.
The submodule build crashes with the same type of error message as in the
original bug description. The build works however if I explicitly specify
version 1.0 of the antrun in the plugin in the pom, as Mike Pernham pointed out
in one of his comments.
I've tried disabling various subprojects and plugins, and I've finally hit a
case where I can trigger the error by enabling a single plugin: The culprit
seems to be the xdoclet plugin from mojo.codehaus.org. When this is enabled in
one of the other subprojects, the antrun 1.1 plugin fails, otherwise it runs
fine.
I've created a testcase which can be checked out using
svn co
https://svn.sourceforge.net/svnroot/coras/coras/branches/maven2-antrun-testcase/src
The module with the antrun problem is in modules/coras-help. The module using
xdoclet is in modules/asset-repository-ejb. Sorry I haven't had a chance to
create an even smaller testcase, but I figured it would be worth getting this
out there. Don't know if the problem is with the antrun or the xdoclet plugin
though.
Antrun breaks on multi-module builds
Key: MANTRUN-37
URL: http://jira.codehaus.org/browse/MANTRUN-37
Project: Maven 2.x Antrun Plugin
Type: Bug
Versions: 1.1
Environment: Maven 2.0.1
Reporter: Mike Perham
Assignee: Carlos Sanchez
Priority: Critical
I just updated to antrun v1.1 (which needs to be marked as released in jira
BTW) and find that my multimodule build is now breaking. Running the build
in the child module itself works fine but if I build the parent, it fails
when it gets to the child with the antrun task. Here's part of the debug
output. Note it says 1.1 in the dependency tree but 1.0 further down.
{noformat}
[DEBUG] org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.1
(selected for runtime)
[DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for
runtime)
[DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
[DEBUG] org.apache.maven:maven-profile:jar:2.0.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
[DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for runtime)
[DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.1 (selected for
runtime)
[DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.1 (selected
for runtime)
[DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.1 (selected for runtime)
[DEBUG] ant:ant:jar:1.6.5 (selected for runtime)
[DEBUG] ant:ant-launcher:jar:1.6.5 (selected for runtime)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
'org.apache.maven.plugins:maven-antrun-plugin'
Component descriptor cannot be found in the component repository:
org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run.
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
plugin manager executing goal
'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
'org.apache.maven.plugins:maven-antrun-plugin'
at
[jira] Created: (MANTRUN-51) Can't find plugin dependency in multiproject
Can't find plugin dependency in multiproject
Key: MANTRUN-51
URL: http://jira.codehaus.org/browse/MANTRUN-51
Project: Maven 2.x Antrun Plugin
Type: Bug
Versions: 1.0, 1.1
Environment: maven 2.0.4, antrun 1.0 1.1, jdk 1.5.0_06, windows xp
Reporter: Fredrik Vraalsen
I'm using antrun in my project to create an IzPack installation. The plugin
configuration is below.
When maven is run from the top-level project, the ant taskdef fails because it
cannot find the IzPackTask class. However, when I run maven from the
subproject itself, it works fine. Not sure if this is related to
http://jira.codehaus.org/browse/MANTRUN-49. The error message from maven is at
the bottom.
{{plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
configuration
tasks
taskdef name=izpack
classname=com.izforge.izpack.ant.IzPackTask/
izpack
input=${project.build.directory}/classes/izPack.xml
output=${project.build.directory}/CorasTool-${coras.version}-installer.jar
basedir=${project.build.directory}/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdizpack/groupId
artifactIdstandalone-compiler/artifactId
version3.8.0/version
/dependency
/dependencies
/plugin}}
{{[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: taskdef class com.izforge.izpack.ant.IzPackTask cannot be found
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant
tasks
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java: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)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error executing ant
tasks
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:77)
at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:72)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
... 16 more
Caused by: taskdef class com.izforge.izpack.ant.IzPackTask cannot be found
at org.apache.tools.ant.taskdefs.Definer.addDefinition(Definer.java:483)
at org.apache.tools.ant.taskdefs.Definer.execute(Definer.java:183)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:71)
... 19 more
Caused by:
[jira] Created: (MJAR-41) Cannot specify additional classpath entries in jar manifest when using addClasspath
Cannot specify additional classpath entries in jar manifest when using addClasspath --- Key: MJAR-41 URL: http://jira.codehaus.org/browse/MJAR-41 Project: Maven 2.x Jar Plugin Type: Bug Versions: 2.1, 2.0 Environment: Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK 1.5.0_06, Windows XP Reporter: Fredrik Vraalsen The plugin configuration snippet below leads to the generation of an illegal jar manifest file, as it contains two Class-Path entries. This works in Maven 1.1b2 by adding the following to project.properties: maven.jar.manifest.classpath.add=true maven.jar.classpath=help/ resources/ For more information, please see http://www.nabble.com/classpath-in-jar-manifest-t1582724.html plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest addClasspathtrue/addClasspath /manifest manifestEntries Class-Pathhelp/ resources//Class-Path /manifestEntries /archive /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-41) Cannot specify additional classpath entries in jar manifest when using addClasspath
[ http://jira.codehaus.org/browse/MJAR-41?page=comments#action_65018 ] Fredrik Vraalsen commented on MJAR-41: -- See http://jira.codehaus.org/browse/MNG-2284 for a simple patch that solved the issue for me. Cannot specify additional classpath entries in jar manifest when using addClasspath --- Key: MJAR-41 URL: http://jira.codehaus.org/browse/MJAR-41 Project: Maven 2.x Jar Plugin Type: Bug Versions: 2.1, 2.0 Environment: Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK 1.5.0_06, Windows XP Reporter: Fredrik Vraalsen The plugin configuration snippet below leads to the generation of an illegal jar manifest file, as it contains two Class-Path entries. This works in Maven 1.1b2 by adding the following to project.properties: maven.jar.manifest.classpath.add=true maven.jar.classpath=help/ resources/ For more information, please see http://www.nabble.com/classpath-in-jar-manifest-t1582724.html plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest addClasspathtrue/addClasspath /manifest manifestEntries Class-Pathhelp/ resources//Class-Path /manifestEntries /archive /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2258) Wrong execution order of plugins in same phase
[ http://jira.codehaus.org/browse/MNG-2258?page=comments#action_65019 ] Fredrik Vraalsen commented on MNG-2258: --- I'm having the same problem. I need to run two plugins in the generate-sources phase, where one depends on the output of the other. For more information, please see http://www.nabble.com/Plugin-execution-order-within-lifecycle-phase-t1541372.html#a4187121 Wrong execution order of plugins in same phase -- Key: MNG-2258 URL: http://jira.codehaus.org/browse/MNG-2258 Project: Maven 2 Type: Bug Versions: 2.0.4 Environment: N/A Reporter: David J. M. Karlsen AFAIK plugins should be execute in the same order as they are listed in the POM, when bound to the same phase. This does not happen, the execution order is arbitrary. -- 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
