[jira] Closed: (MEAR-94) Synchronize module releases and documentation releases
[ http://jira.codehaus.org/browse/MEAR-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-94. --- Assignee: Stephane Nicoll Resolution: Fixed Fix Version/s: 2.3.2 2.3.2 about to be released and website is up to date. > Synchronize module releases and documentation releases > -- > > Key: MEAR-94 > URL: http://jira.codehaus.org/browse/MEAR-94 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3.1 > Environment: N/A >Reporter: Mike Mosiewicz >Assignee: Stephane Nicoll > Fix For: 2.3.2 > > > Right now currently released version is 2.3.1, however documentation at: > http://maven.apache.org/plugins/maven-ear-plugin/usage.html says that one can > use jboss/data-sources. In released version this feature doesn't exist. So > please keep the main site in sync with the documentation. Otherwise it > produces problems for people trying to use the feature, then having to grab > the code to find out that it actually doesn't exist yet. -- 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-2432) Apache and Mojo plugins take precendence over plugins in the pom.
[ http://jira.codehaus.org/browse/MNG-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-2432: --- Fix Version/s: 2.1.0 Merged to 2.1.x in [r751248|http://svn.eu.apache.org/viewvc?view=rev&revision=751248]. > Apache and Mojo plugins take precendence over plugins in the pom. > - > > Key: MNG-2432 > URL: http://jira.codehaus.org/browse/MNG-2432 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 >Reporter: Jan Bartel >Assignee: Brian Fox > Fix For: 2.1.0, 3.0-alpha-2 > > > When resolving plugin prefixes, plugins from apache and mojo take precendence > over plugins explicitly in the pom.xml. For example, an old plugin with > prefix "jetty" at org.codehaus.mojo.jetty-maven-plugin is always used in > preference to the new maven-jetty-plugin with prefix "jetty", even though it > is specified in the pom like so: > > org.mortbay.jetty > maven-jetty-plugin > 6.0-SNAPSHOT > -- 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-3043) Allow 'mvn test' to work with test-jar dependencies in a reactor
[ http://jira.codehaus.org/browse/MNG-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3043: --- Attachment: mng-3043.zip Sample project. > Allow 'mvn test' to work with test-jar dependencies in a reactor > > > Key: MNG-3043 > URL: http://jira.codehaus.org/browse/MNG-3043 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Reactor and workspace >Affects Versions: 2.0.6, 2.0.7 >Reporter: Kenney Westerhof > Fix For: 2.0.x > > Attachments: mng-3043.zip > > > Basically the issue is demonstrated by MNG-2045, but instead of running 'mvn > install', you run 'mvn test'. > Test classes of dependencies should be resolved from the reactor, just as > main classes, if there's no archive available. > I'm not sure how to go about this. Specifying a dependency on something with > test-jar, > and having that dependency declare the maven-jar-plugin with the 'test-jar' > goal is insufficient. > Perhaps we can just add a standard classifier that maven is aware of, in this > case 'tests'. The jar packaging > would export this as a known classifier, and tells maven how it contributes > to what classpath. > Since test sources are a first class citizen, just as main sources are (they > have the same phases, same > elements in the pom (but differently named)). > It seems logical to me that somehow the test classes should be made available > to dependencies, > if they declare a dependency with classifier 'tests'. -- 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-3043) Allow 'mvn test' to work with test-jar dependencies in a reactor
[ http://jira.codehaus.org/browse/MNG-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3043: --- Attachment: mng-3043.zip > Allow 'mvn test' to work with test-jar dependencies in a reactor > > > Key: MNG-3043 > URL: http://jira.codehaus.org/browse/MNG-3043 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Reactor and workspace >Affects Versions: 2.0.6, 2.0.7 >Reporter: Kenney Westerhof > Fix For: 2.0.x > > Attachments: mng-3043.zip, mng-3043.zip > > > Basically the issue is demonstrated by MNG-2045, but instead of running 'mvn > install', you run 'mvn test'. > Test classes of dependencies should be resolved from the reactor, just as > main classes, if there's no archive available. > I'm not sure how to go about this. Specifying a dependency on something with > test-jar, > and having that dependency declare the maven-jar-plugin with the 'test-jar' > goal is insufficient. > Perhaps we can just add a standard classifier that maven is aware of, in this > case 'tests'. The jar packaging > would export this as a known classifier, and tells maven how it contributes > to what classpath. > Since test sources are a first class citizen, just as main sources are (they > have the same phases, same > elements in the pom (but differently named)). > It seems logical to me that somehow the test classes should be made available > to dependencies, > if they declare a dependency with classifier 'tests'. -- 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-3043) Allow 'mvn test' to work with test-jar dependencies in a reactor
[ http://jira.codehaus.org/browse/MNG-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3043: --- Attachment: (was: mng-3043.zip) > Allow 'mvn test' to work with test-jar dependencies in a reactor > > > Key: MNG-3043 > URL: http://jira.codehaus.org/browse/MNG-3043 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Reactor and workspace >Affects Versions: 2.0.6, 2.0.7 >Reporter: Kenney Westerhof > Fix For: 2.0.x > > Attachments: mng-3043.zip > > > Basically the issue is demonstrated by MNG-2045, but instead of running 'mvn > install', you run 'mvn test'. > Test classes of dependencies should be resolved from the reactor, just as > main classes, if there's no archive available. > I'm not sure how to go about this. Specifying a dependency on something with > test-jar, > and having that dependency declare the maven-jar-plugin with the 'test-jar' > goal is insufficient. > Perhaps we can just add a standard classifier that maven is aware of, in this > case 'tests'. The jar packaging > would export this as a known classifier, and tells maven how it contributes > to what classpath. > Since test sources are a first class citizen, just as main sources are (they > have the same phases, same > elements in the pom (but differently named)). > It seems logical to me that somehow the test classes should be made available > to dependencies, > if they declare a dependency with classifier 'tests'. -- 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-3043) Allow 'mvn test' to work with test-jar dependencies in a reactor
[ http://jira.codehaus.org/browse/MNG-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168369#action_168369 ] Benjamin Bentmann commented on MNG-3043: Feature branch has been created for [discussion on dev@|http://www.nabble.com/MNG-3043%2C-please-comment-to22388639.html]. > Allow 'mvn test' to work with test-jar dependencies in a reactor > > > Key: MNG-3043 > URL: http://jira.codehaus.org/browse/MNG-3043 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Reactor and workspace >Affects Versions: 2.0.6, 2.0.7 >Reporter: Kenney Westerhof > Fix For: 2.0.x > > Attachments: mng-3043.zip > > > Basically the issue is demonstrated by MNG-2045, but instead of running 'mvn > install', you run 'mvn test'. > Test classes of dependencies should be resolved from the reactor, just as > main classes, if there's no archive available. > I'm not sure how to go about this. Specifying a dependency on something with > test-jar, > and having that dependency declare the maven-jar-plugin with the 'test-jar' > goal is insufficient. > Perhaps we can just add a standard classifier that maven is aware of, in this > case 'tests'. The jar packaging > would export this as a known classifier, and tells maven how it contributes > to what classpath. > Since test sources are a first class citizen, just as main sources are (they > have the same phases, same > elements in the pom (but differently named)). > It seems logical to me that somehow the test classes should be made available > to dependencies, > if they declare a dependency with classifier 'tests'. -- 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-3857) Malformed respositories element could use a better error message
[ http://jira.codehaus.org/browse/MNG-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168382#action_168382 ] Johannes Schneider commented on MNG-3857: - The problem is the missing "" tag... Better error message will be great. > Malformed respositories element could use a better error message > > > Key: MNG-3857 > URL: http://jira.codehaus.org/browse/MNG-3857 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0.9 >Reporter: Justin Edelson >Assignee: Brett Porter >Priority: Minor > Attachments: pom.xml > > > If you create a pom that has a repository element like this: > > > just.an.id > > > The error message isn't at all helpful: > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at org.apache.maven.wagon.PathUtils.protocol(PathUtils.java:206) > at > org.apache.maven.wagon.repository.Repository.setUrl(Repository.java:121) > at > org.apache.maven.wagon.repository.Repository.(Repository.java:74) > at > org.apache.maven.artifact.repository.DefaultArtifactRepository.(DefaultArtifactRepository.java:87) > at > org.apache.maven.artifact.repository.DefaultArtifactRepositoryFactory.createArtifactRepository(DefaultArtifactRepositoryFactory.java:85) > at > org.apache.maven.project.ProjectUtils.buildArtifactRepository(ProjectUtils.java:105) > at > org.apache.maven.project.ProjectUtils.buildArtifactRepositories(ProjectUtils.java:56) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildArtifactRepositories(DefaultMavenProjectBuilder.java:944) > at > org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1144) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:821) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > 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) > Would be nice to have this be a more obvious message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[
http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168390#action_168390
]
Dimitri Alexeev commented on SUREFIRE-482:
--
I would also vote for reopening this bug. The idea of JUnit4 was to simplify
testing by doing away with unnecessary naming conventions.
The decision to test or not to test should _only_ depend on @Test annotation.
The temporary deactivated tests should be recognized on that double signature
@Ignore("not today")
@Test(timeout = 100)
public void computationPerformance() { ... }
> Surefire tries to run JUnit4 tests that contain no @Test annotations
>
>
> Key: SUREFIRE-482
> URL: http://jira.codehaus.org/browse/SUREFIRE-482
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.4.2
>Reporter: Mark Hobson
> Attachments: test.zip
>
>
> Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that
> contain no @Test annotations as tests, resulting in the exception:
> java.lang.Exception: No runnable methods
> at
> org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32)
> at
> org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43)
> at
> org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36)
> at
> org.junit.internal.runners.JUnit4ClassRunner.(JUnit4ClassRunner.java:27)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at
> org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33)
> at
> org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.(JUnit4TestSet.java:45)
> at
> org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96)
> at
> org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:156)
> 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
> Such classes should be ignored by Surefire.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[
http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=168390#action_168390
]
Dimitri Alexeev edited comment on SUREFIRE-482 at 3/7/09 7:59 PM:
--
I would also vote for reopening this bug.
Perhaps, this solution would work:
@Ignore @Test
public void ignoredMethod() {...}
while the following one results in "java.lang.Exception: No runnable methods":
//@Ignore @Test
public void ignoredMethod() {...}
was (Author: alexeev.net):
I would also vote for reopening this bug. The idea of JUnit4 was to
simplify testing by doing away with unnecessary naming conventions.
The decision to test or not to test should _only_ depend on @Test annotation.
The temporary deactivated tests should be recognized on that double signature
@Ignore("not today")
@Test(timeout = 100)
public void computationPerformance() { ... }
> Surefire tries to run JUnit4 tests that contain no @Test annotations
>
>
> Key: SUREFIRE-482
> URL: http://jira.codehaus.org/browse/SUREFIRE-482
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.4.2
>Reporter: Mark Hobson
> Attachments: test.zip
>
>
> Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that
> contain no @Test annotations as tests, resulting in the exception:
> java.lang.Exception: No runnable methods
> at
> org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32)
> at
> org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43)
> at
> org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36)
> at
> org.junit.internal.runners.JUnit4ClassRunner.(JUnit4ClassRunner.java:27)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at
> org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33)
> at
> org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.(JUnit4TestSet.java:45)
> at
> org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96)
> at
> org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:156)
> 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
> Such classes should be ignored by Surefire.
--
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-2383) Upload Stripes-1.5.1 to Maven Repository
Upload Stripes-1.5.1 to Maven Repository Key: MAVENUPLOAD-2383 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2383 Project: Maven Upload Requests Issue Type: Wish Reporter: Freddy Daoud Could you please upload the stripes-1.5.1 bundle to the public maven repository. 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
