[jira] Commented: (MEJB-16) clientExcludes generates empty packages i client-jar
[ http://jira.codehaus.org/browse/MEJB-16?page=comments#action_67096 ] Anders Kr. Andersen commented on MEJB-16: - Maybe it is because I come from Maven1 and tries to exclude. I just tried to include instead.. It leaves no empty packages. Is it a better solution to include what to be in the client-jar? And not exclude what to avoid? > clientExcludes generates empty packages i client-jar > > > Key: MEJB-16 > URL: http://jira.codehaus.org/browse/MEJB-16 > Project: Maven 2.x Ejb Plugin > Type: Bug > Versions: 2.0 > Environment: Discovered on MAC OSX, but I dont think it is OS dependent > Reporter: Anders Kr. Andersen > Priority: Minor > > > When I use the ... the excluded packages are still package > in the jar. But empty. > The bigggest problem is probably the visual testing the developer is doing. > Seeing that packages remanis in the jar ... and discovering that they are > empty simple just takes a little time. > I don't think the JVM have any problem with this ? > But I don't think it is in the JAR specification either :-) -- 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-38) Maven Puts Arbitrary Extension Definition in JAR Manifest by Default.
[ http://jira.codehaus.org/browse/MJAR-38?page=all ] Mike Perham updated MJAR-38: Attachment: (was: MavenArchiver.patch.1) > Maven Puts Arbitrary Extension Definition in JAR Manifest by Default. > - > > Key: MJAR-38 > URL: http://jira.codehaus.org/browse/MJAR-38 > Project: Maven 2.x Jar Plugin > Type: Bug > Versions: 2.0 > Environment: Maven version: 2.0.4 > Microsoft Windows XP [Version 5.1.2600] > Reporter: Steven Coco > Assignee: Mike Perham > Attachments: Jar Extension-Name Tester.zip > > > I'm using the latest Maven release. When I build my project, the > resulting Jar file's manifest contains an Extension-Name attribute along with > Specification and Implementation attributes. The POM contains no mention > that this project is a Java optional package -- an "extension" (or an > extension of any other kind). > I don't know why Maven is doing that. > If Maven is doing this by default for some reason, it absolutely > shouldn't. Maven should not identify my Jar as an optional package unless I > explicitly say so. Jars are only extensions if explicitly created as such. > The name it uses for the extension name is the POM's . > That's not even a UID! -- 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-38) Maven Puts Arbitrary Extension Definition in JAR Manifest by Default.
[ http://jira.codehaus.org/browse/MJAR-38?page=all ] Mike Perham updated MJAR-38: Attachment: (was: MavenArchiver.patch.2) > Maven Puts Arbitrary Extension Definition in JAR Manifest by Default. > - > > Key: MJAR-38 > URL: http://jira.codehaus.org/browse/MJAR-38 > Project: Maven 2.x Jar Plugin > Type: Bug > Versions: 2.0 > Environment: Maven version: 2.0.4 > Microsoft Windows XP [Version 5.1.2600] > Reporter: Steven Coco > Assignee: Mike Perham > Attachments: Jar Extension-Name Tester.zip > > > I'm using the latest Maven release. When I build my project, the > resulting Jar file's manifest contains an Extension-Name attribute along with > Specification and Implementation attributes. The POM contains no mention > that this project is a Java optional package -- an "extension" (or an > extension of any other kind). > I don't know why Maven is doing that. > If Maven is doing this by default for some reason, it absolutely > shouldn't. Maven should not identify my Jar as an optional package unless I > explicitly say so. Jars are only extensions if explicitly created as such. > The name it uses for the extension name is the POM's . > That's not even a UID! -- 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-38) Maven Puts Arbitrary Extension Definition in JAR Manifest by Default.
[ http://jira.codehaus.org/browse/MJAR-38?page=all ] Mike Perham updated MJAR-38: Attachment: (was: MavenArchiver.patch.1) > Maven Puts Arbitrary Extension Definition in JAR Manifest by Default. > - > > Key: MJAR-38 > URL: http://jira.codehaus.org/browse/MJAR-38 > Project: Maven 2.x Jar Plugin > Type: Bug > Versions: 2.0 > Environment: Maven version: 2.0.4 > Microsoft Windows XP [Version 5.1.2600] > Reporter: Steven Coco > Assignee: Mike Perham > Attachments: Jar Extension-Name Tester.zip > > > I'm using the latest Maven release. When I build my project, the > resulting Jar file's manifest contains an Extension-Name attribute along with > Specification and Implementation attributes. The POM contains no mention > that this project is a Java optional package -- an "extension" (or an > extension of any other kind). > I don't know why Maven is doing that. > If Maven is doing this by default for some reason, it absolutely > shouldn't. Maven should not identify my Jar as an optional package unless I > explicitly say so. Jars are only extensions if explicitly created as such. > The name it uses for the extension name is the POM's . > That's not even a UID! -- 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-38) Maven Puts Arbitrary Extension Definition in JAR Manifest by Default.
[ http://jira.codehaus.org/browse/MJAR-38?page=all ] Mike Perham updated MJAR-38: Attachment: (was: MJAR-38.patch) > Maven Puts Arbitrary Extension Definition in JAR Manifest by Default. > - > > Key: MJAR-38 > URL: http://jira.codehaus.org/browse/MJAR-38 > Project: Maven 2.x Jar Plugin > Type: Bug > Versions: 2.0 > Environment: Maven version: 2.0.4 > Microsoft Windows XP [Version 5.1.2600] > Reporter: Steven Coco > Assignee: Mike Perham > Attachments: Jar Extension-Name Tester.zip > > > I'm using the latest Maven release. When I build my project, the > resulting Jar file's manifest contains an Extension-Name attribute along with > Specification and Implementation attributes. The POM contains no mention > that this project is a Java optional package -- an "extension" (or an > extension of any other kind). > I don't know why Maven is doing that. > If Maven is doing this by default for some reason, it absolutely > shouldn't. Maven should not identify my Jar as an optional package unless I > explicitly say so. Jars are only extensions if explicitly created as such. > The name it uses for the extension name is the POM's . > That's not even a UID! -- 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-38) Maven Puts Arbitrary Extension Definition in JAR Manifest by Default.
[ http://jira.codehaus.org/browse/MJAR-38?page=all ] Mike Perham updated MJAR-38: Attachment: (was: MavenArchiver.patch.3) > Maven Puts Arbitrary Extension Definition in JAR Manifest by Default. > - > > Key: MJAR-38 > URL: http://jira.codehaus.org/browse/MJAR-38 > Project: Maven 2.x Jar Plugin > Type: Bug > Versions: 2.0 > Environment: Maven version: 2.0.4 > Microsoft Windows XP [Version 5.1.2600] > Reporter: Steven Coco > Assignee: Mike Perham > Attachments: Jar Extension-Name Tester.zip > > > I'm using the latest Maven release. When I build my project, the > resulting Jar file's manifest contains an Extension-Name attribute along with > Specification and Implementation attributes. The POM contains no mention > that this project is a Java optional package -- an "extension" (or an > extension of any other kind). > I don't know why Maven is doing that. > If Maven is doing this by default for some reason, it absolutely > shouldn't. Maven should not identify my Jar as an optional package unless I > explicitly say so. Jars are only extensions if explicitly created as such. > The name it uses for the extension name is the POM's . > That's not even a UID! -- 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-38) Maven Puts Arbitrary Extension Definition in JAR Manifest by Default.
[ http://jira.codehaus.org/browse/MJAR-38?page=all ] Mike Perham updated MJAR-38: Attachment: MJAR-38.patch > Maven Puts Arbitrary Extension Definition in JAR Manifest by Default. > - > > Key: MJAR-38 > URL: http://jira.codehaus.org/browse/MJAR-38 > Project: Maven 2.x Jar Plugin > Type: Bug > Versions: 2.0 > Environment: Maven version: 2.0.4 > Microsoft Windows XP [Version 5.1.2600] > Reporter: Steven Coco > Assignee: Mike Perham > Attachments: Jar Extension-Name Tester.zip, MJAR-38.patch > > > I'm using the latest Maven release. When I build my project, the > resulting Jar file's manifest contains an Extension-Name attribute along with > Specification and Implementation attributes. The POM contains no mention > that this project is a Java optional package -- an "extension" (or an > extension of any other kind). > I don't know why Maven is doing that. > If Maven is doing this by default for some reason, it absolutely > shouldn't. Maven should not identify my Jar as an optional package unless I > explicitly say so. Jars are only extensions if explicitly created as such. > The name it uses for the extension name is the POM's . > That's not even a UID! -- 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: (MPA-23) create an internal repository managers discussion list @maven.org
[ http://jira.codehaus.org/browse/MPA-23?page=all ] Jason van Zyl closed MPA-23: Resolution: Fixed List has been created. > create an internal repository managers discussion list @maven.org > - > > Key: MPA-23 > URL: http://jira.codehaus.org/browse/MPA-23 > Project: Maven Project Administration > Type: Task > Components: repository management > Reporter: Brett Porter > Assignee: Jason van Zyl > Fix For: 2006-q1 > > > we have [EMAIL PROTECTED] for sync partners, but we don't have anything we > can send the scm commits or have other repo maintenance discussion on. -- 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: (MSUREFIRE-133) Working directory is not setup correctly when running a unit test in the child subproject if run from the parent's directory
Working directory is not setup correctly when running a unit test in the child subproject if run from the parent's directory Key: MSUREFIRE-133 URL: http://jira.codehaus.org/browse/MSUREFIRE-133 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.3 Environment: Windows XP with cygwin or Ubuntu Linux or MacOSX 10.4.6 Java 1.5, maven 2.0.4 Reporter: toli kuznets Attachments: pathBug.tar Current working directory is not setup correctly when you run all the unit tests of the child module from the parent directory. Create a maven parent project that only contains a child subproject with one unit test, which tries to open/create a file in the relative subdirectory of the current directory. When you run the test directly from the pathBugh/subproject/ directory, then the test passes just fine. If you run the test from the parent project directory, the test fails (cur. working directory is not setup correctly). If, however, the target directory already exists in child module, then everything works. Reproduction: 1. open the tarball 2. run 'mvn test' from the parent directory - unit test will fail 3. you can run 'mvn test' from child project it should pass. remember to delete the "output" directories after you successfully run the test in the child subdir. I've noticed that this bug only happens when the "releases" of Maven plugins is enabled in the parent POM (see the parent POM file for the truth table of what's necessary to get the test to fail). so it may be a failure that only happens in current plugin version. there's a mvn.out file in the attached tarball that has the debug information (-X) for the output of the maven test run. This only happens under maven. When you run the same unit test with ant or IntelliJ it works fine. See the attached tarball. note: the actual error may be in any other maven plugin, but i have a feeling it's in the surefire/unit test setup. -- 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: (MSUREFIRE-133) Working directory is not setup correctly when running a unit test in the child subproject if run from the parent's directory
[ http://jira.codehaus.org/browse/MSUREFIRE-133?page=comments#action_67110 ] Dan Tran commented on MSUREFIRE-133: Please try maven-surefire-plugin-2.2. There are lots of bug fixes since 2.13-SNAPShOT > Working directory is not setup correctly when running a unit test in the > child subproject if run from the parent's directory > > > Key: MSUREFIRE-133 > URL: http://jira.codehaus.org/browse/MSUREFIRE-133 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.1.3 > Environment: Windows XP with cygwin or Ubuntu Linux or MacOSX 10.4.6 > Java 1.5, maven 2.0.4 > Reporter: toli kuznets > Attachments: pathBug.tar > > > Current working directory is not setup correctly when you run all the unit > tests of the child module from the parent directory. > Create a maven parent project that only contains a child subproject with one > unit test, which tries to open/create a file in the relative subdirectory of > the current directory. > When you run the test directly from the pathBugh/subproject/ directory, then > the test passes just fine. > If you run the test from the parent project directory, the test fails (cur. > working directory is not setup correctly). > If, however, the target directory already exists in child module, then > everything works. > Reproduction: > 1. open the tarball > 2. run 'mvn test' from the parent directory - unit test will fail > 3. you can run 'mvn test' from child project it should pass. remember to > delete the "output" directories after you successfully run the test in the > child subdir. > I've noticed that this bug only happens when the "releases" of Maven plugins > is enabled in the parent POM (see the parent POM file for the truth table of > what's necessary to get the test to fail). so it may be a failure that only > happens in current plugin version. > there's a mvn.out file in the attached tarball that has the debug information > (-X) for the output of the maven test run. > This only happens under maven. When you run the same unit test with ant or > IntelliJ it works fine. > See the attached tarball. > note: the actual error may be in any other maven plugin, but i have a feeling > it's in the surefire/unit test setup. -- 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: (MNGECLIPSE-130) Extending the Maven Plugin to allow reuse from other plugins
[ http://jira.codehaus.org/browse/MNGECLIPSE-130?page=comments#action_67112 ] Philip Dodds commented on MNGECLIPSE-130: - Actual the use cases extend beyond a simple archetype, though I do see your point about placing that inside Mavens code. Really the aim was to reuse the Console and the M2 embedded integration with that, since I want to be able to a run Maven 2 goals from an Eclipse plugin and have it log to the M2 Console etc, also reusing the prefences (ie. local repo/logging). > Extending the Maven Plugin to allow reuse from other plugins > > > Key: MNGECLIPSE-130 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-130 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Versions: 0.0.9 > Environment: Eclipse 3.1 > Reporter: Philip Dodds > Assignee: Eugene Kuleshov > Attachments: newMethod.patch > > > I am currently working to build out some tooling around the ServiceMix/FUSE > platform and I have been successful at integrating the Maven2 Eclipse Plugin > to allow the re-use of the archetype plugin in Eclipse (ie. a wizard using > the archetype under the hood) and also the working with using the JBI plugins > to enable integration with publishing to servers. > In order to maximise reuse I wanted to leverage the Maven 2 Eclipse Plugin to > provide access to the MavenEmbedded infrastructure, however it required some > changes to the plugin to provide access from other plugins and to give a > clean simple interface. > Can you review the attached patch for the Maven 2 plugin that offers the > required functionality > 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] Created: (MSUREFIRE-134) Surefire finds test classes but ignores test methods and configuration methods with TestNG and includes tag
Surefire finds test classes but ignores test methods and configuration methods with TestNG and includes tag --- Key: MSUREFIRE-134 URL: http://jira.codehaus.org/browse/MSUREFIRE-134 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.2 Environment: Maven 2.0.4 Surefire Plugin 2.2 TestNG 4.7 jdk15 (using annotations) Sun JDK 1.5_06 Windows XP SP 2 Reporter: Mark Reynolds Attachments: maven2-testng.zip Attachment contains 2 projects which are identical except for how the test cases are referenced. In one project they are referenced via a suite xml file. In the second they are referenced using the includes tag. I believe they should produce identical results. Both projects find all 6 test classes, but only the one using a suite xml file actually executes the configuration methods and test methods. The project using an includes tag completely ignores the configuratiion methods and test methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
