[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=271165#comment-271165
]
Kristian Rosenvold commented on SUREFIRE-749:
-
Yes the line you are looking at executes a single test-class, but unfortunately
you are looking in the wrong provider.
The JUnit4 provider is the classic no-frills JUnit4 executor. The moment you
switch to parallel you switch to the more modern
JUnitCoreProvider, which is a totally different beast.
You may actually be able to do what you want within the context of forking the
junit4 or the junit core provider and just doing everything yourself. You could
just put that on github or similar, making a derivate (forked) surefire
provider is really simple. It's going to be a fairly extensive change and I'm
have serious doubts if we will accept it as a contribution; but I'll keep an
open mind if you should decide to do it. Just be warned. The JUnitCore provider
is where all of the fun stuff happens, the Junit4 provider is basically a safe,
conservative version (and also the first junit 4 implementation).
BTW: You /did/ try just initializing the guice/log4j stuff in either a
@BeforeClass method (runs on a single thread) or simply use a static {} block
somewhere ? I suppose I'm half assuming you know these tricks. Making all the
tests synchronize on a single common static lock might also be viable.
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] Issue Comment Edited: (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=271165#comment-271165
]
Kristian Rosenvold edited comment on SUREFIRE-749 at 6/23/11 1:00 AM:
--
Yes the line you are looking at executes a single test-class, but unfortunately
you are looking in the wrong provider.
The JUnit4 provider is the classic no-frills JUnit4 executor. The moment you
switch to parallel you switch to the more modern
JUnitCoreProvider, which is a totally different beast.
You may actually be able to do what you want within the context of forking the
junit4 or the junit core provider and just doing everything yourself. You could
just put that on github or similar, making a derivate (forked) surefire
provider is really simple. It's going to be a fairly extensive change and I'm
have serious doubts if we will accept it as a contribution; but I'll keep an
open mind if you should decide to do it. Just be warned. The JUnitCore provider
is where all of the fun stuff happens, the Junit4 provider is basically a safe,
conservative version (and also the first junit 4 implementation).
BTW: You /did/ try just initializing the guice/log4j stuff in either a
@BeforeClass method (runs on a single thread) or simply use a static {} block
somewhere ? I suppose I'm half assuming you know these tricks. Making all the
tests synchronize on a single common static lock might also be viable for some
parts of the construction logic
was (Author: krosenvold):
Yes the line you are looking at executes a single test-class, but
unfortunately you are looking in the wrong provider.
The JUnit4 provider is the classic no-frills JUnit4 executor. The moment you
switch to parallel you switch to the more modern
JUnitCoreProvider, which is a totally different beast.
You may actually be able to do what you want within the context of forking the
junit4 or the junit core provider and just doing everything yourself. You could
just put that on github or similar, making a derivate (forked) surefire
provider is really simple. It's going to be a fairly extensive change and I'm
have serious doubts if we will accept it as a contribution; but I'll keep an
open mind if you should decide to do it. Just be warned. The JUnitCore provider
is where all of the fun stuff happens, the Junit4 provider is basically a safe,
conservative version (and also the first junit 4 implementation).
BTW: You /did/ try just initializing the guice/log4j stuff in either a
@BeforeClass method (runs on a single thread) or simply use a static {} block
somewhere ? I suppose I'm half assuming you know these tricks. Making all the
tests synchronize on a single common static lock might also be viable.
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=271170#comment-271170 ] Mark Struberg commented on SUREFIRE-749: I fear this wont work out too. Consider the following (pretty frequently used) scenario: Your @BeforeClass starts a container (e.g. Weld, Spring or OpenWebBeans), the @AfterClass shuts it down again. This would not work as expected if you split the single tests in separate ClassLoaders. Basically the whole test setup needs to be aware that the tests are being run in parallel mode. I had this problem in a few projects where we use testng. In this case it's not even guaranteed that all tests of a class are executed in one go, thus we had to do reference counting to guarantee that the container got shut down correctly. 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] 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, reportNameSuffixcustomText/reportNameSuffix 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 reportNameSuffix 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=271186#comment-271186
]
Martin Todorov commented on MNG-5083:
-
Yegor,
How would this be different from:
{code}
project
...
profiles
profile
idmy-always-active-profile/id
activation
activeByDefaulttrue/activeByDefault
/activation
...
/profile
/profiles
/project
{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}
profiles
profile
activation
enforcetrue/enforce
/activation
/profile
/profiles
{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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=271206#comment-271206
]
Yegor Bugayenko commented on MNG-5083:
--
{{activeByDefault}} 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}
profiles
profile
activation
enforcetrue/enforce
/activation
/profile
/profiles
{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
dependency
groupIdorg.apache.maven/groupId
artifactIdmaven-embedder/artifactId
version3.0-beta-3/version
/dependency
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
