[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}
configuration
excludes
exclude
groupIdbe.nondistributable.*/groupId
/exclude
/excludes
/configuration
{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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 (typemar/type), 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-tabpanelfocusedCommentId=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 plugin artifactIdmaven-surefire-plugin/artifactId version2.11/version executions execution iddefault-test/id phasetest/phase goals goaltest/goal /goals configuration argLine-Xmx2048m -Xms1024m/argLine failIfNoTeststrue/failIfNoTests useManifestOnlyJarfalse/useManifestOnlyJar forkModealways/forkMode forkedProcessTimeoutInSeconds600/forkedProcessTimeoutInSeconds redirectTestOutputToFiletrue/redirectTestOutputToFile systemPropertyVariables java.awt.headlesstrue/java.awt.headless /systemPropertyVariables /configuration /execution /executions configuration argLine-Xmx2048m -Xms1024m/argLine failIfNoTeststrue/failIfNoTests useManifestOnlyJarfalse/useManifestOnlyJar forkModealways/forkMode forkedProcessTimeoutInSeconds600/forkedProcessTimeoutInSeconds redirectTestOutputToFiletrue/redirectTestOutputToFile systemPropertyVariables java.awt.headlesstrue/java.awt.headless /systemPropertyVariables /configuration /plugin reporting plugin configuration plugin artifactIdmaven-surefire-report-plugin/artifactId version2.11/version configuration argLine-Xmx2048m -Xms1024m/argLine failIfNoTeststrue/failIfNoTests useManifestOnlyJarfalse/useManifestOnlyJar forkModealways/forkMode forkedProcessTimeoutInSeconds600/forkedProcessTimeoutInSeconds redirectTestOutputToFiletrue/redirectTestOutputToFile systemPropertyVariables java.awt.headlesstrue/java.awt.headless /systemPropertyVariables /configuration /plugin -- 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 plugin artifactIdmaven-surefire-plugin/artifactId version2.11/version executions execution iddefault-test/id phasetest/phase goals goaltest/goal /goals configuration argLine-Xmx2048m -Xms1024m/argLine failIfNoTeststrue/failIfNoTests useManifestOnlyJarfalse/useManifestOnlyJar forkModealways/forkMode forkedProcessTimeoutInSeconds600/forkedProcessTimeoutInSeconds redirectTestOutputToFiletrue/redirectTestOutputToFile systemPropertyVariables java.awt.headlesstrue/java.awt.headless /systemPropertyVariables /configuration /execution /executions configuration argLine-Xmx2048m -Xms1024m/argLine failIfNoTeststrue/failIfNoTests useManifestOnlyJarfalse/useManifestOnlyJar forkModealways/forkMode forkedProcessTimeoutInSeconds600/forkedProcessTimeoutInSeconds redirectTestOutputToFiletrue/redirectTestOutputToFile systemPropertyVariables java.awt.headlesstrue/java.awt.headless /systemPropertyVariables /configuration /plugin reporting plugin configuration plugin artifactIdmaven-surefire-report-plugin/artifactId version2.11/version configuration argLine-Xmx2048m -Xms1024m/argLine failIfNoTeststrue/failIfNoTests useManifestOnlyJarfalse/useManifestOnlyJar forkModealways/forkMode forkedProcessTimeoutInSeconds600/forkedProcessTimeoutInSeconds redirectTestOutputToFiletrue/redirectTestOutputToFile systemPropertyVariables java.awt.headlesstrue/java.awt.headless /systemPropertyVariables /configuration /plugin -- 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-tabpanelfocusedCommentId=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=1228968view=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-tabpanelfocusedCommentId=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
