[jira] (MEAR-87) Allow exclusion of artifacts when building the ear file.
[
https://jira.codehaus.org/browse/MEAR-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MEAR-87.
---
Resolution: Fixed
> Allow exclusion of artifacts when building the ear file.
>
>
> Key: MEAR-87
> URL: https://jira.codehaus.org/browse/MEAR-87
> Project: Maven 2.x Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.1
>Reporter: Dieter Houthooft
>Assignee: Dennis Lundberg
>Priority: Minor
> Fix For: 2.7
>
> Attachments: maven-ear-plugin-excludes-fixed.patch,
> maven-ear-plugin-excludes.patch
>
>
> What is included in the .ear file is determined by the module list and the
> dependency list and its transitive dependencies. We are often confronted with
> changing demands about what to include in our ear files. It is quite hard to
> change our dependency management (scopes) every time without side-effects on
> other distributable artifacts. So I created an exclude configuration option
> which allows to exclude artifacts from the ear file based on regular
> expressions (java.util.regex) matching artifactIds and groupIds.
> Use it like this:
> {code:xml}
>
>
>
> be.nondistributable.*
>
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-60) Improve support for skinny war files
[ https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MEAR-60. --- Resolution: Fixed I'm closing this issue as fixed now. Andreas, if you manage to put together a reproducible example project for the versioning issue, please open a new issue for that. If we get a release out we can get more people to test this in the wild, and perhaps they can help us zoom in on the that issue. > Improve support for skinny war files > > > Key: MEAR-60 > URL: https://jira.codehaus.org/browse/MEAR-60 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: mvn 2.0.5 >Reporter: Marcel Schutte >Assignee: Dennis Lundberg >Priority: Critical > Fix For: 2.7 > > Attachments: maven-ear-plugin-addon-1.0-SNAPSHOT.jar, > maven-ear-plugin-addon-1.0-SNAPSHOT-sources.jar, > maven-ear-plugin-MEAR-60.patch > > > Provide a boolean configuration option for webModules to include the war's > transitive dependencies. > As described on > http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it > is very common in a J2EE environment to use so called skinny wars. Here the > war's WEB-INF/lib will not contain the dependent jars, but instead they are > packaged inside the EAR. The war references them through its > META-INF/MANIFEST.MF > This option could be used to avoid the 'painful part' mentioned in the above > web page. The war's dependencies wouldn't have to be duplicated alongside the > ear's. > I also found an old issue (MEAR-14) which has asked for the current default > behavior of not including the transitive dependencies. It suggests a property > to include specific dependencies of the war. As far as I can tell this has > never been implemented and this is also not what I am asking for. My proposal > is an all of nothing kind of option for each war module in the ear. > On a side note, for me this is the part where removal of the old maven 1 > style properties per dependency is missed the most. With them it was possible > to decide for each single dependency whether to put it in WEB-INF/lib or > reference it through the manifest classpath. But of course, then we didn't > have the transitive dependencies -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-60) Improve support for skinny war files
[ https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287731#comment-287731 ] Andreas Thaler commented on MEAR-60: Hi Dennis, Purpose of my fileNameMapper was not to remove the timestamped version from war, instead it configured the ear to use timestamped versions for the shared libs. Nevertheless I changed my code now by configuring the war plugin to use non-timestamped versions and now it works fine. I always avoided this approach as I have many war projects to configure contra one ear project, but it is ok. thanks for your support, am looking forward to the new release :) > Improve support for skinny war files > > > Key: MEAR-60 > URL: https://jira.codehaus.org/browse/MEAR-60 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: mvn 2.0.5 >Reporter: Marcel Schutte >Assignee: Dennis Lundberg >Priority: Critical > Fix For: 2.7 > > Attachments: maven-ear-plugin-addon-1.0-SNAPSHOT.jar, > maven-ear-plugin-addon-1.0-SNAPSHOT-sources.jar, > maven-ear-plugin-MEAR-60.patch > > > Provide a boolean configuration option for webModules to include the war's > transitive dependencies. > As described on > http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it > is very common in a J2EE environment to use so called skinny wars. Here the > war's WEB-INF/lib will not contain the dependent jars, but instead they are > packaged inside the EAR. The war references them through its > META-INF/MANIFEST.MF > This option could be used to avoid the 'painful part' mentioned in the above > web page. The war's dependencies wouldn't have to be duplicated alongside the > ear's. > I also found an old issue (MEAR-14) which has asked for the current default > behavior of not including the transitive dependencies. It suggests a property > to include specific dependencies of the war. As far as I can tell this has > never been implemented and this is also not what I am asking for. My proposal > is an all of nothing kind of option for each war module in the ear. > On a side note, for me this is the part where removal of the old maven 1 > style properties per dependency is missed the most. With them it was possible > to decide for each single dependency whether to put it in WEB-INF/lib or > reference it through the manifest classpath. But of course, then we didn't > have the transitive dependencies -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-236) Create a new report to show how to include the module in different build systems
[ https://jira.codehaus.org/browse/MPIR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi updated MPIR-236: Fix Version/s: 2.4.1 > Create a new report to show how to include the module in different build > systems > > > Key: MPIR-236 > URL: https://jira.codehaus.org/browse/MPIR-236 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement > Components: dependency-info >Affects Versions: 2.4.1 >Reporter: Simone Tripodi >Assignee: Simone Tripodi > Fix For: 2.4.1 > > > Different Maven Repositories usually show an info section to show how to > include the found artifact in different build systems (Maven, Ivy, ...), it > would be nice having it directly in the documentation site as well -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-76) This resolution resolves the Clover defect MCLOVER-77
[ https://jira.codehaus.org/browse/MEAR-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287736#comment-287736 ] Torsten Liermann commented on MEAR-76: -- i have a similar when building with cobertura. "Cobertura" is the classifier. I must play with module excludes and extra step for removing duplicate entries from application.xml. > This resolution resolves the Clover defect MCLOVER-77 > - > > Key: MEAR-76 > URL: https://jira.codehaus.org/browse/MEAR-76 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3.1 > Environment: windows/jdk1.5/cloer plugin 2.3.1 and above >Reporter: Martin Franklin >Assignee: Stephane Nicoll > Attachments: cloverclassifier.diff > > > The clover plugin 'swizzles' the dependencies of an artifact when the > clover:instrument goal is executed. This adds the classifier 'clover' to > those dependencies of the ear which can be resolved as clovered artifacts. > However due to some assumptions made in constructing the ear the problem > detailed in http://jira.codehaus.org/browse/MCLOVER-77 can be created. > The cause turns out to be multiple problems - first after clover 'swizzles' > the dependencies the list gets new versions added during ear processing. I > suspect this is due to the classifier being different so the dependencies of > the dependencies are not found and so they get added again. Thus the same > dependency is listed in the project.getArtifacts() Set. Once with the clover > classifier and once with null. The second problem is the application.xml > generation which adds a second set of dependencies. This can be resolved by > specifying the classifier for the specific module listed in the Modules > section. However this is awkward to use if you wish to use the same pom for > both clovered and unclovered ear generation. This patch supports this. > This patch will always select an artifact with a classifier rather than one > with null set. The matching is only done at the groupid/artifactid level, but > I believe that should be sufficient. > Duplicate EarModules are also removed so that only the most specific > gorupid/artifactid/classifier is used for both inclusion in the ear and > inclusion in the application.xml > One last point about the patch - I could not get test 42 to run before I > started work on the patch, so this test is commented out in the patch. All > the other tests worked fine. > As creating a test would require creating a linkage with the clover plugin, > and the fact that the clover plugin itself needs a patch MCLOVER-82, in order > to fully display these effects easily, I haven't created a test case for it. > I have tested this with my own projects which show that MCLOVER-77 is now > resolved with this patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[
https://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287737#comment-287737
]
Andrew Phillips commented on MRRESOURCES-55:
Thanks for updating the downloader, Robert!
Any idea if/when the changes to
{code}ProcessRemoteResourcesMojo.downloadBundles{code} (that will actually use
the new functionality in downloader) could be included?
> Support groupId:artifactId:version:type and
> groupId:artifactId:version:type:classifier as resource bundle references
>
>
> Key: MRRESOURCES-55
> URL: https://jira.codehaus.org/browse/MRRESOURCES-55
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: New Feature
>Affects Versions: 1.2
>Reporter: Andrew Phillips
>Assignee: Robert Scholte
> Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt,
> MRRESOURCES-55-remote-resources-patch.txt
>
>
> Currently, the RR plugin only support groupId:artifactId:version as an
> identifier for a remote bundle. However, there are quite a few use cases
> (e.g. platform-specific bundles) where it would be very useful to be able to
> identify bundles additionally by classifier. The current workaround we use -
> different versions - works, but isn't particularly elegant or semantically
> accurate.
> The proposal therefore is to also allow identifiers of the type
> groupId:artifactId:version:type:classifier
> As Brett pointed out in an IRC chat, this automatically adds the type to the
> identifier as well. One could ignore it or enforce 'jar' (the current
> default), but on the other hand there seems to be no reason *not* to allow
> types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much
> sense.
> Two potential implementations, with tests, are attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-65) Support MAR archives
[ https://jira.codehaus.org/browse/MEAR-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-65: Fix Version/s: (was: 2.7) Unless we get a better view of how this is bundled, I am going to remove it from the 2.7 roadmap. > Support MAR archives > > > Key: MEAR-65 > URL: https://jira.codehaus.org/browse/MEAR-65 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: Stephane Nicoll >Priority: Trivial > > Add support for adding MARs to the archive (mar), like the axis2 > addressing module @: > http://repo1.maven.org/maven2/org/apache/axis2/addressing/1.2/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-71) please support outputFilename here, same as in war plugin
[ https://jira.codehaus.org/browse/MEAR-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-71: Fix Version/s: (was: 2.7) 2.8 > please support outputFilename here, same as in war plugin > - > > Key: MEAR-71 > URL: https://jira.codehaus.org/browse/MEAR-71 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Reporter: Joakim Verona >Assignee: Stephane Nicoll > Fix For: 2.8 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-812) log4j classloader problem in 2.11 that is not there in 2.10
[ https://jira.codehaus.org/browse/SUREFIRE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287744#comment-287744 ] Kristian Rosenvold commented on SUREFIRE-812: - Can you please attach your log4j configuration ? I have committed a test project at https://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/surefire-812-log4j-classloader that can be checked out from svn. Unfortunately this project does not reproduce the problem (run project with "mvn -Dsurefire.version=2.11 test"). If you could try to modify this project to reproduce the problem, you could submit the diff. If there is no further acitvity on this issue in a reasonable amount of time I will close it as cannot reproduce > log4j classloader problem in 2.11 that is not there in 2.10 > --- > > Key: SUREFIRE-812 > URL: https://jira.codehaus.org/browse/SUREFIRE-812 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.11 >Reporter: Gregor N. Purdy, Sr. > > Unit test does not fail with 2.10 but does fail with 2.11 > Output from failing unit test > log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not assignable > to a "org.apache.log4j.spi.Configurator" variable. > log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by > log4j:ERROR [sun.misc.Launcher$AppClassLoader@37b90b39] whereas object of > type > log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by > [org.apache.maven.surefire.booter.IsolatedClassLoader@7bd63e39]. > log4j:ERROR Could not instantiate configurator > [org.apache.log4j.xml.DOMConfigurator]. > $ mvn -version > Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) > Plugin config > > maven-surefire-plugin > 2.11 > > > default-test > test > > test > > > -Xmx2048m -Xms1024m > true > false > always > > 600 > true > > true > > > > > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > true > > > > reporting plugin configuration > > maven-surefire-report-plugin > 2.11 > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > true > > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-812) log4j classloader problem in 2.11 that is not there in 2.10
[ https://jira.codehaus.org/browse/SUREFIRE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-812. --- Resolution: Fixed Fix Version/s: 2.12 Assignee: Kristian Rosenvold Managed to reproduce, added it in r1228952. The issue has already been fixed but can consitently be proved to happen with 2.11 using the IT > log4j classloader problem in 2.11 that is not there in 2.10 > --- > > Key: SUREFIRE-812 > URL: https://jira.codehaus.org/browse/SUREFIRE-812 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.11 >Reporter: Gregor N. Purdy, Sr. >Assignee: Kristian Rosenvold > Fix For: 2.12 > > > Unit test does not fail with 2.10 but does fail with 2.11 > Output from failing unit test > log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not assignable > to a "org.apache.log4j.spi.Configurator" variable. > log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by > log4j:ERROR [sun.misc.Launcher$AppClassLoader@37b90b39] whereas object of > type > log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by > [org.apache.maven.surefire.booter.IsolatedClassLoader@7bd63e39]. > log4j:ERROR Could not instantiate configurator > [org.apache.log4j.xml.DOMConfigurator]. > $ mvn -version > Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) > Plugin config > > maven-surefire-plugin > 2.11 > > > default-test > test > > test > > > -Xmx2048m -Xms1024m > true > false > always > > 600 > true > > true > > > > > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > true > > > > reporting plugin configuration > > maven-surefire-report-plugin > 2.11 > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > true > > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-800) redirectTestOutputToFile is not taken into account in all cases with JUnit47 provider
[
https://jira.codehaus.org/browse/SUREFIRE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-800:
Fix Version/s: 2.12
> redirectTestOutputToFile is not taken into account in all cases with JUnit47
> provider
> -
>
> Key: SUREFIRE-800
> URL: https://jira.codehaus.org/browse/SUREFIRE-800
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10
> Environment: all
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
> Fix For: 2.12
>
>
> With the following class:
> {noformat}
> public class Test0 {
> public Test0(){
> System.out.println("Constructor");
> }
> @Test
> public void testT0() throws Exception {
> System.out.println("testT0");
> }
> @Test
> public void testT1() throws Exception {
> System.out.println("testT1");
> }
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> System.out.println("setUpBeforeClass");
> }
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> System.out.println("tearDownAfterClass");
> }
> @Before
> public void setUp() throws Exception {
> System.out.println("setUp");
> }
> @After
> public void tearDown() throws Exception {
> System.out.println("tearDown");
> }
> }
> {noformat}
> Some elements of the output are not redirected with JUNit47.
> {noformat}
> Concurrency config is parallel='none', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> setUpBeforeClass
> Constructor
> Constructor
> tearDownAfterClass
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
> {noformat}
> While it's ok with with JUNit4:
> {noformat}
> ---
> T E S T S
> ---
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-800) redirectTestOutputToFile is not taken into account in all cases with JUnit47 provider
[
https://jira.codehaus.org/browse/SUREFIRE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-800.
---
Resolution: Fixed
Fix Version/s: (was: Backlog)
Assignee: Kristian Rosenvold
Asssigning to backlog helps ;) Beforeclass/aterclass console output fixed for
"classes" mode in r1228960
> redirectTestOutputToFile is not taken into account in all cases with JUnit47
> provider
> -
>
> Key: SUREFIRE-800
> URL: https://jira.codehaus.org/browse/SUREFIRE-800
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10
> Environment: all
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
>
> With the following class:
> {noformat}
> public class Test0 {
> public Test0(){
> System.out.println("Constructor");
> }
> @Test
> public void testT0() throws Exception {
> System.out.println("testT0");
> }
> @Test
> public void testT1() throws Exception {
> System.out.println("testT1");
> }
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> System.out.println("setUpBeforeClass");
> }
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> System.out.println("tearDownAfterClass");
> }
> @Before
> public void setUp() throws Exception {
> System.out.println("setUp");
> }
> @After
> public void tearDown() throws Exception {
> System.out.println("tearDown");
> }
> }
> {noformat}
> Some elements of the output are not redirected with JUNit47.
> {noformat}
> Concurrency config is parallel='none', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> setUpBeforeClass
> Constructor
> Constructor
> tearDownAfterClass
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
> {noformat}
> While it's ok with with JUNit4:
> {noformat}
> ---
> T E S T S
> ---
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-800) redirectTestOutputToFile is not taken into account in all cases with JUnit47 provider
[
https://jira.codehaus.org/browse/SUREFIRE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287749#comment-287749
]
nkeywal commented on SUREFIRE-800:
--
This one is great! Thanks for all your help, Kristian.
> redirectTestOutputToFile is not taken into account in all cases with JUnit47
> provider
> -
>
> Key: SUREFIRE-800
> URL: https://jira.codehaus.org/browse/SUREFIRE-800
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10
> Environment: all
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
> Fix For: 2.12
>
>
> With the following class:
> {noformat}
> public class Test0 {
> public Test0(){
> System.out.println("Constructor");
> }
> @Test
> public void testT0() throws Exception {
> System.out.println("testT0");
> }
> @Test
> public void testT1() throws Exception {
> System.out.println("testT1");
> }
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> System.out.println("setUpBeforeClass");
> }
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> System.out.println("tearDownAfterClass");
> }
> @Before
> public void setUp() throws Exception {
> System.out.println("setUp");
> }
> @After
> public void tearDown() throws Exception {
> System.out.println("tearDown");
> }
> }
> {noformat}
> Some elements of the output are not redirected with JUNit47.
> {noformat}
> Concurrency config is parallel='none', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> setUpBeforeClass
> Constructor
> Constructor
> tearDownAfterClass
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
> {noformat}
> While it's ok with with JUNit4:
> {noformat}
> ---
> T E S T S
> ---
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-3) [maven-downloader] Infinite-loop in DefaultDownloader.download
[ https://jira.codehaus.org/browse/MSHARED-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSHARED-3. Resolution: Fixed Fix Version/s: maven-downloader-1.2 Assignee: Robert Scholte Fixed in [rev. 1228968|http://svn.apache.org/viewvc?rev=1228968&view=rev] > [maven-downloader] Infinite-loop in DefaultDownloader.download > -- > > Key: MSHARED-3 > URL: https://jira.codehaus.org/browse/MSHARED-3 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-downloader >Reporter: Mark Hobson >Assignee: Robert Scholte > Fix For: maven-downloader-1.2 > > > org.apache.maven.shared.downloader.DefaultDownloader.download(String, String, > String, File, String[]) continuously invokes itself since it doesn't convert > localRepository from a File to an ArtifactRepository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-656) Building maven-scm-1.6 requires a native install of git.
Chris Graham created SCM-656: Summary: Building maven-scm-1.6 requires a native install of git. Key: SCM-656 URL: https://jira.codehaus.org/browse/SCM-656 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.6 Environment: Windows XP maven 2.2.1 Reporter: Chris Graham Check out a fresh copy of maven-scm-1.6 and attempt to build via "mvn clean install" and it fails due to a missing native git.exe not being present. Running org.apache.maven.scm.provider.git.gitexe.command.checkout.GitExeCheckOutCommandNoBranchTest [INFO] Executing: cmd.exe /X /C "git clone C\Workspaces\\maven-scm-1.6\maven-scm-providers\maven-scm-providers-git\maven-scm-provider-gitexe\src\test\resources\repository_no_branch C:\Workspaces\maven-scm-1.6\maven-scm-providers\maven-scm-providers-git\maven-scm-provider-gitexe\target\checkin-nobranch" [INFO] Working directory: C:\Workspaces\maven-scm-1.6\maven-scm-providers\maven-scm-providers-git\maven-scm-provider-gitexe\target -- Provider message -- The git-clone command failed. -- -- Command output -- 'git' is not recognized as an internal or external command, operable program or batch file. -- [INFO] Executing: cmd.exe /X /C "git clone C\Workspaces\maven-scm-1.6\maven-scm-providers\maven-scm-providers-git\maven-scm-provider-gitexe\src\test\resources\repository_no_branch C:\Workspaces\maven-scm-1.6\maven-scm-providers\maven-scm-providers-git\maven-scm-provider-gitexe\target\checkin-nobranch" [INFO] Working directory: C:\Workspaces\maven-scm-1.6\maven-scm-providers\maven-scm-providers-git\maven-scm-provider-gitexe\target -- Provider message -- The git-clone command failed. -- -- Command output -- 'git' is not recognized as an internal or external command, operable program or batch file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-770) persistence.xml in src/test/resources/META-INF is not taken into account
[ https://jira.codehaus.org/browse/SUREFIRE-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287775#comment-287775 ] Marcin Cinik commented on SUREFIRE-770: --- Thank you for the clarification - it's very helpful. And you are right that it is not a maven problem. It looks like the problem also occurs for OpenEJB and it concerns ejb-jar.xml, but I'm still in progress of finding the root cause of my problems. Anyway it's not a good place to discuss this specific issue. > persistence.xml in src/test/resources/META-INF is not taken into account > > > Key: SUREFIRE-770 > URL: https://jira.codehaus.org/browse/SUREFIRE-770 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.9 > Environment: Windows XP >Reporter: Wolfgang Grossinger > Labels: proposedWontFix > Fix For: Backlog > > > When i have a persistence.xml in /src/main/resources/META-INF and in > /src/test/resources/META-INF the xml for the test is never used. I found a > few issues how to fix this but nobody had an explanation why this behavior is > as it is. For me this behavior is really strange (and I couldn't believe that > this is not my fault and is really not working). It seem this has to do with > classloading - in my opinion, the test classes and the test resources should > have priority, otherwise the whole separation of main/test is useless. I > hope, that there is no real reason why this is so at the moment, because this > behavior is really strange and absolutely against what the normal user would > expect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
