[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 > > org.apache.maven.plugins > maven-jar-plugin > > > > true > > > help/ resources/ > > > > -- 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: > > org.apache.maven.plugins > maven-ejb-plugin > 2.1-SNAPSHOT > > > > jndi.properties > > META-INF/*-client.xml > > **/interfaces/ > > **/assetrepository/Asset.class > > true > > > META-INF/ejb-jar.xml > > META-INF/jboss.xml > > **/dao/ > > **/entity/ > > **/jaxb/ > > **/session/ > > **/xmldb/ > > > -- 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: > > org.apache.maven.plugins > maven-ejb-plugin > 2.1-SNAPSHOT > > > > jndi.properties > > META-INF/*-client.xml > > **/interfaces/ > > **/assetrepository/Asset.class > > true > > > META-INF/ejb-jar.xml > > META-INF/jboss.xml > > **/dao/ > > **/entity/ > > **/jaxb/ > > **/session/ > > **/xmldb/ > > > -- 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=426575&group_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 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 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 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 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: > > org.apache.maven.plugins > maven-ejb-plugin > 2.1-SNAPSHOT > > > > jndi.properties > > META-INF/*-client.xml > > **/interfaces/ > > **/assetrepository/Asset.class > > true > > > META-INF/ejb-jar.xml > > META-INF/jboss.xml > > **/dao/ > > **/entity/ > > **/jaxb/ > > **/session/ > > **/xmldb/ > > > -- 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_69152 ] Fredrik Vraalsen commented on MEJB-13: -- Another issue: The exclude/include filters in the ejb plugin also control which class files are put in the ejb-client jar. My other reason for wanting to be able to configure the ejb jar exludes is that there are some class files that I only want in the ejb-client jar. > 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: > > org.apache.maven.plugins > maven-ejb-plugin > 2.1-SNAPSHOT > > > > jndi.properties > > META-INF/*-client.xml > > **/interfaces/ > > **/assetrepository/Asset.class > > true > > > META-INF/ejb-jar.xml > > META-INF/jboss.xml > > **/dao/ > > **/entity/ > > **/jaxb/ > > **/session/ > > **/xmldb/ > > > -- 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 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 set to sar. The file in the build target directory has the correct .sar extension. Here's the relevant excerpt from my pom.xml: jboss-sar ... org.codehaus.mojo jboss-packaging-maven-plugin 2.0-SNAPSHOT true ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2426) Artifact copied to local repository with wrong file extension when using jboss-packaging plugin
[ http://jira.codehaus.org/browse/MNG-2426?page=comments#action_69244 ] Fredrik Vraalsen commented on MNG-2426: --- Also reported as http://jira.codehaus.org/browse/MOJO-449 Related to http://jira.codehaus.org/browse/MNG-2240 ? > 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 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 set to sar. The file in the build target directory has the > correct .sar extension. > Here's the relevant excerpt from my pom.xml: > jboss-sar > ... > > > > org.codehaus.mojo > jboss-packaging-maven-plugin > 2.0-SNAPSHOT > true > ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] 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: true resources/ 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: (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-addClasspath-and-user-specified-classpath.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-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: (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] 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 > > org.apache.maven.plugins > maven-jar-plugin > > > > true > > > help/ resources/ > > > > -- 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 > > org.apache.maven.plugins > maven-jar-plugin > > > > true > > > help/ resources/ > > > > -- 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: (MEJB-13) Add support for configuring exclusion filter for main ejb jar
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 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: org.apache.maven.plugins maven-ejb-plugin 2.1-SNAPSHOT jndi.properties META-INF/*-client.xml **/interfaces/ **/assetrepository/Asset.class true META-INF/ejb-jar.xml META-INF/jboss.xml **/dao/ **/entity/ **/jaxb/ **/session/ **/xmldb/ -- 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: (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 org.apache.maven.plugins maven-jar-plugin true help/ resources/ -- 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-2284) Cannot specify additional classpath entries in manifest when using addClasspath
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 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: (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 > > org.apache.maven.plugins > maven-jar-plugin > > > > true > > > help/ resources/ > > > > -- 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
[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
[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.
{{
org.apache.maven.plugins
maven-antrun-plugin
package
run
izpack
standalone-compiler
3.8.0
}}
{{[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: java.lang.ClassNotFoundException: com.izforge.izpack.ant.IzPackTask
at
org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1166)
at
org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1107)
at
org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:977)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName
