[jira] Updated: (SUREFIRE-738) Fail on not existing run order.
[ https://jira.codehaus.org/browse/SUREFIRE-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Birkner updated SUREFIRE-738: Attachment: surefire-738.patch Here's the patch. I introduced an enum RunOrder. > Fail on not existing run order. > --- > > Key: SUREFIRE-738 > URL: https://jira.codehaus.org/browse/SUREFIRE-738 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Stefan Birkner >Priority: Minor > Attachments: surefire-738.patch > > > I want surefire to fail, if I start surefire with a run order, which is not > in the set alphabetical, reversealphabetical, random, hourly and fileset. > Today I don't get any information, when I start surefire with a wrong run > order like alphapetical. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGES-46) There is no link to the RSS feed of changes in the changes report
[ https://jira.codehaus.org/browse/MCHANGES-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MCHANGES-46: -- Attachment: MCHANGES-46.patch Attaching an alternative that uses the rome library for rss generation. Since I haven't checked what other work went into this issue before, and the changes plugin just had some release, I leave it here for review. > There is no link to the RSS feed of changes in the changes report > - > > Key: MCHANGES-46 > URL: https://jira.codehaus.org/browse/MCHANGES-46 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: changes.xml >Reporter: Dennis Lundberg > Attachments: MCHANGES-46-maven-changes-plugin.patch, MCHANGES-46.patch > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-750) Add custom name suffix for surefire-reports (xml and txt)
[ https://jira.codehaus.org/browse/SUREFIRE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rostislav Svoboda updated SUREFIRE-750: --- Attachment: reportNameSuffix-tests.patch Tests for .xml .txt and -output.txt files with and without reportNameSuffix defined. Apply this patch after reportNameSuffix.patch > Add custom name suffix for surefire-reports (xml and txt) > - > > Key: SUREFIRE-750 > URL: https://jira.codehaus.org/browse/SUREFIRE-750 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin, xml > generation >Reporter: Rostislav Svoboda >Priority: Critical > Attachments: reportNameSuffix.patch, reportNameSuffix-tests.patch > > > Hi. > I'd to add support in surefire for custom name suffix for tests in > surefire-reports. > Motivation 1): > I have more modules, some modules are sharing tests from another using > org.codehaus.mojo:build-helper-maven-plugin. > I'd like to have txt and xml files with some differentiator to determine in > which module tests were executed. > Motivation 2): > I have defined several executions where I use different parameters and > execute the same tests in each execution. > Again, I'd like to have txt and xml files with some differentiator. > Solution: > Introduce new configuration property reportNameSuffix. > Patch for this improvement is included. > Tested: > Yes, customText added into surefire > plugin configuration and received these files: > org.xyz.test.componentA.ComponentAUnitTest-customText-output.txt > org.xyz.test.componentA.ComponentAUnitTest-customText.txt > org.xyz.test.componentB.ComponentBUnitTest-customText-output.txt > org.xyz.test.componentB.ComponentBUnitTest-customText.txt > TEST-org.xyz.test.componentA.ComponentAUnitTest-customText.xml > TEST-org.xyz.test.componentB.ComponentBUnitTest-customText.xml > Tested without defined too, original file names and > content generated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271072#comment-271072
]
Geoffrey De Smet edited comment on MASSEMBLY-557 at 6/23/11 7:00 AM:
-
During 5.2.0 first failed attempt it occurred again, for droolsjbpm-integration
again this time.
During 5.2.0.Final succeeded attempt it occurred again, for drools-planner that
time.
So hopefully this is a reproduce recipe:
git clone g...@github.com:droolsjbpm/droolsjbpm-build-bootstrap.git
droolsjbpm-build-bootstrap/script/git-clone-others.sh
droolsjbpm-build-bootstrap/script/mvn-all.sh clean install -DskipTests -Dfull
cd
droolsjbpm-build-distribution/droolsjbpm-uber-distribution/target/droolsjbpm-uber-distribution-*
unzip *.zip
// check the reference_manual directory contents after unzipping (not when
zipped)
was (Author: ge0ffrey):
During 5.2.0 final it occurred again, for droolsjbpm-integration again this
time.
So hopefully this is a reproduce recipe:
git clone g...@github.com:droolsjbpm/droolsjbpm-build-bootstrap.git
droolsjbpm-build-bootstrap/script/git-clone-others.sh
droolsjbpm-build-bootstrap/script/mvn-all.sh clean install -DskipTests -Dfull
cd
droolsjbpm-build-distribution/droolsjbpm-uber-distribution/target/droolsjbpm-uber-distribution-*
unzip *.zip
// check the reference_manual directory contents after unzipping (not when
zipped)
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271185#comment-271185
]
Geoffrey De Smet commented on MASSEMBLY-557:
Similar problems with javadoc directory
> Corrupted zip created by assembly: extracting the zip forgets certain folders
> (or throws permission denied errors) possibly because zip index is corrupted
> --
>
> Key: MASSEMBLY-557
> URL: https://jira.codehaus.org/browse/MASSEMBLY-557
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Geoffrey De Smet
>Priority: Critical
> Attachments:
> droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
>
>
> Take a look at the attached zip created by the assembly plugin.
> - If you open it, you can see navigate to the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
> map you find the file droolsjbpm-integration-docs.pdf which you can open with
> a PDF reader.
> - If instead you extract the entire archive to a directory, and navigate to
> the submap
> /droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
> find that that map is unreadable (chmod 000) and the pdf file is gone.
> The directories html_single and html suffer the same fate, but none of the
> other directories do.
> I used the default linux Ubuntu 10.10 archive manager (which according to
> about screen is called "File-roller 2.32.0").
> I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
> Note that that attached zip is gutted to stay inside the maximum file upload
> size.
> Possible reproduce recipe:
> {code}
> git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
> cd droolsjbpm-integration
> git checkout 5.2.0.M2
> mvn clean install -DskipTests -Dfull
> cd droolsjbpm-integration/target
> ls
> {code}
> {code}
> checkdir error: cannot create
> /home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
> Permission denied
> unable to process
> droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
> ...
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5083) unconditional explicit profile activation
[
https://jira.codehaus.org/browse/MNG-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271186#comment-271186
]
Martin Todorov commented on MNG-5083:
-
Yegor,
How would this be different from:
{code}
...
my-always-active-profile
true
...
{code}
This already exists in Maven.
> unconditional explicit profile activation
> -
>
> Key: MNG-5083
> URL: https://jira.codehaus.org/browse/MNG-5083
> Project: Maven 2 & 3
> Issue Type: New Feature
>Affects Versions: 3.0.3
>Reporter: Yegor Bugayenko
>
> Would be nice to have an ability to activate a profile unconditionally:
> {noformat}
>
>
>
> true
>
>
>
> {noformat}
> That should mean that the profile is active no matter what. All other
> activation conditions are just ignored.
> With this feature profiles could be used for convenient grouping of plugins
> inside one module. For better readability of {{pom.xml}}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGES-261) Mail sender specification pointlessly difficult
Mail sender specification pointlessly difficult --- Key: MCHANGES-261 URL: https://jira.codehaus.org/browse/MCHANGES-261 Project: Maven 2.x Changes Plugin Issue Type: Bug Affects Versions: 2.5, 2.6 Reporter: Benson Margulies THe mail sender in the pom is a complex data structure, inaccessible from -D. There's no good reason for this; it wouldn't be hard to write a tiny parser to allow someone not listed as a 'developer' to send email. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-687) assembly:assembly goal as mentioned in the documentation is deprecated
assembly:assembly goal as mentioned in the documentation is deprecated -- Key: MRELEASE-687 URL: https://jira.codehaus.org/browse/MRELEASE-687 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: documentation Affects Versions: 2.1 Reporter: Pieter Iserbyt Priority: Trivial In "Introduction" -> "Perform a Release", in the example POM configuration, the "assembly:assembly" goal is used, which per http://maven.apache.org/plugins/maven-assembly-plugin/plugin-info.html (v2.2.1) is deprecated. Propose to replace by "assembly:single" as suggested on the assembly plugin documentation, here and everywhere else mentioned in the documentation. Remark: this might require updates also with testing the release plugin (using assembly:single iso assembly:assembly) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-749) Parallel methods should run in separate classloaders
[ https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271191#comment-271191 ] Gili commented on SUREFIRE-749: --- Kristian, @BeforeClass won't work for Guice because we're launching a new server per @Test, not per-class. It would help for slf4j though. Mark, I'm only proposing separate Classloaders for parallel-methods. The implementation already instantiates a separate object per @Test so I'm not sure that @BeforeClass/@AfterClass is really relevant here. > Parallel methods should run in separate classloaders > > > Key: SUREFIRE-749 > URL: https://jira.codehaus.org/browse/SUREFIRE-749 > Project: Maven Surefire > Issue Type: New Feature > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.8.1 >Reporter: Gili > > When running in parallel-method or parallel-both mode, each @Test should run > in its own ClassLoader. I'm running into a lot of problems involving the use > of static variables in 3rd-party libraries. Here are two examples: > 1. slf4j: http://bugzilla.slf4j.org/show_bug.cgi?id=176 > 2. guice: http://code.google.com/p/google-guice/issues/detail?id=635 > I believe running in isolated ClassLoaders would fix both problems and it > makes a lot of sense from a test isolation point of view so we should do it > anyway. > I believe Surefire's forkMode is defined in terms of isolated JVMs instead of > ClassLoaders. Furthermore, it only seems to support per-Class isolation > instead of per-@Test isolation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-749) Parallel methods should run in separate classloaders
[ https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271197#comment-271197 ] Gili commented on SUREFIRE-749: --- Kristian, I think I've got a very simple solution but I need a second pair of eyes to confirm. JUnit doesn't seem to be Classloader-aware. We're invoking JUnitCore.runClasses(Class...) and it goes about doing its business. How about we simply load those Classes into separate Classloaders before passing them into that method? I believe that should do it. Can you point out where Surefire is constructing the Class objects? > Parallel methods should run in separate classloaders > > > Key: SUREFIRE-749 > URL: https://jira.codehaus.org/browse/SUREFIRE-749 > Project: Maven Surefire > Issue Type: New Feature > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.8.1 >Reporter: Gili > > When running in parallel-method or parallel-both mode, each @Test should run > in its own ClassLoader. I'm running into a lot of problems involving the use > of static variables in 3rd-party libraries. Here are two examples: > 1. slf4j: http://bugzilla.slf4j.org/show_bug.cgi?id=176 > 2. guice: http://code.google.com/p/google-guice/issues/detail?id=635 > I believe running in isolated ClassLoaders would fix both problems and it > makes a lot of sense from a test isolation point of view so we should do it > anyway. > I believe Surefire's forkMode is defined in terms of isolated JVMs instead of > ClassLoaders. Furthermore, it only seems to support per-Class isolation > instead of per-@Test isolation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5083) unconditional explicit profile activation
[
https://jira.codehaus.org/browse/MNG-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271206#comment-271206
]
Yegor Bugayenko commented on MNG-5083:
--
{{}} will be ignored once you specify profile name in command
line (using {{-P}} argument)
> unconditional explicit profile activation
> -
>
> Key: MNG-5083
> URL: https://jira.codehaus.org/browse/MNG-5083
> Project: Maven 2 & 3
> Issue Type: New Feature
>Affects Versions: 3.0.3
>Reporter: Yegor Bugayenko
>
> Would be nice to have an ability to activate a profile unconditionally:
> {noformat}
>
>
>
> true
>
>
>
> {noformat}
> That should mean that the profile is active no matter what. All other
> activation conditions are just ignored.
> With this feature profiles could be used for convenient grouping of plugins
> inside one module. For better readability of {{pom.xml}}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5122) MavenCli com.google.inject.internal.util.ComputationException: java.lang.NoClassDefFoundError: org/apache/maven/plugin/descriptor/MojoDescriptor
[
https://jira.codehaus.org/browse/MNG-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MNG-5122:
--
Affects Version/s: (was: 2.2.1)
3.0.3
> MavenCli com.google.inject.internal.util.ComputationException:
> java.lang.NoClassDefFoundError:
> org/apache/maven/plugin/descriptor/MojoDescriptor
>
>
> Key: MNG-5122
> URL: https://jira.codehaus.org/browse/MNG-5122
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading, Embedding
>Affects Versions: 3.0.3
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_16
> Java home: C:\Programme\Java\jdk1.6.0_16\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
>Reporter: Kati Golbang
> Attachments: build.log, components.xml, pom.xml
>
>
> I want to use MavenCli in order to use Maven programatically within an
> installer (IzPack).
> pom.xml (see attachment).
> I'm using
>
> org.apache.maven
> maven-embedder
> 3.0-beta-3
>
> Note that all dependencies are unzipped and part of the final installer jar
> (target/product-installer.jar). The components.xml contains all available
> components.xml files (merged by plexus-component-metadata plugin).
> how to build: mvn -X clean install > build.log
> At runtime (java -Xdebug
> -Xrunjdwp:transport=dt_socket,server=y,address="8000" -jar
> target/wigeoweb-installer.jar) following code is executed:
> MavenCli cli = new MavenCli();
> int result = cli.doMain(new String[]{"compile -X"},
> "C:/Develop/Experiments/webservercontext-maven-plugin", //Own plugin
> System.out, System.out);
> System.out.println("result: " + result);
> It terminates with exception while initializing plexus container (there's the
> place where the debugger exits):
> Exception:
> Listening for transport dt_socket at address: 8000
> [ERROR] Error executing Maven.
> [ERROR] com.google.inject.internal.util.ComputationException:
> java.lang.NoClassDefFoundError:
> org/apache/maven/plugin/descriptor/MojoDescriptor
> [ERROR] Caused by: java.lang.NoClassDefFoundError:
> org/apache/maven/plugin/descriptor/MojoDescriptor
> [ERROR] Caused by: org/apache/maven/plugin/descriptor/MojoDescriptor
> [ERROR] Caused by: org.apache.maven.plugin.descriptor.MojoDescriptor
> Source Code:
> private void container( CliRequest cliRequest )
> throws Exception
> {
> if ( cliRequest.classWorld == null )
> { cliRequest.classWorld = new ClassWorld( "plexus.core",
> Thread.currentThread().getContextClassLoader() ); }
> DefaultPlexusContainer container = this.container;
> if ( container == null )
> {
> ContainerConfiguration cc = new DefaultContainerConfiguration()
> .setClassWorld( cliRequest.classWorld )
> .setName( "maven" );
> *container = new DefaultPlexusContainer( cc ); //<<
> EXCEPTION THROWN*
> container.setLoggerManager( new MavenLoggerManager( logger ) );
> container.getLoggerManager().setThresholds(
> cliRequest.request.getLoggingLevel() );
> customizeContainer( container );
> if ( cliRequest.classWorld == classWorld )
> { this.container = container; }
> }
> maven = container.lookup( Maven.class );
> executionRequestPopulator = container.lookup(
> MavenExecutionRequestPopulator.class );
> modelProcessor = createModelProcessor( container );
> settingsBuilder = container.lookup( SettingsBuilder.class );
> dispatcher = (DefaultSecDispatcher) container.lookup( SecDispatcher.class,
> "maven" );
> }
> thank you
> K. Golbang
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-749) Parallel methods should run in separate classloaders
[ https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271242#comment-271242 ] Kristian Rosenvold commented on SUREFIRE-749: - You'd have to test if loading the class object in different classloaders actually works. But remember that JUnit instantiates one instance per test, so you'd still be left with multiple instances from the same classloader when there are several methods in one class. How does that solve anything for methods ? (You might be able to run classes parallel...) The class objects are being loaded in class "DefaultDirectoryScanner" line 78. I recommend you just clone surefire on github (https://github.com/apache/maven-surefire) ,fork the provider use your custom fork as described here http://maven.apache.org/plugins/maven-surefire-plugin/examples/providers.html. Using this setup makes it quite easy to experiment and play around with this stuff. If your patch turns out to be really simple and works really well I'll consider it, especially if there's tests. After all we're not totally mean :-) > Parallel methods should run in separate classloaders > > > Key: SUREFIRE-749 > URL: https://jira.codehaus.org/browse/SUREFIRE-749 > Project: Maven Surefire > Issue Type: New Feature > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.8.1 >Reporter: Gili > > When running in parallel-method or parallel-both mode, each @Test should run > in its own ClassLoader. I'm running into a lot of problems involving the use > of static variables in 3rd-party libraries. Here are two examples: > 1. slf4j: http://bugzilla.slf4j.org/show_bug.cgi?id=176 > 2. guice: http://code.google.com/p/google-guice/issues/detail?id=635 > I believe running in isolated ClassLoaders would fix both problems and it > makes a lot of sense from a test isolation point of view so we should do it > anyway. > I believe Surefire's forkMode is defined in terms of isolated JVMs instead of > ClassLoaders. Furthermore, it only seems to support per-Class isolation > instead of per-@Test isolation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-749) Parallel methods should run in separate classloaders
[ https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271243#comment-271243 ] Kristian Rosenvold commented on SUREFIRE-749: - I sense there's a documentation update coming out of this issue. I have written several blogposts about running tests in parallel, but I think we need to make a whole new docs page about the parallel stuff, probably covering some options/aspects/known gotchas in this space. Submissions welcome ;) > Parallel methods should run in separate classloaders > > > Key: SUREFIRE-749 > URL: https://jira.codehaus.org/browse/SUREFIRE-749 > Project: Maven Surefire > Issue Type: New Feature > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.8.1 >Reporter: Gili > > When running in parallel-method or parallel-both mode, each @Test should run > in its own ClassLoader. I'm running into a lot of problems involving the use > of static variables in 3rd-party libraries. Here are two examples: > 1. slf4j: http://bugzilla.slf4j.org/show_bug.cgi?id=176 > 2. guice: http://code.google.com/p/google-guice/issues/detail?id=635 > I believe running in isolated ClassLoaders would fix both problems and it > makes a lot of sense from a test isolation point of view so we should do it > anyway. > I believe Surefire's forkMode is defined in terms of isolated JVMs instead of > ClassLoaders. Furthermore, it only seems to support per-Class isolation > instead of per-@Test isolation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRRESOURCES-56) The maven-remote-resources-plugin (1.2.1) fails to create a usable Resource Bundle if the outputDirectory configuration parameter is specified and does not explicitly
The maven-remote-resources-plugin (1.2.1) fails to create a usable Resource
Bundle if the outputDirectory configuration parameter is specified and does not
explicitly contain ${project.build.outputDirectory}
---
Key: MRRESOURCES-56
URL: https://jira.codehaus.org/browse/MRRESOURCES-56
Project: Maven 2.x Remote Resources Plugin
Issue Type: Bug
Affects Versions: 1.2.1
Environment: Window XP, Java 1.6
Reporter: Gareth Tudor Eley
Attachments: test.zip
Issue:
The maven-remote-resources-plugin (1.2.1) fails to create a usable Resource
Bundle if the outputDirectory configuration parameter is specified and does not
explicitly contain ${project.build.outputDirectory} - this makes
${project.build.outputDirectory} the only viable configuration.
The documentation for the remote-resources:bundle goal: (see:
http://maven.apache.org/plugins/maven-remote-resources-plugin/bundle-mojo.html#outputDirectory)
states:
outputDirectory:
The directory where you want the resource bundle manifest written to.
Type: java.io.File
Required: No
Expression: ${project.build.outputDirectory}
Reproduction the issue:
With this initial POM:
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
org.gteley
test
0.0.1-SNAPSHOT
maven-remote-resources-plugin
1.2.1
bundle
**/database*
With this project directory structure:
test/
|
+src/
|
+ main/
|
+ resources
|
`database.ddl
`database.sql
Execute this command: mvn clean package to obtain this good result:
test/
|
+src/
|
+target/
|
+test-0.0.1-SNAPSHOT.jar/
|
`database.ddl
`database.sql
|
+ META-INF\
|
` MANIFEST.MF
|
+ maven
|
` remote-resources.xml
|
+ org.gteley/
|
`pom.properties
`pom.xml
|
+ classes/
|
`database.ddl
`database.sql
|
+ META-INF\
|
+ maven
|
` remote-resources.xml
|
+ maven-archiver/
|
` pom.properties
|
+ maven-shared-archive-resources/
+ test-classes/
Everything is fine, the contents of the Resource Bundle
(test-0.0.1-SNAPSHOT.jar) are as required and expected for subsequent
consumption by the remote-resource:process goal..
Now, amend the POM to explicitly specify the default value for the
outputDirectory parameter:
(...)
**/database*
${project.build.outputDirectory}
(...)
Execute this command again: mvn clean package to obtain the same good result.
OK far, now amend the POM to explicitly specify an alternative value
(${project.build.directory}) for the outputDirectory parameter:
(...)
**/database*
${project.build.directory}
(...)
The result below now reveals the issue, the Resource Bundle
(test-0.0.1-SNAPSHOT.jar) is created, but without the necessary
META-INF/maven/remote-resources.xml file:
test/
|
|
+ META-INF\
|
` MANIFEST.MF
|
+ maven
|
` remote-resources.xml
|
+ org.gteley/
|
`pom.properties
`pom.xml
|
+src/
|
+target/
|
+test-0.0.1-SNAPSHOT.jar/
|
`database.ddl
`database.sql
|
+ classes/
|
`database.ddl
`database.sql
|
+ maven-archiver/
|
` pom.properties
|
+ maven-shared-archive-resources/
+ test-classes/
By specifying ${project.build.directory} the
META-INF/maven/remote-resources.xml file lies at the same directory level as
the src and target directories (as expected) - but the Resource Bundle
(test-0.0.1-SNAPSHOT.jar) does not now contain the
META-INF/maven/remote-resources.xml file rendering useless for subsequent
processing by the remote-resource:process goal:
Another way to also render the Bundled Resource useless for processing by the
remote-resource:process goal is to append a subdirectory to the valid
${project.build.outputDirectory} configuration.
Amend the POM again this time specify an additional subdirectory to the
${project.build.outputDirectory} configuration of the outputDirectory parameter
like thi
