[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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:
project xmlns=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;
modelVersion4.0.0/modelVersion
groupIdorg.gteley/groupId
artifactIdtest/artifactId
version0.0.1-SNAPSHOT/version
build
plugins
plugin
artifactIdmaven-remote-resources-plugin/artifactId
version1.2.1/version
executions
execution
goals
goalbundle/goal
/goals
/execution
/executions
configuration
includes
include**/database*/include
/includes
/configuration
/plugin
/plugins
/build
/project
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:
(...)
configuration
includes
include**/database*/include
/includes
outputDirectory
${project.build.outputDirectory}
/outputDirectory
/configuration
(...)
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:
(...)
configuration
includes
include**/database*/include
/includes
outputDirectory
${project.build.directory}
/outputDirectory
/configuration
(...)
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
[jira] Created: (SUREFIRE-751) Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/
Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/ -- Key: SUREFIRE-751 URL: https://jira.codehaus.org/browse/SUREFIRE-751 Project: Maven Surefire Issue Type: New Feature Affects Versions: 2.9 Reporter: Stephen Connolly The current parallel execution spawns one thread _per_class_ When there is a large disparity between the number of tests in different classes, this can result in a longer execution time. This can often happen in GUI testing, where a couple of classes will contain a lot of long running (but low cpu) test cases, and the remaining classes run fast. See http://maven-junit-plugin.kenai.com/ for an attempt at solving this -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-751) Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/
[ https://jira.codehaus.org/browse/SUREFIRE-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-751: -- Fix Version/s: 3.0 Assignee: Kristian Rosenvold Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/ -- Key: SUREFIRE-751 URL: https://jira.codehaus.org/browse/SUREFIRE-751 Project: Maven Surefire Issue Type: New Feature Affects Versions: 2.9 Reporter: Stephen Connolly Assignee: Kristian Rosenvold Fix For: 3.0 The current parallel execution spawns one thread _per_class_ When there is a large disparity between the number of tests in different classes, this can result in a longer execution time. This can often happen in GUI testing, where a couple of classes will contain a lot of long running (but low cpu) test cases, and the remaining classes run fast. See http://maven-junit-plugin.kenai.com/ for an attempt at solving this -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-752) Fix duplication in surefire/failsafe sites
[ https://jira.codehaus.org/browse/SUREFIRE-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-752: Fix Version/s: 2.10 Assignee: Stephen Connolly Fix duplication in surefire/failsafe sites -- Key: SUREFIRE-752 URL: https://jira.codehaus.org/browse/SUREFIRE-752 Project: Maven Surefire Issue Type: Improvement Reporter: Kristian Rosenvold Assignee: Stephen Connolly Fix For: 2.10 There is a large amount of duplicated documentation in the surefire project, because failsafe and surefire contain the same docs. This duplication is a PITA. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-752) Fix duplication in surefire/failsafe sites
Fix duplication in surefire/failsafe sites -- Key: SUREFIRE-752 URL: https://jira.codehaus.org/browse/SUREFIRE-752 Project: Maven Surefire Issue Type: Improvement Reporter: Kristian Rosenvold There is a large amount of duplicated documentation in the surefire project, because failsafe and surefire contain the same docs. This duplication is a PITA. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCLEAN-48) Failure cleaning files containing special characters
Failure cleaning files containing special characters Key: MCLEAN-48 URL: https://jira.codehaus.org/browse/MCLEAN-48 Project: Maven 2.x Clean Plugin Issue Type: Bug Affects Versions: 2.4.1 Environment: Ubuntu 10.10 LANG=en_DK.utf8 Reporter: Stefan Meisner Larsen I am not able to clean my project which contains files named with special characters. It seems as though the plugin does not handle UTF-8 correctly. Name of file as reported by find command: ./ewp-fr/ewp-fr.war/src/main/webapp/secure/fr/Conditions_générales_d'isalaire.pdf Output from clean: . . . [ERROR] Failed to execute goal org.apache.maven.plugins:maven-clean-plugin:2.4.1:clean (default-clean) on project ewp-fr.war: Failed to clean project: Failed to delete /home/stefan/trifork/lessor/ewp-clean/trunk/ewp-fr/ewp-fr.war/target/ewp-fr.war-1.69-SNAPSHOT/secure/fr/Conditions_g??n??rales_d'isalaire.pdf - [Help 1] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-561) Encoding is broken when filtering is enabled
Encoding is broken when filtering is enabled
Key: MASSEMBLY-561
URL: https://jira.codehaus.org/browse/MASSEMBLY-561
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
Priority: Critical
My resources are encoded in ISO-8859-1. I have specified encoding in the pom:
{code}project.build.sourceEncodingISO-8859-1/project.build.sourceEncoding{code}
I have written a custom assembly file and I am using resource filtering.
{code}...
fileSet
directory${project.basedir}/src/main/resources//directory
outputDirectory//outputDirectory
filteredtrue/filtered
/fileSet
...{code}
As a result all the french characters are broken in the resulting zip assembly.
My platform is Linux so the default platform encoding is UTF-8.
I have checked plugin code and I think I found the issue. This is in
FileFormatter.java, method doFileFilter():
{code}
configSource.getMavenFileFilter().copyFile( source, target, true,
configSource.getProject(),
configSource.getFilters(), isPropertiesFile, null,
configSource.getMavenSession() );
{code}
You can see that enconding is set to null, so I think it means using default
platform encoding... Would it be possible to use value of
project.build.sourceEncoding instead?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-259) Provide a configuration settings for default tag/label to use when releasing
[
https://jira.codehaus.org/browse/MRELEASE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MRELEASE-259.
-
Resolution: Duplicate
Closing as duplicate of MRELEASE-159
Provide a configuration settings for default tag/label to use when releasing
Key: MRELEASE-259
URL: https://jira.codehaus.org/browse/MRELEASE-259
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Components: prepare
Reporter: Wouter Hermeling
Currently the default tag/label proposed is ${artifactId}-${version}
However i would like to only use the version, like this: ${version}
And maybe others would like to use ${project.name$}_${version} or something
else.
This could easily be set via the plugin configuration.
I may provide a patch myself, when i have some more free time.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-150) Can't add prefix to tags without affecting version
[
https://jira.codehaus.org/browse/MRELEASE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MRELEASE-150.
-
Resolution: Duplicate
Closing as duplicate of MRELEASE-159
Can't add prefix to tags without affecting version
--
Key: MRELEASE-150
URL: https://jira.codehaus.org/browse/MRELEASE-150
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.0-beta-4
Reporter: Yuri Schimke
Priority: Minor
Attachments: release-manager-patch.patch
I added the following to my POM
plugin
artifactIdmaven-release-plugin/artifactId
configuration
tagXXX-${artifactId}-${version}/tag
/configuration
/plugin
However the tag comes out incorrectly.
[INFO] Full run would be tagging C:\PerforceViews\... with label:
'XXX-myproject-0.5.4-SNAPSHOT
What is the default? tag${artifactId}-${version}/tag
Note: this seems to be missing from the plugin documentation, it only
mentions releaseLabel, which defaults to tag.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-159) Support a pattern to generate the release tag
[ https://jira.codehaus.org/browse/MRELEASE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MRELEASE-159. - Resolution: Fixed Assignee: Stephen Connolly r1139359 Support a pattern to generate the release tag - Key: MRELEASE-159 URL: https://jira.codehaus.org/browse/MRELEASE-159 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.0-beta-4 Reporter: Joerg Schaible Assignee: Stephen Connolly Fix For: 2.2 Attachments: MRELEASE-159-PATCH-2-0.patch, MRELEASE-159-PATCH.diff.gz, MRELEASE-159-PATCH-update.diff.gz, release-manager-patch.patch, release-manager(updated).patch The release-plugin uses currently the pattern artifactId-version to create the version tag. A configuration element would be fine to support different requirements for release tags (in our case v_version, since with svn the module is already part of the path). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-374) Snapshot versions unusable in batch mode
[ https://jira.codehaus.org/browse/MRELEASE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MRELEASE-374. - Resolution: Fixed Fix Version/s: 2.2 Assignee: Stephen Connolly r1139366 Snapshot versions unusable in batch mode Key: MRELEASE-374 URL: https://jira.codehaus.org/browse/MRELEASE-374 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-8 Environment: Maven 2.0.9 Windows XP Reporter: Edouard Hue Assignee: Stephen Connolly Priority: Blocker Fix For: 2.2 Attachments: MRELEASE-374.diff When running in batch mode, build fails when a snapshot of maven-release-plugin is being used : [INFO] Can't release project due to non released dependencies : org.apache.maven.plugins:maven-release-plugin:maven-plugin:2.0-beta-8-SNAPSHOT:runtime In interactive mode, it is possible to bypass the check. This should be possible in batch mode too. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3228) Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ https://jira.codehaus.org/browse/MNG-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=271290#comment-271290 ] Chris Cooper commented on MNG-3228: --- Can we get someone to look at this? This is definitely still an issue. I have a project that has a top level parent which all other components (100's) eventually inherit from and it is not acceptable to have to copy paste this profile to every component. The profile defined in the parent is not being inherited from any child to be activated. If you use the exact test case to reproduce this, you can in fact easily reproduce it. Maven profile activation does not work when profile is defined in inherited 'parent' pom Key: MNG-3228 URL: https://jira.codehaus.org/browse/MNG-3228 Project: Maven 2 3 Issue Type: Bug Affects Versions: 2.0.7 Reporter: tony nys Assignee: John Casey Fix For: 2.1.0 The goal is to activate a maven profile based on OS user name. When I create a standalone project with a profile activation, it works, however, when I define the profile in a parent pom, it is never activated. this works: ... profile idTONY/id activation property nameuser.name/name valueWINTONY/value /property /activation properties /properties So in this case, my profile is activated based on my OS user name [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': The following profiles are active: - TONY (source: pom) -- However, if I now have the profiles definition in the parent pom, it doesn't work when I build a child project So the child project references the parent pom containing the profiles and the activation, but when it is built, the profile is not activated PARENT POM: ... profiles profile idTONY/id activation property nameuser.name/name valueWINTONY/value /property /activation properties ... CHILD POM (the one being built) project parent groupIdcom.capgemini.be.proj1/groupId artifactIdparent/artifactId version4.0.2/version /parent [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 Application [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': There are no active profiles. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
