[jira] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291455#comment-291455
]
Geoffrey De Smet commented on MENFORCER-128:
I am ok with any name change,
but I do think that "RequireHighestDependencyVersion" is simpler and clearer
then "RequireUpperBoundDependencies".
The term "Upper bound" is misleading and not standard knowledge for the average
programmer: http://en.wikipedia.org/wiki/Upper_and_lower_bounds
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291455#comment-291455
]
Geoffrey De Smet edited comment on MENFORCER-128 at 2/13/12 2:49 AM:
-
I am ok with any name change,
but I do think that "RequireHighestDependencyVersion" is simpler and clearer
then "RequireUpperBoundDependencies".
The term "Upper bound" might not be standard knowledge for the average
programmer: http://en.wikipedia.org/wiki/Upper_and_lower_bounds
was (Author: ge0ffrey):
I am ok with any name change,
but I do think that "RequireHighestDependencyVersion" is simpler and clearer
then "RequireUpperBoundDependencies".
The term "Upper bound" might be misleading and not standard knowledge for the
average programmer: http://en.wikipedia.org/wiki/Upper_and_lower_bounds
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291455#comment-291455
]
Geoffrey De Smet edited comment on MENFORCER-128 at 2/13/12 2:48 AM:
-
I am ok with any name change,
but I do think that "RequireHighestDependencyVersion" is simpler and clearer
then "RequireUpperBoundDependencies".
The term "Upper bound" might be misleading and not standard knowledge for the
average programmer: http://en.wikipedia.org/wiki/Upper_and_lower_bounds
was (Author: ge0ffrey):
I am ok with any name change,
but I do think that "RequireHighestDependencyVersion" is simpler and clearer
then "RequireUpperBoundDependencies".
The term "Upper bound" is misleading and not standard knowledge for the average
programmer: http://en.wikipedia.org/wiki/Upper_and_lower_bounds
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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-834) Groups are ignored if test are executed in parallel mode
Mario Krautz created SUREFIRE-834:
-
Summary: Groups are ignored if test are executed in parallel mode
Key: SUREFIRE-834
URL: https://jira.codehaus.org/browse/SUREFIRE-834
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.7+ (parallel) support, Junit 4.x support
Affects Versions: 2.12
Environment: Linux 3.0.0-15-generic #26-Ubuntu SMP x86_64 x86_64
x86_64 GNU/Linux
Junit 4.10
Reporter: Mario Krautz
Attachments: test-playground.tar.gz
Hi!
We have a maven-project containing multiple modules. Our junit tests are
annotated with categories (@Category annotation). If we start the test with:
{code}mvn clean verify -Dgroups=org.example.MyCategory{code}
everything works as expected (only MyCategory-annotated tests are executed).
But in parallel mode *all* tests are executed!
I have attached an example project to demonstrate the bug.
When executing:
{code}mvn clean verify -Dgroups=org.example.MyCategory{code}
two test are executed.
When executing:
{code}mvn clean verify -Dgroups=org.example.MyCategory -Pparallel{code}
four tests are executed.
The parallel profile looks like this:
{code}
parallel
org.apache.maven.plugins
maven-failsafe-plugin
2.12
methods
2
false
{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] (SUREFIRE-834) Groups are ignored if test are executed in parallel mode
[
https://jira.codehaus.org/browse/SUREFIRE-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Krautz updated SUREFIRE-834:
--
Attachment: test-playground.tar.gz
attachment uploaded again, first version cannot be opened after download;(
> Groups are ignored if test are executed in parallel mode
>
>
> Key: SUREFIRE-834
> URL: https://jira.codehaus.org/browse/SUREFIRE-834
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Junit 4.x support
>Affects Versions: 2.12
> Environment: Linux 3.0.0-15-generic #26-Ubuntu SMP x86_64 x86_64
> x86_64 GNU/Linux
> Junit 4.10
>Reporter: Mario Krautz
> Attachments: test-playground.tar.gz, test-playground.tar.gz
>
>
> Hi!
> We have a maven-project containing multiple modules. Our junit tests are
> annotated with categories (@Category annotation). If we start the test with:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> everything works as expected (only MyCategory-annotated tests are executed).
> But in parallel mode *all* tests are executed!
> I have attached an example project to demonstrate the bug.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> two test are executed.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory -Pparallel{code}
> four tests are executed.
> The parallel profile looks like this:
> {code}
>
> parallel
>
>
>
> org.apache.maven.plugins
> maven-failsafe-plugin
> 2.12
>
> methods
> 2
> false
>
>
>
>
>
> {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] (SUREFIRE-834) Groups are ignored if test are executed in parallel mode
[
https://jira.codehaus.org/browse/SUREFIRE-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Krautz updated SUREFIRE-834:
--
Attachment: bugexample.zip
now the test project is added as zip
> Groups are ignored if test are executed in parallel mode
>
>
> Key: SUREFIRE-834
> URL: https://jira.codehaus.org/browse/SUREFIRE-834
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Junit 4.x support
>Affects Versions: 2.12
> Environment: Linux 3.0.0-15-generic #26-Ubuntu SMP x86_64 x86_64
> x86_64 GNU/Linux
> Junit 4.10
>Reporter: Mario Krautz
> Attachments: bugexample.zip, test-playground.tar.gz,
> test-playground.tar.gz
>
>
> Hi!
> We have a maven-project containing multiple modules. Our junit tests are
> annotated with categories (@Category annotation). If we start the test with:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> everything works as expected (only MyCategory-annotated tests are executed).
> But in parallel mode *all* tests are executed!
> I have attached an example project to demonstrate the bug.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory{code}
> two test are executed.
> When executing:
> {code}mvn clean verify -Dgroups=org.example.MyCategory -Pparallel{code}
> four tests are executed.
> The parallel profile looks like this:
> {code}
>
> parallel
>
>
>
> org.apache.maven.plugins
> maven-failsafe-plugin
> 2.12
>
> methods
> 2
> false
>
>
>
>
>
> {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] (MRELEASE-737) Make SCM tag and other release properties available during release:perform
James Roper created MRELEASE-737: Summary: Make SCM tag and other release properties available during release:perform Key: MRELEASE-737 URL: https://jira.codehaus.org/browse/MRELEASE-737 Project: Maven 2.x Release Plugin Issue Type: New Feature Reporter: James Roper My use case is, when a perform is done, I want to make an API call on our Continuous Deployment system (Jenkins) that triggers a build that will deploy the artifact to our staging system. In order to do that, I need to know the SCM tag to pass to Jenkins to tell it to build. Hence it would be helpful if this could be passed to the release:perform stage as a system property. -- 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-835) Tests for maven plugins are incompatible with maven 3.0.4
Ruslan Diachenko created SUREFIRE-835:
-
Summary: Tests for maven plugins are incompatible with maven 3.0.4
Key: SUREFIRE-835
URL: https://jira.codehaus.org/browse/SUREFIRE-835
Project: Maven Surefire
Issue Type: Bug
Reporter: Ruslan Diachenko
Attachments: simple-test.zip
Steps will reproduce the problem:
1. Write test for maven plugin by extending test class from
AbstractMojoTestCase (package org.apache.maven.plugin.testing)
public class SimpleMavenTest extends AbstractMojoTestCase {
@Override
protected void setUp() throws Exception {
super.setUp();
// code
}
public void test() throws Exception {
// test case
}
@Override
protected void tearDown() throws Exception {
// code
super.tearDown();
}
}
2. Configure maven-surefire-plugin as follows:
org.apache.maven.plugins
maven-surefire-plugin
never
3. Run "mvn test" on maven 3.0.4
Detected:
java.lang.IllegalStateException: The internal default plexus-bootstrap.xml is
missing. This is highly irregular, your plexus JAR is most likely corrupt.
at
org.codehaus.plexus.DefaultPlexusContainer.initializeConfiguration(DefaultPlexusContainer.java:1052)
at
org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:627)
at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:119)
at
org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:69)
at org.maven.test.MyMojoTest.setUp(MyMojoTest.java:12)
at junit.framework.TestCase.runBare(TestCase.java:128)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Error occurred only when never. If we change forkMode
value to "once" or another one, test will run succesfully. On maven 3.0.3 and
previous maven versions the test was run without any errors.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291493#comment-291493
]
Paul Gier commented on MENFORCER-128:
-
The reason I didn't go with something like RequireHighestDependencyVersion is
because it sounds like it will require the highest version available in the
repository. Upper bound makes more sense to me because what you are saying is
that the version in the POM is the highest version that is acceptable in the
dependency tree.
Anyway, I think as long at the description in the site docs are good, users
will be able to figure out what it means.
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291499#comment-291499
]
Geoffrey De Smet commented on MENFORCER-128:
Ok, sounds good :)
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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-827) Surefire 2.12 cannot run a single test, regression from 2.11
[
https://jira.codehaus.org/browse/SUREFIRE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291515#comment-291515
]
François LEIBER commented on SUREFIRE-827:
--
We also have a big issue with the Surefire 2.12 (using default configuration,
which means forkMode=once): the Junit tests of the first module pass perfectly,
then we have a "Z,0,BYE!" in the log and the surefire plugin fails with:
{code}
The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?
at
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.close(ForkClient.java:244)
{code}
If I check
maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java,
I see the following lines:
runSuitesInProcess( testSet, testClassLoader, startupConfiguration,
providerConfiguration );
// Say bye.
System.out.println("Z,0,BYE!");
System.out.flush();
// noinspection CallToSystemExit
System.exit( 0 );
> Surefire 2.12 cannot run a single test, regression from 2.11
>
>
> Key: SUREFIRE-827
> URL: https://jira.codehaus.org/browse/SUREFIRE-827
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.12
> Environment: Ubuntu 11.10
>Reporter: Andrew Gaul
>
> # Surefire 2.11
> $ mvn test -Dtest=DataTest#testDataServerGetNonExistentFile
> ...
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> # Surefire 2.12
> mvn test -Dtest=DataTest#testDataServerGetNonExistentFile
> ...
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0
--
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-827) Surefire 2.12 cannot run a single test, regression from 2.11
[
https://jira.codehaus.org/browse/SUREFIRE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291515#comment-291515
]
François LEIBER edited comment on SUREFIRE-827 at 2/13/12 10:04 AM:
We also have a big issue with the Surefire 2.12 (using default configuration,
which means forkMode=once): the Junit tests of the first module pass perfectly,
then we have a "Z,0,BYE!" in the log and the surefire plugin fails with:
{code}
The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?
at
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.close(ForkClient.java:244)
{code}
If I check
maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java,
I see the following lines:
{code}
runSuitesInProcess( testSet, testClassLoader, startupConfiguration,
providerConfiguration );
// Say bye.
System.out.println("Z,0,BYE!");
System.out.flush();
// noinspection CallToSystemExit
System.exit( 0 );
{code}
Why is surefire someone called System.exit() if it's the one which did it?
was (Author: fleiber):
We also have a big issue with the Surefire 2.12 (using default
configuration, which means forkMode=once): the Junit tests of the first module
pass perfectly, then we have a "Z,0,BYE!" in the log and the surefire plugin
fails with:
{code}
The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?
at
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.close(ForkClient.java:244)
{code}
If I check
maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java,
I see the following lines:
runSuitesInProcess( testSet, testClassLoader, startupConfiguration,
providerConfiguration );
// Say bye.
System.out.println("Z,0,BYE!");
System.out.flush();
// noinspection CallToSystemExit
System.exit( 0 );
> Surefire 2.12 cannot run a single test, regression from 2.11
>
>
> Key: SUREFIRE-827
> URL: https://jira.codehaus.org/browse/SUREFIRE-827
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.12
> Environment: Ubuntu 11.10
>Reporter: Andrew Gaul
>
> # Surefire 2.11
> $ mvn test -Dtest=DataTest#testDataServerGetNonExistentFile
> ...
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> # Surefire 2.12
> mvn test -Dtest=DataTest#testDataServerGetNonExistentFile
> ...
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0
--
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-827) Surefire 2.12 cannot run a single test, regression from 2.11
[
https://jira.codehaus.org/browse/SUREFIRE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291515#comment-291515
]
François LEIBER edited comment on SUREFIRE-827 at 2/13/12 10:09 AM:
We also have a big issue with surefire 2.12 (using default configuration, which
means forkMode=once): the Junit tests of the first module pass perfectly, then
we have a "Z,0,BYE!" in the log and the surefire plugin fails with:
{code}
The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?
at
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.close(ForkClient.java:244)
{code}
If I check
maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java,
I see the following lines:
{code}
runSuitesInProcess( testSet, testClassLoader, startupConfiguration,
providerConfiguration );
// Say bye.
System.out.println("Z,0,BYE!");
System.out.flush();
// noinspection CallToSystemExit
System.exit( 0 );
{code}
Why is surefire someone called System.exit() if it's the one which did it?
was (Author: fleiber):
We also have a big issue with the Surefire 2.12 (using default
configuration, which means forkMode=once): the Junit tests of the first module
pass perfectly, then we have a "Z,0,BYE!" in the log and the surefire plugin
fails with:
{code}
The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?
at
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.close(ForkClient.java:244)
{code}
If I check
maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java,
I see the following lines:
{code}
runSuitesInProcess( testSet, testClassLoader, startupConfiguration,
providerConfiguration );
// Say bye.
System.out.println("Z,0,BYE!");
System.out.flush();
// noinspection CallToSystemExit
System.exit( 0 );
{code}
Why is surefire someone called System.exit() if it's the one which did it?
> Surefire 2.12 cannot run a single test, regression from 2.11
>
>
> Key: SUREFIRE-827
> URL: https://jira.codehaus.org/browse/SUREFIRE-827
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.12
> Environment: Ubuntu 11.10
>Reporter: Andrew Gaul
>
> # Surefire 2.11
> $ mvn test -Dtest=DataTest#testDataServerGetNonExistentFile
> ...
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> # Surefire 2.12
> mvn test -Dtest=DataTest#testDataServerGetNonExistentFile
> ...
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0
--
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-827) Surefire 2.12 cannot run a single test, regression from 2.11
[
https://jira.codehaus.org/browse/SUREFIRE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291515#comment-291515
]
François LEIBER edited comment on SUREFIRE-827 at 2/13/12 10:10 AM:
We also have a big issue with surefire 2.12 (using default configuration, which
means forkMode=once): the Junit tests of the first module pass perfectly, then
we have a "Z,0,BYE!" in the log and the surefire plugin fails with:
{code}
The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?
at
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.close(ForkClient.java:244)
{code}
If I check
maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java,
I see the following lines:
{code}
runSuitesInProcess( testSet, testClassLoader, startupConfiguration,
providerConfiguration );
// Say bye.
System.out.println("Z,0,BYE!");
System.out.flush();
// noinspection CallToSystemExit
System.exit( 0 );
{code}
Why is surefire surprised someone called System.exit() if he's the one who did
it?
was (Author: fleiber):
We also have a big issue with surefire 2.12 (using default configuration,
which means forkMode=once): the Junit tests of the first module pass perfectly,
then we have a "Z,0,BYE!" in the log and the surefire plugin fails with:
{code}
The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?
at
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.close(ForkClient.java:244)
{code}
If I check
maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java,
I see the following lines:
{code}
runSuitesInProcess( testSet, testClassLoader, startupConfiguration,
providerConfiguration );
// Say bye.
System.out.println("Z,0,BYE!");
System.out.flush();
// noinspection CallToSystemExit
System.exit( 0 );
{code}
Why is surefire someone called System.exit() if it's the one which did it?
> Surefire 2.12 cannot run a single test, regression from 2.11
>
>
> Key: SUREFIRE-827
> URL: https://jira.codehaus.org/browse/SUREFIRE-827
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.12
> Environment: Ubuntu 11.10
>Reporter: Andrew Gaul
>
> # Surefire 2.11
> $ mvn test -Dtest=DataTest#testDataServerGetNonExistentFile
> ...
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> # Surefire 2.12
> mvn test -Dtest=DataTest#testDataServerGetNonExistentFile
> ...
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291550#comment-291550
]
Paul Gier commented on MENFORCER-128:
-
I added a bit more description to the site docs, just to try to make this clear.
[r1243555|http://svn.apache.org/viewvc?view=revision&revision=1243555]
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MRELEASE-281) Pom version is not modified during release:branch goal
[ https://jira.codehaus.org/browse/MRELEASE-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRELEASE-281: Component/s: (was: prepare) branch > Pom version is not modified during release:branch goal > -- > > Key: MRELEASE-281 > URL: https://jira.codehaus.org/browse/MRELEASE-281 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.0-beta-6 > Environment: maven 2.0.6 >Reporter: Franck HUGOT > > When I perform release:branch I have 3 problems : > - FirstI have to specify the branch name on the command line (I don't want to > have it in my pom to commit it!), why it don't ask me for the branche name as > for the release:prepare goal? > - Secondly, the most important, the version in the pom () > is not modified. It should also work as the release:prepare goal. > - To finish, the documentation on the web site talks about tag, I think you > should talk about branch > (http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html) > I think this goal (release:branch) should have the same behavior as the > release:prepare because the same actions have to be performed. -- 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] (MRELEASE-253) AIOOB exception on release:prepare
[ https://jira.codehaus.org/browse/MRELEASE-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-253. --- Resolution: Incomplete Assignee: Robert Scholte I know there have been several releases of this plugin since, so I have to assume this issue is fixed by now. The description is not complete enough to confirm. > AIOOB exception on release:prepare > -- > > Key: MRELEASE-253 > URL: https://jira.codehaus.org/browse/MRELEASE-253 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Reporter: Milos Kleint >Assignee: Robert Scholte > > I've tried to do a nbm-maven-plugin 2.5 release (project at > mojo.codehaus.org) with the release:prepare goal. > got this rather "symbolic" error message. :) > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] 42 > [INFO] > > full output along with stacktrace. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'release'. > WAGON_VERSION: 1.0-beta-2 > [INFO] > > [INFO] Building NBM Maven Plugin > [INFO]task-segment: [release:prepare] (aggregator-style) > [INFO] > > [INFO] [release:prepare] > [INFO] Resuming release from phase 'rewrite-poms-for-release' > [INFO] Transforming 'NBM Maven Plugin'... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] 42 > [INFO] > > [INFO] Trace > java.lang.ArrayIndexOutOfBoundsException: 42 > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateUrlPath(RewritePomsForReleasePhase.java:249) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateScm(RewritePomsForReleasePhase.java:124) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.transformScm(RewritePomsForReleasePhase.java:79) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:271) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:180) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:116) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:99) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.cla
[jira] (MNG-5243) If a transitive dependency is missing, the error message makes it very hard to find out where it comes from
S.Leske created MNG-5243:
Summary: If a transitive dependency is missing, the error message
makes it very hard to find out where it comes from
Key: MNG-5243
URL: https://jira.codehaus.org/browse/MNG-5243
Project: Maven 2 & 3
Issue Type: Bug
Reporter: S.Leske
Priority: Minor
If a transitive dependency cannot be resolved during the build, the build fails
(so far obviously OK). However, the error message printed does not indicate
where the dependency came from. It may have been pulled in via several layers
of transitive dependencies, in that case it is very difficult to figure out how
it got included.
Example:
Project dependencies are: A -> B -> C. Error message during build of A, if C is
missing from the repo:
{noformat}
[...]
[WARNING] The POM for dependency-bug-test:C:jar:1 is missing, no
dependency information available
[INFO] ---
[INFO] BUILD FAILURE
[INFO] ---
[...]
[ERROR] Failed to execute goal on project A: Could not resolve dependencies
for project dependency-bug-test:A:jar:1:
Failure to find dependency-bug-test:C:jar:1 in
http://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of
central has elapsed or updates are forced -> [Help 1]
[...]
{noformat}
Note the error message gives no indication whatsoever that the missing C is
required because B depends on it. With more complex dependencies, this makes
tracking down the culprit very difficult.
Also note that "mvn dependency:tree" does not help in this case, because it
fails with the same unhelpful error :-(.
--
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] (MNG-5243) If a transitive dependency is missing, the error message makes it very hard to find out where it comes from
[
https://jira.codehaus.org/browse/MNG-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Leske updated MNG-5243:
-
Attachment: dependency-bug.tgz
Simple example to demonstrate the problem.
The archive contains three minimal POMs (A, B, C). Dependencies are A -> B -> C.
The included build.sh will build C, then B, then delete C from the local Maven
repo, then build A. Building A causes the described error message.
build.sh should run unmodified on Linux. Adapt accordingly on Windows.
> If a transitive dependency is missing, the error message makes it very hard
> to find out where it comes from
> ---
>
> Key: MNG-5243
> URL: https://jira.codehaus.org/browse/MNG-5243
> Project: Maven 2 & 3
> Issue Type: Bug
>Reporter: S.Leske
>Priority: Minor
> Attachments: dependency-bug.tgz
>
>
> If a transitive dependency cannot be resolved during the build, the build
> fails (so far obviously OK). However, the error message printed does not
> indicate where the dependency came from. It may have been pulled in via
> several layers of transitive dependencies, in that case it is very difficult
> to figure out how it got included.
> Example:
> Project dependencies are: A -> B -> C. Error message during build of A, if C
> is missing from the repo:
> {noformat}
> [...]
> [WARNING] The POM for dependency-bug-test:C:jar:1 is missing, no
> dependency information available
> [INFO] ---
> [INFO] BUILD FAILURE
> [INFO] ---
> [...]
> [ERROR] Failed to execute goal on project A: Could not resolve dependencies
> for project dependency-bug-test:A:jar:1:
> Failure to find dependency-bug-test:C:jar:1 in
> http://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of
> central has elapsed or updates are forced -> [Help 1]
> [...]
> {noformat}
> Note the error message gives no indication whatsoever that the missing C is
> required because B depends on it. With more complex dependencies, this makes
> tracking down the culprit very difficult.
> Also note that "mvn dependency:tree" does not help in this case, because it
> fails with the same unhelpful error :-(.
--
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] (MRELEASE-207) Update JavaDoc @versin tags on new release
[
https://jira.codehaus.org/browse/MRELEASE-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-207.
---
Resolution: Won't Fix
Assignee: Robert Scholte
You're talking about updating javadoc-tags. There's already a
maven-javadoc-plugin with the
[fix|http://maven.apache.org/plugins/maven-javadoc-plugin/fix-mojo.html] goal,
which can do these things.
> Update JavaDoc @versin tags on new release
> --
>
> Key: MRELEASE-207
> URL: https://jira.codehaus.org/browse/MRELEASE-207
> Project: Maven 2.x Release Plugin
> Issue Type: New Feature
> Components: prepare
>Reporter: Roman Cerny
>Assignee: Robert Scholte
>Priority: Minor
>
> it would be nice to tell the maven-release-plugin, to change ALL the source
> files as well.
> i mean, it would be nice, if the @version javadoc tag would be automatically
> changed for each class.
> For e.g. when releasing version 1.7 and changing to 1.8-SNAPSHOT, all
> @version tags (for each class) should be changed to 1.8 (right after the
> release).
> So what i need would be the plugin to look at the ${pom.version} and the walk
> through all my packages (in my source folder) and change the @version javadoc
> tag in every single java class 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] (MRELEASE-207) Update JavaDoc @version tags on new release
[
https://jira.codehaus.org/browse/MRELEASE-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-207:
Summary: Update JavaDoc @version tags on new release (was: Update JavaDoc
@versin tags on new release)
> Update JavaDoc @version tags on new release
> ---
>
> Key: MRELEASE-207
> URL: https://jira.codehaus.org/browse/MRELEASE-207
> Project: Maven 2.x Release Plugin
> Issue Type: New Feature
> Components: prepare
>Reporter: Roman Cerny
>Assignee: Robert Scholte
>Priority: Minor
>
> it would be nice to tell the maven-release-plugin, to change ALL the source
> files as well.
> i mean, it would be nice, if the @version javadoc tag would be automatically
> changed for each class.
> For e.g. when releasing version 1.7 and changing to 1.8-SNAPSHOT, all
> @version tags (for each class) should be changed to 1.8 (right after the
> release).
> So what i need would be the plugin to look at the ${pom.version} and the walk
> through all my packages (in my source folder) and change the @version javadoc
> tag in every single java class 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] (MASSEMBLY-91) Currently the assembly plugin renames SNAPSHOT dependencies to a date stamp ex. api-authorisation-4.00-20060502.150651-20.jar
[
https://jira.codehaus.org/browse/MASSEMBLY-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291558#comment-291558
]
Curtis Rueden commented on MASSEMBLY-91:
David: You can avoid using two separate configurations with the
"${dashClassifier?}" syntax:
${artifact.artifactId}-${artifact.baseVersion}${dashClassifier?}.${artifact.extension}
> Currently the assembly plugin renames SNAPSHOT dependencies to a date stamp
> ex. api-authorisation-4.00-20060502.150651-20.jar
> -
>
> Key: MASSEMBLY-91
> URL: https://jira.codehaus.org/browse/MASSEMBLY-91
> Project: Maven 2.x Assembly Plugin
> Issue Type: New Feature
>Affects Versions: 2.0.1
> Environment: Win XP, Java 1.5
>Reporter: Chris Stevenson
>Assignee: John Casey
> Fix For: 2.2-beta-1
>
>
> Currently the assembly plugin renames SNAPSHOT dependencies to a date stamp
> ex. api-authorisation-4.00-20060502.150651-20.jar. Would it be possible to
> offer a flag on the plugin so that this behaviour could be turned off and the
> file could remain as api-authorisation-SNAPSHOT.jar?
> The renaming of the files causes the files to become invalid when compiling
> native or CSharp binaries inside of maven.
> Thanks,
> Chris Stevenson
--
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] (MRELEASE-587) release:prepare ends up with FATAL ERROR (java.lang.OutOfMemoryError: Java heap space)
[
https://jira.codehaus.org/browse/MRELEASE-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-587.
---
Resolution: Won't Fix
Assignee: Robert Scholte
No, it is not possible to have a better message, we're talking about an
{{OutOfMemoryError}}, an _Error_ and not an _Exception_.
Let's quote
[java.lang.Error|http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Error.html]
{quote}
An Error is a subclass of Throwable that indicates serious problems that a
reasonable application should not try to catch. Most such errors are abnormal
conditions. The ThreadDeath error, though a "normal" condition, is also a
subclass of Error because most applications should not try to catch it.
A method is not required to declare in its throws clause any subclasses of
Error that might be thrown during the execution of the method but not caught,
since these errors are abnormal conditions that should never occur.
{quote}
The solution: add more memory to the JVM. This is actually a FAQ (just google)
and here's a hint:
[MAVEN_OPTS|http://maven.apache.org/download.html#Installation_Instructions]
> release:prepare ends up with FATAL ERROR (java.lang.OutOfMemoryError: Java
> heap space)
> --
>
> Key: MRELEASE-587
> URL: https://jira.codehaus.org/browse/MRELEASE-587
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: prepare
>Affects Versions: 2.0
> Environment: Windows XP
>Reporter: Teemu Lehto
>Assignee: Robert Scholte
>Priority: Minor
>
> OutOfMemoryError occurs if unit tests (for example) write a lot of debug
> messages to console.
> prepare works fine when logging level is something else than DEBUG
> Is it possible to somehow get better error message???
> Here is a stack trace:
> [INFO] Trace
> java.lang.OutOfMemoryError: Java heap space at
> java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99)
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393)
> at java.lang.StringBuffer.append(StringBuffer.java:225)
> at
> org.apache.maven.shared.release.ReleaseResult.appendOutput(ReleaseResult.java:85)
> at
> org.apache.maven.shared.release.exec.ForkedMavenExecutor.executeGoals(ForkedMavenExecutor.java:118)
> at
> org.apache.maven.shared.release.exec.ForkedMavenExecutor.executeGoals(ForkedMavenExecutor.java:126)
> at
> org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:59)
> at
> org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:42)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:136)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:227)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO]
>
> [INFO] Total time: 4 minutes 2 seconds
> [INFO] Finished at: Mon Aug 09 15:49:17 EEST 2010 [INFO] Final Memory:
> 16M/1016M [INFO]
>
[jira] (MRELEASE-724) Release plugin doesn't honor profiles defined in user settings
[
https://jira.codehaus.org/browse/MRELEASE-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MRELEASE-724.
-
Resolution: Duplicate
Duplicate of MNG-5224
> Release plugin doesn't honor profiles defined in user settings
> --
>
> Key: MRELEASE-724
> URL: https://jira.codehaus.org/browse/MRELEASE-724
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.2.2
>Reporter: Arnaud Heritier
>Priority: Critical
> Attachments: MRELEASE-724.log
>
>
> We tried to upgrade the release plugin from 2.2.1 to 2.2.2 and it broke our
> release.
> We don't define repositories (especially private ones) in our pom but in our
> developers settings (activated from command line or more often in
> activeProfiles)
> Releasing this project fails with :
> {code}
> arnaud@mbp-arnaud:~/Code/eXo/cloud-management (git:develop %)$ mvn
> release:prepare -DdryRun=true
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> ...
> [INFO] --- maven-release-plugin:2.2.2:prepare (default-cli) @
> cloud-management-parent ---
> [INFO] Resuming release from phase 'run-preparation-goals'
> [INFO] Executing preparation goals - since this is simulation mode it is
> running against the original project, not the rewritten ones
> [INFO] Executing goals 'clean verify'...
> [WARNING] Maven will be executed in interactive mode, but no input stream has
> been configured for this MavenInvoker instance.
> [INFO] [INFO] Scanning for projects...
> [INFO] [INFO]
>
> [INFO] [INFO] Reactor Build Order:
> ...
> [INFO] [INFO]
>
> [INFO] [INFO] Building eXo Cloud Management :: Parent 1.1-M4-SNAPSHOT
> [INFO] [INFO]
>
> ...
> [INFO] [INFO] --- maven-license-plugin:1.9.0:check (check-headers) @
> cloud-management-parent ---
> [INFO] [WARNING] The POM for
> org.exoplatform.cloud-management:cloud-build-tools:jar:0.1-M1 is missing, no
> dependency information available
> [INFO] [INFO]
>
> [INFO] [INFO] Reactor Summary:
> [INFO] [INFO]
> [INFO] [INFO] eXo Cloud Management :: Parent FAILURE
> [1.257s]
> ...
> [INFO] [INFO]
>
> [INFO] [INFO] BUILD FAILURE
> [INFO] [INFO]
>
> ...
> [INFO] [INFO]
>
> [INFO] [WARNING] The requested profile "exo-central" could not be activated
> because it does not exist.
> [INFO] [WARNING] The requested profile "local-properties" could not be
> activated because it does not exist.
> [INFO] [WARNING] The requested profile "exo-private" could not be activated
> because it does not exist.
> [INFO] [WARNING] The requested profile "exo-staging" could not be activated
> because it does not exist.
> [INFO] [ERROR] Failed to execute goal
> com.mycila.maven-license-plugin:maven-license-plugin:1.9.0:check
> (check-headers) on project cloud-management-parent: Execution check-headers
> of goal com.mycila.maven-license-plugin:maven-license-plugin:1.9.0:check
> failed: Plugin com.mycila.maven-license-plugin:maven-license-plugin:1.9.0 or
> one of its dependencies could not be resolved: Failure to find
> org.exoplatform.cloud-management:cloud-build-tools:jar:0.1-M1 in
> http://repository.exoplatform.org/public was cached in the local repository,
> resolution will not be reattempted until the update interval of exo-fr-mirror
> has elapsed or updates are forced -> [Help 1]
> [INFO] [ERROR]
> [INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [INFO] [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [INFO] [ERROR]
> [INFO] [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [INFO] [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] eXo Cloud Management :: Parent FAILURE [5.210s]
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> ...
> [INFO
[jira] (MRELEASE-297) release doesn't bump versions in properties to the next dev iteration
[ https://jira.codehaus.org/browse/MRELEASE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-297. --- Resolution: Fixed Fix Version/s: 2.2.2 Assignee: Benjamin Bentmann (was: Maria Odea Ching) Seems to be fixed by Benjamin with [rev. 1083092|http://svn.apache.org/viewvc?view=revision&revision=1083092], which is indeed version 2.2.2 It's a huge diff, so it's quite hard to pinpoint the exact lines. > release doesn't bump versions in properties to the next dev iteration > - > > Key: MRELEASE-297 > URL: https://jira.codehaus.org/browse/MRELEASE-297 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-6, 2.0-beta-7 >Reporter: Brian Fox >Assignee: Benjamin Bentmann > Fix For: 2.2.2 > > > Properties used as versions are correctly updated to the release version and > committed, but they are not bumped to the next snapshot after. -- 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] (MASSEMBLY-494) No way to set the directory mode for the base directory nor any implicitly created directory for zip assemblies
[ https://jira.codehaus.org/browse/MASSEMBLY-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291585#comment-291585 ] Arnaud de Bossoreille commented on MASSEMBLY-494: - It works, but I have the 493 issue which I suspect to be a bug (affects 2.3 too). And you did not mention the fact that in 2.2-beta-5, the directoryMode tag changed the permissions of files instead of directories. Was not a bug? Fortunately it seems to be fixed in 2.3. > No way to set the directory mode for the base directory nor any implicitly > created directory for zip assemblies > --- > > Key: MASSEMBLY-494 > URL: https://jira.codehaus.org/browse/MASSEMBLY-494 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-5 > Environment: Debian GNU/Linux >Reporter: Arnaud de Bossoreille >Assignee: John Casey > Attachments: assembly-test.zip > > > A sample maven project is attached to reproduce everything. I am trying to > generate a zip file with correct permissions (i.e. directories not writable > by everyone which I would say should not be too difficult). > If you run `mvn assembly:assembly` as is, you will have: > drwxrwxrwx ... assembly-test-1.0.0/ > drwxrwxrwx ... assembly-test-1.0.0/bin/ > -rw-r--r-- ... assembly-test-1.0.0/bin/assembly-test-1.0.0.jar > -rw-r--r-- ... assembly-test-1.0.0/bin/commons-lang-2.4.jar > drwxr-xr-x ... assembly-test-1.0.0/copyofsubdir/ > -rw-r--r-- ... assembly-test-1.0.0/copyofsubdir/file > I found no way to set the first two directories permissions. If you add the > two directoryMode tags, you will have: > drwxrwxrwx ... assembly-test-1.0.0/ > drwxrwxrwx ... assembly-test-1.0.0/bin/ > -rw-r--r-- ... assembly-test-1.0.0/bin/assembly-test-1.0.0.jar > -rw-r--r-- ... assembly-test-1.0.0/bin/commons-lang-2.4.jar > drwxr-xr-x ... assembly-test-1.0.0/copyofsubdir/ > -rwxrwxrwx ... assembly-test-1.0.0/copyofsubdir/file* > ... which is pretty much what I did NOT expect (a cut'n paste issue in the > code?). If you add both directoryMode and fileMode, you will have the same > results as the first iteration (see above). > Unfortunately I still cannot change the permissions of: > - the base directory (assembly-test-1.0.0) > - any directory that is not present on the file system (bin) > I looked a bit at the code and, as far as I can see, it may be linked to the > plexus zip archiver (although it may not be responsible for the bug) which > automatically adds parent directories but most probably with incorrect > permissions due to bad configuration. > I did not test with other assembly formats. > PS: yes I can do a simple tarball, and I will probably do that while waiting > for a patch. But I think it is important that you are aware of something > which may annoy more than one single user in the world. > Regards. -- 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] (MNG-2570) Maven needs to support multiple logging levels
[ https://jira.codehaus.org/browse/MNG-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] patrick garcia updated MNG-2570: Attachment: MNG-2570-maven-embedder.patch As a simple answer to this issue, you will find in the attached patch a new "-w" "--warinig" maven option. This set the log level to LOGGING_LEVEL_WARN The final solution for this issue may be cleverer. At least this patch allows setting ALL possible log level values. Integration test are ok. more over, I have tested it by checking the following commands: $M2_HOME/bin/mvn --help $M2_HOME/bin/mvn -w test $M2_HOME/bin/mvn --warning test Then I did a diff with the following commands: $M2_HOME/bin/mvn test $M2_HOME/bin/mvn -q test > Maven needs to support multiple logging levels > -- > > Key: MNG-2570 > URL: https://jira.codehaus.org/browse/MNG-2570 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Logging >Affects Versions: 2.0.4 >Reporter: Brian Fox > Fix For: Issues to be reviewed for 3.x > > Attachments: MNG-2570-maven-embedder.patch > > > The current logging levels are essentially verbose (default) and debug (-X). > We need a slightly less verbose output so that things like compiler warnings > and other output is actually visable to the developer. Currently it gets > buried in all the noise. -- 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
