[jira] Created: (MDEPLOY-94) Variables in the version element in pom.xml need to be expanded before deployment
Variables in the version element in pom.xml need to be expanded before
deployment
-
Key: MDEPLOY-94
URL: http://jira.codehaus.org/browse/MDEPLOY-94
Project: Maven 2.x Deploy Plugin
Issue Type: Bug
Reporter: Brian Jackson
We use an external tool to manage our releases (instead of
maven-release-plugin). The version in our pom.xml is declared as:
${build.number}
The actual version number is passed in during a release deployment on the
command line "mvn deploy -Dbuild.number=1.2.3"
The pom.xml is deployed literally without the variable replaced with the actual
value. This causes problems, in particular multi-module releases are
impossible since the parent pom can't be resolved properly as well as this
issue with Nexus https://issues.sonatype.org/browse/NEXUS-1552
I started digging into the code and see deployment is deferred to the
DefaultArtifactDeployer
http://maven.apache.org/ref/current/xref/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.html
Can I somehow install a custom ArtifactTransformation that expands these
variables before deployment? How would I install it in my builds? Would I
build it as a Plexus component and add it as a plugin dependency of
maven-deploy-plugin? If someone could give me a little guidance I'd be happy
to implement it, test it and submit a patch.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4023) Profiles from parent POM are injected multiple times if parent is part of reactor build
[
http://jira.codehaus.org/browse/MNG-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4023.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.1.0-M2
2.0.11
Fixed in [r741777|http://svn.eu.apache.org/viewvc?view=rev&revision=741777] and
[r741779|http://svn.eu.apache.org/viewvc?view=rev&revision=741779].
> Profiles from parent POM are injected multiple times if parent is part of
> reactor build
> ---
>
> Key: MNG-4023
> URL: http://jira.codehaus.org/browse/MNG-4023
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.9, 2.1.0-M1
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 2.0.11, 2.1.0-M2
>
>
> The test project provided for MNG-4022 depends on a bug in the project
> builder to trigger to actual {{Xpp3Dom}} merging issue. When the parent POM
> is part of the reactor, it will be added to the project cache and its model
> already includes active profiles. When the child is build next it retrieves
> the previously created parent model from the cache to assemble the lineage
> and injects the active profiles again. This causes discrepancies in the
> effective model if profile injection has additive effects on the model.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-180) Missing url tag in (parent) pom make it ignore the site inheritence system
[ http://jira.codehaus.org/browse/MSITE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Falkenberg updated MSITE-180: - Attachment: multi-module-project-with-inheritance.zip Yes, you are right, the inheritance mechanism seems to work now. I've tried it using the 2.0 snapshot and have attached a sample project with no URL:s but with an inherited menu that now seems to work. This bug should be closed. > Missing url tag in (parent) pom make it ignore the site inheritence system > -- > > Key: MSITE-180 > URL: http://jira.codehaus.org/browse/MSITE-180 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.0-beta-5 >Reporter: Geoffrey De Smet > Attachments: multi-module-project-with-inheritance.zip, > multi-module-project.zip > > > IF none of the poms (module or parent) don't have an url tag, like this: > > ... > ... > ... > > (It doesn't matter if they have url tags in scm, distribution etc) > THEN site inheritence quitely isn't applied, for example in the parent's > site.xml > > http://www.mavenblogs.org/"/> > > isn't inherited in the childe module's site. > proposed solutions: > - or fix it :) > - or document this wanted behaviour in the site plugin's documentation at > http://maven.apache.org/plugins/maven-site-plugin/howto.html > with something like > "Site inheritence only works if you have a url tag in your parent pom." > because this can cost people many hours - it did for me > But once site inheritence works, it's very nice though :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4023) Profiles from parent POM are injected multiple times if parent is part of reactor build
Profiles from parent POM are injected multiple times if parent is part of
reactor build
---
Key: MNG-4023
URL: http://jira.codehaus.org/browse/MNG-4023
Project: Maven 2
Issue Type: Bug
Components: Profiles
Affects Versions: 2.1.0-M1, 2.0.9
Reporter: Benjamin Bentmann
The test project provided for MNG-4022 depends on a bug in the project builder
to trigger to actual {{Xpp3Dom}} merging issue. When the parent POM is part of
the reactor, it will be added to the project cache and its model already
includes active profiles. When the child is build next it retrieves the
previously created parent model from the cache to assemble the lineage and
injects the active profiles again. This causes discrepancies in the effective
model if profile injection has additive effects on the model.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCLEAN-39) followSymLinks is always set to true
[ http://jira.codehaus.org/browse/MCLEAN-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bouiaw updated MCLEAN-39: - Attachment: test-clean.zip clean.txt You will find attached the output of mvn -X clean, and a test case to reproduce the issue. Run the sh script and next run mvn clean to see the issue : /tmp/test/toto is deleted with default configuration ! > followSymLinks is always set to true > > > Key: MCLEAN-39 > URL: http://jira.codehaus.org/browse/MCLEAN-39 > Project: Maven 2.x Clean Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.9, Linux >Reporter: Bouiaw >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.4 > > Attachments: clean.txt, test-clean.zip > > > From my tests, followSymLinks that is used to delete the content of symlink > when it is set to true, is not taken in account. > It should be a regression caused by http://jira.codehaus.org/browse/MCLEAN-28 > This is a blocker bug, since it could delete all the filesystem easily, and > there is no workaround. Even when I set followSymLinks explicitley to false, > Maven clean 2.3 follow symlinks and delete its contents. > To reproduce : > Declare 2.3 clean plugin in your pom > mkdir /tmp/test > touch /tmp/test/foo > symlink -s /tmp/test /myproject/target/test > cd /myproject > mvn clean > After runnig that, /tmp/test is empty ! > If it is confirmed, I would recommand to release quickly a 2.4 version with a > fix, since in is REALLY dansgerous. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-435) Maven Surefire should set system property java.class.path or something like surefire.java.class.path
[ http://jira.codehaus.org/browse/SUREFIRE-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164285#action_164285 ] jmfj edited comment on SUREFIRE-435 at 2/6/09 1:09 PM: --- I have the exact same problem Added comment to [SUREFIRE-510|http://jira.codehaus.org/browse/SUREFIRE-510?focusedCommentId=164278&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_164278] Seems like the issue is still on. was (Author: mars): Added comment to [SUREFIRE-510|http://jira.codehaus.org/browse/SUREFIRE-510?focusedCommentId=164278&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_164278] Seems like the issue is still on. > Maven Surefire should set system property java.class.path or something like > surefire.java.class.path > > > Key: SUREFIRE-435 > URL: http://jira.codehaus.org/browse/SUREFIRE-435 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.4 >Reporter: Martin Burger > > In some of my test cases I fork another JVM instance that must have the same > classpath as the executed test. I use the system property java.class.path to > get the classpath. > In Eclipse it works as expected, the system property java.class.path holds > all the dependencies. But if I use Maven to run the tests, that system > property holds just > '/Users/mburger/bin/maven2/boot/classworlds-1.1.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/.compatibility/14compatibility.jar'. > AFAIK the system property java.class.path is read only, so Surefire cannot > set it. But it would be very nice to have some fall back like > surefire.java.class.path. In my test cases I could use that system property > as fall back when java.class.path does not contain the expected JAR files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-435) Maven Surefire should set system property java.class.path or something like surefire.java.class.path
[ http://jira.codehaus.org/browse/SUREFIRE-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164285#action_164285 ] jmfj edited comment on SUREFIRE-435 at 2/6/09 1:07 PM: --- Added comment to [SUREFIRE-510|http://jira.codehaus.org/browse/SUREFIRE-510?focusedCommentId=164278&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_164278] Seems like the issue is still on. was (Author: mars): Added comment to [SUREFIRE-510~http://jira.codehaus.org/browse/SUREFIRE-510?focusedCommentId=164278&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_164278] Seems like the issue is still on. > Maven Surefire should set system property java.class.path or something like > surefire.java.class.path > > > Key: SUREFIRE-435 > URL: http://jira.codehaus.org/browse/SUREFIRE-435 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.4 >Reporter: Martin Burger > > In some of my test cases I fork another JVM instance that must have the same > classpath as the executed test. I use the system property java.class.path to > get the classpath. > In Eclipse it works as expected, the system property java.class.path holds > all the dependencies. But if I use Maven to run the tests, that system > property holds just > '/Users/mburger/bin/maven2/boot/classworlds-1.1.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/.compatibility/14compatibility.jar'. > AFAIK the system property java.class.path is read only, so Surefire cannot > set it. But it would be very nice to have some fall back like > surefire.java.class.path. In my test cases I could use that system property > as fall back when java.class.path does not contain the expected JAR files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-435) Maven Surefire should set system property java.class.path or something like surefire.java.class.path
[ http://jira.codehaus.org/browse/SUREFIRE-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164285#action_164285 ] jmfj commented on SUREFIRE-435: --- Added comment to [SUREFIRE-510~http://jira.codehaus.org/browse/SUREFIRE-510?focusedCommentId=164278&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_164278] Seems like the issue is still on. > Maven Surefire should set system property java.class.path or something like > surefire.java.class.path > > > Key: SUREFIRE-435 > URL: http://jira.codehaus.org/browse/SUREFIRE-435 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.4 >Reporter: Martin Burger > > In some of my test cases I fork another JVM instance that must have the same > classpath as the executed test. I use the system property java.class.path to > get the classpath. > In Eclipse it works as expected, the system property java.class.path holds > all the dependencies. But if I use Maven to run the tests, that system > property holds just > '/Users/mburger/bin/maven2/boot/classworlds-1.1.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/.compatibility/14compatibility.jar'. > AFAIK the system property java.class.path is read only, so Surefire cannot > set it. But it would be very nice to have some fall back like > surefire.java.class.path. In my test cases I could use that system property > as fall back when java.class.path does not contain the expected JAR files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MNG-2720) Multiproject dependencies not accurate for project.compileClasspathElements when run from root project
[ http://jira.codehaus.org/browse/MNG-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-2720 started by John Casey. > Multiproject dependencies not accurate for project.compileClasspathElements > when run from root project > -- > > Key: MNG-2720 > URL: http://jira.codehaus.org/browse/MNG-2720 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.4 >Reporter: Jeff Genender >Assignee: John Casey > Fix For: 2.1.0-M3 > > > In a plugin I wrote (jspc), needs the dependency jars. It asks for this with > the request for the project.compileClasspathElements. In a multiproject > environment, when each project is built individually, it seems correct. > Example (when run with -X ina subproject dir) showing classpath: > /Users/mbp/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar > /Users/mbp/.m2/repository/taglibs/standard/1.1.2/standard-1.1.2.jar > /Users/mbp/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar > /Users/mbp/.m2/repository/tldtestapp/testexttld/1/testexttld-1.jar > <-NOTICE HERE - THIS IS AN ARTIFACT FROM ANOTHER SUBPROJECT > /Users/mbp/.m2/repository/javax/servlet/jstl/1.1.2/jstl-1.1.2.jar] > When it is run from the Top level/Root project...here is the output: > Users/mbp/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar > /Users/mbp/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar > /Users/mbp/.m2/repository/taglibs/standard/1.1.2/standard-1.1.2.jar > /Users/mbp/Desktop/jsp-example/TestTldProject/target/classes >INSTEAD > /Users/mbp/.m2/repository/javax/servlet/jstl/1.1.2/jstl-1.1.2.jar] > The second project has a dependency on the testexttld-1.jar because it > contains tag libs which must be wrapped in a jar. When run from a top level, > it uses the other project's classes directory instead of the JAR artifact. > WIth JSPC and taglibs, this makes it so it cannot work. If I have a > dependency on a jar, that jar should be the dependency as expected and not a > classes directory. For full explanation and example see here: > http://jira.codehaus.org/browse/MJSPC-4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work stopped: (MNG-3530) Regression: Properties get resolved before the LifeCycle is Forked.
[
http://jira.codehaus.org/browse/MNG-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MNG-3530 stopped by John Casey.
> Regression: Properties get resolved before the LifeCycle is Forked.
> ---
>
> Key: MNG-3530
> URL: http://jira.codehaus.org/browse/MNG-3530
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Nick Pellow
>Assignee: John Casey
> Fix For: 2.1.0-M3
>
> Attachments: MNG-3530.tar.gz, MNG-3530.zip
>
>
> Since Maven 2.0.9 -- If a plugin uses a forked lifecycle, then the project
> properties are resolved by maven before the lifecycle is forked.
> This means that the forked lifecycle has the non-forked lifecycle's values.
> This was not the case in maven prior to version 2.0.9, where properties were
> resolved at a much later time.
> For example - the attached sample project uses the Clover plugin with the
> xdoclet plugin. When {code}mvn clean install{code} is run under *Maven-2.0.8*
> you can see the following output:
> {code}
> [INFO] [xdoclet:xdoclet {execution: default}]
> [INFO] Initializing DocletTasks!!!
> [INFO] Executing tasks
> [echo] Build Dir: ${project.build.directory}/test.clover
> [INFO] Executed tasks
> {code}
> whilst *Maven 2.0.9* outputs:
> {code}
> [INFO] [xdoclet:xdoclet {execution: default}]
> [INFO] Initializing DocletTasks!!!
> [INFO] Executing tasks
> [mkdir] Created dir: /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target
> [touch] Creating
> /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target/test.clover
> [echo] Build Dir:
> /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target/test.clover
> [INFO] Executed tasks
> [INFO] [resources:resources]
> {code}
> The fact the ${project.build.directory} property has been expanded already
> under 2.0.9, means that the forked lifecycle has the same value for that
> property.
> This new behavior will break any plugin which uses a forked lifecycle.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3530) Regression: Properties get resolved before the LifeCycle is Forked.
[
http://jira.codehaus.org/browse/MNG-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164281#action_164281
]
John Casey commented on MNG-3530:
-
I can't get the attached sample project to fail. I'm using JDK 1.4 with Maven
2.1.0-M1, and had to modify the POM to include the following repository entry:
{code:xml}
atlassian
http://repository.atlassian.com/maven2
{code}
but it clearly shows the xdoclet plugin creating the target/clover/test.clover
file...
Can someone tell me how I can reproduce this problem? BTW, the Maven core ITs
are all passing here for this issue, too...
> Regression: Properties get resolved before the LifeCycle is Forked.
> ---
>
> Key: MNG-3530
> URL: http://jira.codehaus.org/browse/MNG-3530
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Nick Pellow
>Assignee: John Casey
> Fix For: 2.1.0-M3
>
> Attachments: MNG-3530.tar.gz, MNG-3530.zip
>
>
> Since Maven 2.0.9 -- If a plugin uses a forked lifecycle, then the project
> properties are resolved by maven before the lifecycle is forked.
> This means that the forked lifecycle has the non-forked lifecycle's values.
> This was not the case in maven prior to version 2.0.9, where properties were
> resolved at a much later time.
> For example - the attached sample project uses the Clover plugin with the
> xdoclet plugin. When {code}mvn clean install{code} is run under *Maven-2.0.8*
> you can see the following output:
> {code}
> [INFO] [xdoclet:xdoclet {execution: default}]
> [INFO] Initializing DocletTasks!!!
> [INFO] Executing tasks
> [echo] Build Dir: ${project.build.directory}/test.clover
> [INFO] Executed tasks
> {code}
> whilst *Maven 2.0.9* outputs:
> {code}
> [INFO] [xdoclet:xdoclet {execution: default}]
> [INFO] Initializing DocletTasks!!!
> [INFO] Executing tasks
> [mkdir] Created dir: /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target
> [touch] Creating
> /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target/test.clover
> [echo] Build Dir:
> /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target/test.clover
> [INFO] Executed tasks
> [INFO] [resources:resources]
> {code}
> The fact the ${project.build.directory} property has been expanded already
> under 2.0.9, means that the forked lifecycle has the same value for that
> property.
> This new behavior will break any plugin which uses a forked lifecycle.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-510) surefire.test.class.path is not set when forkMode is always
[
http://jira.codehaus.org/browse/SUREFIRE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164278#action_164278
]
jmfj edited comment on SUREFIRE-510 at 2/6/09 12:10 PM:
I am still seeing this issue on 2.4.3:
e.g, for configuration
{code:title=pom.xml|borderStyle=solid}
-Xmx512m
always
true
{code}
The following unit test fails ---
{code:title=TestSurefire.java|borderStyle=solid}
public void testSurefireClassPath() {
final String surefireClassPathPropertyName = "surefire.test.class.path";
final String javaClassPathPropertyName = "java.class.path";
final String surefireClassPath = System
.getProperty(surefireClassPathPropertyName);
final String javaClassPath = System
.getProperty(javaClassPathPropertyName);
System.out.println(surefireClassPathPropertyName + "="
+ surefireClassPath);
System.out.println(javaClassPathPropertyName + "=" + javaClassPath);
assertNotNull(System.getProperty(surefireClassPathPropertyName));
assertNotNull(System.getProperty(javaClassPathPropertyName));
}
{code}
was (Author: mars):
I am still seeing this issue on 2.4.3:
e.g, for configuration
{code:title=pom.xml|borderStyle=solid}
-Xmx512m
always
true
{code}
The following unit test fails ---
{code:title=TestSurefire.java|borderStyle=solid}
public void testSurefireClassPath() {
final String surefireClassPathPropertyName = "surefire.test.class.path";
final String javaClassPathPropertyName = "java.class.path";
final String surefireClassPath = System
.getProperty(surefireClassPathPropertyName);
final String javaClassPath = System
.getProperty(javaClassPathPropertyName);
System.out.println(surefireClassPathPropertyName + "="
+ surefireClassPath);
System.out.println(javaClassPathPropertyName + "=" + javaClassPath);
assertNotNull(System.getProperty(surefireClassPathPropertyName));
assertNotNull(System.getProperty(javaClassPathPropertyName));
}
{code}
> surefire.test.class.path is not set when forkMode is always
> ---
>
> Key: SUREFIRE-510
> URL: http://jira.codehaus.org/browse/SUREFIRE-510
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.4.2
>Reporter: Carlo de Wolf
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-510) surefire.test.class.path is not set when forkMode is always
[
http://jira.codehaus.org/browse/SUREFIRE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164278#action_164278
]
jmfj commented on SUREFIRE-510:
---
I am still seeing this issue on 2.4.3:
e.g, for configuration
{code:title=pom.xml|borderStyle=solid}
-Xmx512m
always
true
{code}
The following unit test fails ---
{code:title=TestSurefire.java|borderStyle=solid}
public void testSurefireClassPath() {
final String surefireClassPathPropertyName = "surefire.test.class.path";
final String javaClassPathPropertyName = "java.class.path";
final String surefireClassPath = System
.getProperty(surefireClassPathPropertyName);
final String javaClassPath = System
.getProperty(javaClassPathPropertyName);
System.out.println(surefireClassPathPropertyName + "="
+ surefireClassPath);
System.out.println(javaClassPathPropertyName + "=" + javaClassPath);
assertNotNull(System.getProperty(surefireClassPathPropertyName));
assertNotNull(System.getProperty(javaClassPathPropertyName));
}
{code}
> surefire.test.class.path is not set when forkMode is always
> ---
>
> Key: SUREFIRE-510
> URL: http://jira.codehaus.org/browse/SUREFIRE-510
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.4.2
>Reporter: Carlo de Wolf
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-510) surefire.test.class.path is not set when forkMode is always
[
http://jira.codehaus.org/browse/SUREFIRE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164278#action_164278
]
jmfj edited comment on SUREFIRE-510 at 2/6/09 12:11 PM:
I am still seeing this issue on 2.4.3:
e.g, for configuration
{code:title=pom.xml|borderStyle=solid}
-Xmx512m
always
{code}
The following unit test fails ---
{code:title=TestSurefire.java|borderStyle=solid}
public void testSurefireClassPath() {
final String surefireClassPathPropertyName = "surefire.test.class.path";
final String javaClassPathPropertyName = "java.class.path";
final String surefireClassPath = System
.getProperty(surefireClassPathPropertyName);
final String javaClassPath = System
.getProperty(javaClassPathPropertyName);
System.out.println(surefireClassPathPropertyName + "="
+ surefireClassPath);
System.out.println(javaClassPathPropertyName + "=" + javaClassPath);
assertNotNull(System.getProperty(surefireClassPathPropertyName));
assertNotNull(System.getProperty(javaClassPathPropertyName));
}
{code}
was (Author: mars):
I am still seeing this issue on 2.4.3:
e.g, for configuration
{code:title=pom.xml|borderStyle=solid}
-Xmx512m
always
true
{code}
The following unit test fails ---
{code:title=TestSurefire.java|borderStyle=solid}
public void testSurefireClassPath() {
final String surefireClassPathPropertyName = "surefire.test.class.path";
final String javaClassPathPropertyName = "java.class.path";
final String surefireClassPath = System
.getProperty(surefireClassPathPropertyName);
final String javaClassPath = System
.getProperty(javaClassPathPropertyName);
System.out.println(surefireClassPathPropertyName + "="
+ surefireClassPath);
System.out.println(javaClassPathPropertyName + "=" + javaClassPath);
assertNotNull(System.getProperty(surefireClassPathPropertyName));
assertNotNull(System.getProperty(javaClassPathPropertyName));
}
{code}
> surefire.test.class.path is not set when forkMode is always
> ---
>
> Key: SUREFIRE-510
> URL: http://jira.codehaus.org/browse/SUREFIRE-510
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.4.2
>Reporter: Carlo de Wolf
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-64) "mvn clean install" crashes with java.lang.OutOfMemoryError: PermGen space after update to java 1.6.0_04
[ http://jira.codehaus.org/browse/MCOMPILER-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164275#action_164275 ] werner mueller commented on MCOMPILER-64: - the docs mention some options to adjust memory settings for the compiler: http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-with-memory-enhancements.html but i dont know if its working :) > "mvn clean install" crashes with java.lang.OutOfMemoryError: PermGen space > after update to java 1.6.0_04 > > > Key: MCOMPILER-64 > URL: http://jira.codehaus.org/browse/MCOMPILER-64 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Maven version: 2.0.8 > Java version: 1.6.0_04 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Joern Huxhorn >Priority: Critical > > After upgrading to java 1.6.0_04 i can't build a big multi-module project > anymore. > java.exe keeps allocating more and more memory (ca. 260MB) until it crashes > with an error like the following: > Failure executing javac, but could not parse the error: > The system is out of resources. > Consult the following stack trace for details. > java.lang.OutOfMemoryError: PermGen space > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at > org.codehaus.plexus.compiler.javac.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:56) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at com.sun.tools.javac.comp.Annotate.(Annotate.java:52) > at com.sun.tools.javac.comp.Annotate.instance(Annotate.java:36) > at com.sun.tools.javac.jvm.ClassReader.(ClassReader.java:215) > at com.sun.tools.javac.jvm.ClassReader.instance(ClassReader.java:168) > at com.sun.tools.javac.main.JavaCompiler.(JavaCompiler.java:293) > at > com.sun.tools.javac.main.JavaCompiler.instance(JavaCompiler.java:72) > at com.sun.tools.javac.main.Main.compile(Main.java:340) > at com.sun.tools.javac.main.Main.compile(Main.java:279) > at com.sun.tools.javac.main.Main.compile(Main.java:270) > at com.sun.tools.javac.Main.compile(Main.java:87) > 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.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:420) > at > org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:141) > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:493) > at > org.apache.maven.plugin.TestCompilerMojo.execute(TestCompilerMojo.java:102) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > Executing the same command with this setup > Maven version: 2.0.8 > Java version: 1.5.0_13 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" > works perfectly. java.exe allocates at most 110MB. > Increasing the PermGen space using -XX:MaxPermSize=512M didn't help, either... > This is probably a java regression introduced with j6u4 but it could also be > a problem in org.codehaus.plexus.compiler.javac.IsolatedClassLoader. > I didn't experience any other problems with the new java version, so far. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3553) cannot resolve dependency with scope import
[
http://jira.codehaus.org/browse/MNG-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164269#action_164269
]
Jacques Morel commented on MNG-3553:
Jason,
Thanks for responding so fast. I would be more than happy to help in any way I
can.
However have you guys looked at the attached project and the [associated
steps|http://jira.codehaus.org/browse/MNG-3553?focusedCommentId=152108&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_152108]
to reproduce the problem?
I can reproduce it without problem. I get this output which matches John Crim
[comment|http://jira.codehaus.org/browse/MNG-3553?focusedCommentId=160542&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_160542]
and Thomas Diesler's the original reporter.
This is the error message I get:
{noformat}
$ mvn install
[INFO] Scanning for projects...
[INFO]
[INFO] Building test-depends-on-importer
[INFO]task-segment: [install]
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] snapshot mng-3553:test-importer:1.0-SNAPSHOT: checking for updates from
public
[INFO] snapshot mng-3553:test-importer:1.0-SNAPSHOT: checking for updates from
public-snapshots
Downloading:
http://liberty.sabre.com/nexus/content/groups/public-snapshots/mng-3553/test-importer/1.0-SNAPSHOT/test-importer-1.0-20090206.171302-2.pom
1K downloaded
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: mng-3553:test-parent
Reason: POM 'mng-3553:test-parent' not found in repository: Unable to download
the artifact from any repository
mng-3553:test-parent:pom:1.0-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
for project mng-3553:test-parent
{noformat}
I used our team nexus repository to deploy in so I had to add a distribution
section in all pom files:
{code}
nexus
liberty nexus proxy
http://liberty.sabre.com/nexus/content/repositories/releases
snapshot nexus
liberty snapshot nexus proxy
http://liberty.sabre.com/nexus/content/repositories/snapshots
{code}
My effective settings are
{code}
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/settings-1.0.0.xsd">
C:\Documents and
Settings\SG0426575\.m2\repository
false
true
sg0XX
80
www-ad-proxy.sabre.com
*.sabre.com
public-snapshots
Liberty Nexus Mirror
http://liberty.sabre.com/nexus/content/groups/public-snapshots
nexus-public-snapshots
public
Liberty Nexus Mirror
http://liberty.sabre.com/nexus/content/groups/public
nexus
public
http://public
public-snapshots
http://public-snapshots
false
public
http://public
false
public-snapshots
http://public-snapshots
liberty-profile
liberty-profile
{code}
> cannot resolve dependency with scope import
> ---
>
> Key: MNG-3553
> URL: http://jira.codehaus.org/browse/MNG-3553
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9
>Reporter: Thomas Diesler
> Fix For: 2.0.11
>
> Attachments: mng-3553.zip
>
>
> This pom when added as a dependency of another project does not see
> repository http://snapshots.jboss.org/maven2
>
>
>
>
> org.jboss.jbossas
> jboss-as-component-matrix
> ${jboss.version}
> pom
> import
>
>
>
> with effective settings
> [tdies...@tddell trunk]$ mvn help:effective-settings
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] JBoss Web Services - Stack CXF
> [INFO] JBoss Web Services - Stack CXF Management
> [INFO] JBoss Web Services - Stack CXF Runtime Server
> [INFO] JBoss Web Services - Stack CXF Runtime Client
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO]
>
>
[jira] Work started: (MNG-3530) Regression: Properties get resolved before the LifeCycle is Forked.
[
http://jira.codehaus.org/browse/MNG-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MNG-3530 started by John Casey.
> Regression: Properties get resolved before the LifeCycle is Forked.
> ---
>
> Key: MNG-3530
> URL: http://jira.codehaus.org/browse/MNG-3530
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Nick Pellow
>Assignee: John Casey
> Fix For: 2.1.0-M3
>
> Attachments: MNG-3530.tar.gz, MNG-3530.zip
>
>
> Since Maven 2.0.9 -- If a plugin uses a forked lifecycle, then the project
> properties are resolved by maven before the lifecycle is forked.
> This means that the forked lifecycle has the non-forked lifecycle's values.
> This was not the case in maven prior to version 2.0.9, where properties were
> resolved at a much later time.
> For example - the attached sample project uses the Clover plugin with the
> xdoclet plugin. When {code}mvn clean install{code} is run under *Maven-2.0.8*
> you can see the following output:
> {code}
> [INFO] [xdoclet:xdoclet {execution: default}]
> [INFO] Initializing DocletTasks!!!
> [INFO] Executing tasks
> [echo] Build Dir: ${project.build.directory}/test.clover
> [INFO] Executed tasks
> {code}
> whilst *Maven 2.0.9* outputs:
> {code}
> [INFO] [xdoclet:xdoclet {execution: default}]
> [INFO] Initializing DocletTasks!!!
> [INFO] Executing tasks
> [mkdir] Created dir: /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target
> [touch] Creating
> /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target/test.clover
> [echo] Build Dir:
> /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target/test.clover
> [INFO] Executed tasks
> [INFO] [resources:resources]
> {code}
> The fact the ${project.build.directory} property has been expanded already
> under 2.0.9, means that the forked lifecycle has the same value for that
> property.
> This new behavior will break any plugin which uses a forked lifecycle.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JXR-10) Create a named anchor for each symbol like Javadoc does
[ http://jira.codehaus.org/browse/JXR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164263#action_164263 ] Matthew Beermann commented on JXR-10: - This issue hasn't had any updates in a long time; any progress? We have a regulatory requirement to link each of our functional requirements to one or more test cases, and as the reporter said, line numbers tend to be very brittle... > Create a named anchor for each symbol like Javadoc does > --- > > Key: JXR-10 > URL: http://jira.codehaus.org/browse/JXR-10 > Project: Maven JXR > Issue Type: Improvement > Components: jxr >Reporter: Laurent Caillette >Priority: Minor > > I want to reference source code from XDoc. By now I'm writing a link like > this: > method here > The problem is, my link can lead to a wrong place just after a few cosmetic > changes in source code. Of course, automatic link check will not guess the > link went wrong. > It would be nice to generate named anchors in XRef the same way Javadoc does, > supporting a link like this from XDoc: > method here > Another way to achieve the same result would be to parse Java comments to > find a special expression to be transformed in a named anchor, but the > Javadoc way seems more straightforward. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3004) Allow build lifecycle to execute tasks in parallel
[ http://jira.codehaus.org/browse/MNG-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3004: Fix Version/s: (was: 2.1.0-M3) 2.2.0-M1 We don't have code in place to do file locking in the local repository, nor do we have a design for this...I can't see how we'll get this done ahead of 2.2 at this point. > Allow build lifecycle to execute tasks in parallel > -- > > Key: MNG-3004 > URL: http://jira.codehaus.org/browse/MNG-3004 > Project: Maven 2 > Issue Type: Improvement > Components: Bootstrap & Build, General, Performance >Affects Versions: 2.0.6 >Reporter: Nigel Magnay > Fix For: 2.2.0-M1 > > Attachments: parallel-builds.patch > > > One of the great advantages with maven over scripted build environments is > that it can calculate the dependencies of the build, and it could execute > items that are independent of each other in parallel. > Unfortunately it currently doesn't do this, which would be a big win over > tools such as 'ant'. It also means that multicore machines have lots of idle > capacity when running a serial build that could be utilised. > I had a quick shot at seeing what might be required. Bear in mind this is the > first time I have looked at maven internally, and I was just trying to feel > my way around and build a POC. I got some of the way there, but my build > threads don't seem to have the correct classpath - I think this is something > to do with plexus / classworlds - but I don't know enough. > It'd be great to get this feature in a future version, or a way of running my > hack (figuring out why in a thread has not the plexus stuff) in the interim. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3995) Configuration Property Lost In Join of PluginManagement/Plugin
[ http://jira.codehaus.org/browse/MNG-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell closed MNG-3995. - Resolution: Fixed > Configuration Property Lost In Join of PluginManagement/Plugin > -- > > Key: MNG-3995 > URL: http://jira.codehaus.org/browse/MNG-3995 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 3.0-alpha-2 >Reporter: Shane Isbell >Assignee: Shane Isbell > Fix For: 3.0-alpha-3 > > > If a pluginManagement section contains an execution/configuration/, > and is joined with a plugin, then one only property is retained. For example: > > > > > becomes: > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCLEAN-39) followSymLinks is always set to true
[ http://jira.codehaus.org/browse/MCLEAN-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164245#action_164245 ] Brian Fox commented on MCLEAN-39: - A quick scan of the code shows everything in order. Can you include output of "mvn clean -X" ? > followSymLinks is always set to true > > > Key: MCLEAN-39 > URL: http://jira.codehaus.org/browse/MCLEAN-39 > Project: Maven 2.x Clean Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.9, Linux >Reporter: Bouiaw >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.4 > > > From my tests, followSymLinks that is used to delete the content of symlink > when it is set to true, is not taken in account. > It should be a regression caused by http://jira.codehaus.org/browse/MCLEAN-28 > This is a blocker bug, since it could delete all the filesystem easily, and > there is no workaround. Even when I set followSymLinks explicitley to false, > Maven clean 2.3 follow symlinks and delete its contents. > To reproduce : > Declare 2.3 clean plugin in your pom > mkdir /tmp/test > touch /tmp/test/foo > symlink -s /tmp/test /myproject/target/test > cd /myproject > mvn clean > After runnig that, /tmp/test is empty ! > If it is confirmed, I would recommand to release quickly a 2.4 version with a > fix, since in is REALLY dansgerous. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCLEAN-39) followSymLinks is always set to true
[ http://jira.codehaus.org/browse/MCLEAN-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MCLEAN-39: Fix Version/s: 2.4 > followSymLinks is always set to true > > > Key: MCLEAN-39 > URL: http://jira.codehaus.org/browse/MCLEAN-39 > Project: Maven 2.x Clean Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.9, Linux >Reporter: Bouiaw >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.4 > > > From my tests, followSymLinks that is used to delete the content of symlink > when it is set to true, is not taken in account. > It should be a regression caused by http://jira.codehaus.org/browse/MCLEAN-28 > This is a blocker bug, since it could delete all the filesystem easily, and > there is no workaround. Even when I set followSymLinks explicitley to false, > Maven clean 2.3 follow symlinks and delete its contents. > To reproduce : > Declare 2.3 clean plugin in your pom > mkdir /tmp/test > touch /tmp/test/foo > symlink -s /tmp/test /myproject/target/test > cd /myproject > mvn clean > After runnig that, /tmp/test is empty ! > If it is confirmed, I would recommand to release quickly a 2.4 version with a > fix, since in is REALLY dansgerous. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCLEAN-39) followSymLinks is always set to true
[ http://jira.codehaus.org/browse/MCLEAN-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164242#action_164242 ] Bouiaw commented on MCLEAN-39: -- The only workaround I have found is to use 2.1.1 release. > followSymLinks is always set to true > > > Key: MCLEAN-39 > URL: http://jira.codehaus.org/browse/MCLEAN-39 > Project: Maven 2.x Clean Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.9, Linux >Reporter: Bouiaw >Priority: Blocker > > From my tests, followSymLinks that is used to delete the content of symlink > when it is set to true, is not taken in account. > It should be a regression caused by http://jira.codehaus.org/browse/MCLEAN-28 > This is a blocker bug, since it could delete all the filesystem easily, and > there is no workaround. Even when I set followSymLinks explicitley to false, > Maven clean 2.3 follow symlinks and delete its contents. > To reproduce : > Declare 2.3 clean plugin in your pom > mkdir /tmp/test > touch /tmp/test/foo > symlink -s /tmp/test /myproject/target/test > cd /myproject > mvn clean > After runnig that, /tmp/test is empty ! > If it is confirmed, I would recommand to release quickly a 2.4 version with a > fix, since in is REALLY dansgerous. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCLEAN-39) followSymLinks is always set to true
followSymLinks is always set to true Key: MCLEAN-39 URL: http://jira.codehaus.org/browse/MCLEAN-39 Project: Maven 2.x Clean Plugin Issue Type: Bug Affects Versions: 2.3 Environment: Maven 2.0.9, Linux Reporter: Bouiaw Priority: Blocker >From my tests, followSymLinks that is used to delete the content of symlink >when it is set to true, is not taken in account. It should be a regression caused by http://jira.codehaus.org/browse/MCLEAN-28 This is a blocker bug, since it could delete all the filesystem easily, and there is no workaround. Even when I set followSymLinks explicitley to false, Maven clean 2.3 follow symlinks and delete its contents. To reproduce : Declare 2.3 clean plugin in your pom mkdir /tmp/test touch /tmp/test/foo symlink -s /tmp/test /myproject/target/test cd /myproject mvn clean After runnig that, /tmp/test is empty ! If it is confirmed, I would recommand to release quickly a 2.4 version with a fix, since in is REALLY dansgerous. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3719) [regression] plugin execution ordering no longer POM ordered in 2.0.9
[
http://jira.codehaus.org/browse/MNG-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164239#action_164239
]
Torben S. Giesselmann commented on MNG-3719:
Exactly, the problem came from from merging multiple plugin declarations into
one. I still think the docs should be updated, though.
> [regression] plugin execution ordering no longer POM ordered in 2.0.9
> -
>
> Key: MNG-3719
> URL: http://jira.codehaus.org/browse/MNG-3719
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.9, 2.0.10, 2.1.0-M1
> Environment: Maven 2.0.9, java version "1.5.0_13" Java(TM) 2 Runtime
> Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM)
> Client VM (build 1.5.0_13-120, mixed mode, sharing), OS X 10.4
>Reporter: Gary S. Weaver
>Assignee: Brett Porter
>Priority: Critical
> Fix For: 2.0.11, 2.1.0-M2
>
> Attachments: MNG-3719-maven-project.patch,
> plugin-execution-order-cant-be-defined-maven-2.0.9.tar.gz
>
>
> I extend my sincere apologies if there is a much easier way of doing this,
> but so far I haven't found any.
> There should be some way to ensure order of plugin executions through
> dependencies on other executions. See attached project for example, or see
> below for the applicable example in a pom.xml. When plugins are defined in
> pom.xml in the following manner to ensure correct execution order, they are
> not executed sequentially and there is no way to indicate dependencies, as
> would be expected (note- I'm not expecting that it interpret the "step 1...",
> ..., "step 5..." IDs, I'm only suggesting that either the plugins be executed
> in order that they are found in the XML (most intuitive) or that there be
> some concept of priority/ordinal added, or even perhaps (this would be most
> "ant-like") that plugin executions (and maybe even plugin goal executions) be
> allowed to define prequisite execution IDs to be run (even if they are IDs
> not defined in the pom, but maybe a parent pom, even though I don't need that
> right now).
> I know that this could be problematic if a plugin execution from one
> lifecycle phase depends on another from another lifecycle phase (and you
> could get into circular references that way that would have to be recognized
> during pom validation after loading/merging pom.xmls). However, not being
> able to at the very least define order of execution of different (or the
> same) plugin executions as noted below and in attached project makes it
> difficult to chain plugin executions that depend on each other, thereby
> reducing the practicality of the pom.xml and Maven 2.
> For example, these plugin executions cannot be ordered properly in Maven
> 2.0.9, since there appears to be no way to indicate dependencies of one
> execution on another:
> {code}
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.5
> 1.5
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> step 1 - backup-original-web.xml-from-src
> generate-resources
>
> run
>
>
>
>
>
> file="${pom.basedir}/src/main/webapp/WEB-INF/web.xml"
> todir="${pom.basedir}/target/tmpwebxml/"/>
>
>
>
>
>
>
>
> org.codehaus.mojo
> jspc-maven-plugin
>
>
> step 2 - jspc
> generate-resources
>
> compile
>
>
>
>
>
>
>
>
>
> org.apache.pluto
> pluto-taglib
> 1.1.3
> jar
>
>
> javax.portlet
> portlet-api
> 1.0
> jar
>
>
> javax.servlet
>
[jira] Closed: (MNG-3853) [regression] Distribution Management injected by profile is not reflected by MavenProject
[
http://jira.codehaus.org/browse/MNG-3853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-3853.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: (was: 3.0-alpha-4)
3.0-alpha-3
> [regression] Distribution Management injected by profile is not reflected by
> MavenProject
> -
>
> Key: MNG-3853
> URL: http://jira.codehaus.org/browse/MNG-3853
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories, Profiles
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-3
>
>
> The cause of the user reported issue [Tycho: problem with
> distributionManagement in
> profile|http://www.nabble.com/Tycho%3A-problem-with-distributionManagement-in-profile-to20490017.html]
> is that the aritfact repos are created in the constructor of
> {{MavenProject}} but the the profiles are injected in a later step.
> There is other setup code in the constructor which most likely is also
> affected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3885) Modules of Maven projects are deployed with Timestamp during reactor build when uniqueVersion is set to false in parent profile
[ http://jira.codehaus.org/browse/MNG-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3885: --- Fix Version/s: 3.0-alpha-3 > Modules of Maven projects are deployed with Timestamp during reactor build > when uniqueVersion is set to false in parent profile > --- > > Key: MNG-3885 > URL: http://jira.codehaus.org/browse/MNG-3885 > Project: Maven 2 > Issue Type: Bug > Components: Deployment >Affects Versions: 2.0.8 > Environment: Red Hat Linux, Maven 2.0.8, Java 1.6, Cruisecontrol >Reporter: Matthias Wegerhoff >Assignee: Benjamin Bentmann > Fix For: 2.0.11, 2.1.0-M1, 3.0-alpha-3 > > Attachments: minimizedPOM.xml, minimizedPOM.xml, > minimizedSETTINGS.xml, MNG-3885.zip > > > When deploying artifacts into local repository with cruisecontrol by using > the following command: > mvn -U -P mvn-profile ... -DuniqueVersion=false deploy > The parent is always beeing deployed correctly, without timestamp as > -SNAPSHOT. But all Modules are beeing deployed with Timestamp. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3719) [regression] plugin execution ordering no longer POM ordered in 2.0.9
[
http://jira.codehaus.org/browse/MNG-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3719.
-
Assignee: Brett Porter
Resolution: Fixed
> [regression] plugin execution ordering no longer POM ordered in 2.0.9
> -
>
> Key: MNG-3719
> URL: http://jira.codehaus.org/browse/MNG-3719
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.9, 2.0.10, 2.1.0-M1
> Environment: Maven 2.0.9, java version "1.5.0_13" Java(TM) 2 Runtime
> Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM)
> Client VM (build 1.5.0_13-120, mixed mode, sharing), OS X 10.4
>Reporter: Gary S. Weaver
>Assignee: Brett Porter
>Priority: Critical
> Fix For: 2.0.11, 2.1.0-M2
>
> Attachments: MNG-3719-maven-project.patch,
> plugin-execution-order-cant-be-defined-maven-2.0.9.tar.gz
>
>
> I extend my sincere apologies if there is a much easier way of doing this,
> but so far I haven't found any.
> There should be some way to ensure order of plugin executions through
> dependencies on other executions. See attached project for example, or see
> below for the applicable example in a pom.xml. When plugins are defined in
> pom.xml in the following manner to ensure correct execution order, they are
> not executed sequentially and there is no way to indicate dependencies, as
> would be expected (note- I'm not expecting that it interpret the "step 1...",
> ..., "step 5..." IDs, I'm only suggesting that either the plugins be executed
> in order that they are found in the XML (most intuitive) or that there be
> some concept of priority/ordinal added, or even perhaps (this would be most
> "ant-like") that plugin executions (and maybe even plugin goal executions) be
> allowed to define prequisite execution IDs to be run (even if they are IDs
> not defined in the pom, but maybe a parent pom, even though I don't need that
> right now).
> I know that this could be problematic if a plugin execution from one
> lifecycle phase depends on another from another lifecycle phase (and you
> could get into circular references that way that would have to be recognized
> during pom validation after loading/merging pom.xmls). However, not being
> able to at the very least define order of execution of different (or the
> same) plugin executions as noted below and in attached project makes it
> difficult to chain plugin executions that depend on each other, thereby
> reducing the practicality of the pom.xml and Maven 2.
> For example, these plugin executions cannot be ordered properly in Maven
> 2.0.9, since there appears to be no way to indicate dependencies of one
> execution on another:
> {code}
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.5
> 1.5
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> step 1 - backup-original-web.xml-from-src
> generate-resources
>
> run
>
>
>
>
>
> file="${pom.basedir}/src/main/webapp/WEB-INF/web.xml"
> todir="${pom.basedir}/target/tmpwebxml/"/>
>
>
>
>
>
>
>
> org.codehaus.mojo
> jspc-maven-plugin
>
>
> step 2 - jspc
> generate-resources
>
> compile
>
>
>
>
>
>
>
>
>
> org.apache.pluto
> pluto-taglib
> 1.1.3
> jar
>
>
> javax.portlet
> portlet-api
> 1.0
> jar
>
>
> javax.servlet
> jstl
> 1.1.2
> jar
>
>
>
[jira] Updated: (MNG-3530) Regression: Properties get resolved before the LifeCycle is Forked.
[
http://jira.codehaus.org/browse/MNG-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3530:
--
Fix Version/s: (was: 2.1.0-M2)
2.1.0-M3
> Regression: Properties get resolved before the LifeCycle is Forked.
> ---
>
> Key: MNG-3530
> URL: http://jira.codehaus.org/browse/MNG-3530
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Nick Pellow
>Assignee: John Casey
> Fix For: 2.1.0-M3
>
> Attachments: MNG-3530.tar.gz, MNG-3530.zip
>
>
> Since Maven 2.0.9 -- If a plugin uses a forked lifecycle, then the project
> properties are resolved by maven before the lifecycle is forked.
> This means that the forked lifecycle has the non-forked lifecycle's values.
> This was not the case in maven prior to version 2.0.9, where properties were
> resolved at a much later time.
> For example - the attached sample project uses the Clover plugin with the
> xdoclet plugin. When {code}mvn clean install{code} is run under *Maven-2.0.8*
> you can see the following output:
> {code}
> [INFO] [xdoclet:xdoclet {execution: default}]
> [INFO] Initializing DocletTasks!!!
> [INFO] Executing tasks
> [echo] Build Dir: ${project.build.directory}/test.clover
> [INFO] Executed tasks
> {code}
> whilst *Maven 2.0.9* outputs:
> {code}
> [INFO] [xdoclet:xdoclet {execution: default}]
> [INFO] Initializing DocletTasks!!!
> [INFO] Executing tasks
> [mkdir] Created dir: /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target
> [touch] Creating
> /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target/test.clover
> [echo] Build Dir:
> /Users/niick/work/mvnclvr/src/it/mng/xdoclet/target/test.clover
> [INFO] Executed tasks
> [INFO] [resources:resources]
> {code}
> The fact the ${project.build.directory} property has been expanded already
> under 2.0.9, means that the forked lifecycle has the same value for that
> property.
> This new behavior will break any plugin which uses a forked lifecycle.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3808) Execution order of report plugins is arbitrary if inheritance is involved
[ http://jira.codehaus.org/browse/MNG-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3808. - Assignee: Brett Porter Resolution: Fixed Fix Version/s: 2.0.11 applied > Execution order of report plugins is arbitrary if inheritance is involved > - > > Key: MNG-3808 > URL: http://jira.codehaus.org/browse/MNG-3808 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation, Plugins and Lifecycle, > Sites & Reporting >Affects Versions: 2.0.9 > Environment: maven 2.0.4, windows 2000 >Reporter: David Vicente >Assignee: Brett Porter >Priority: Critical > Fix For: 2.0.11, 2.1.0-M2 > > Attachments: MNG-3808.patch > > > I have created a maven 2 report : Dashboard report which aggregate all > reports results in one report. > My plugin must be executed as the last one even if i can't bind the > "post-site" phase or use the "aggregator" annotation. > I declare my report plugin as the last one in the reporting section of my POM. > When i run mvn site on a single project, it's ok, my plugin has been > executed as the last one. > The reports list has been ordered as declared in my POM. > But if i run "mvn site" on a multi-project POM, the reports list isn't > ordered as before. > I think, it's the same problem as > http://jira.codehaus.org/browse/MNG-1994?page=all -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3719) [regression] plugin execution ordering no longer POM ordered in 2.0.9
[
http://jira.codehaus.org/browse/MNG-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164221#action_164221
]
Brett Porter commented on MNG-3719:
---
I noted that this is only an issue when there is more than one declaration of a
particular plugin.
Since MNG-2145, multiple declarations are grouped together as if there were
executions in one plugin. This patch simply sorts those executions correctly.
I think the original poster wanted the old functionality back where plugins
could be declared multiple times and run in order - however I'm not prepared to
undo that on 2.0.x.
I've applied the patch to resolve the issue.
> [regression] plugin execution ordering no longer POM ordered in 2.0.9
> -
>
> Key: MNG-3719
> URL: http://jira.codehaus.org/browse/MNG-3719
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.9, 2.0.10, 2.1.0-M1
> Environment: Maven 2.0.9, java version "1.5.0_13" Java(TM) 2 Runtime
> Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM)
> Client VM (build 1.5.0_13-120, mixed mode, sharing), OS X 10.4
>Reporter: Gary S. Weaver
>Priority: Critical
> Fix For: 2.0.11, 2.1.0-M2
>
> Attachments: MNG-3719-maven-project.patch,
> plugin-execution-order-cant-be-defined-maven-2.0.9.tar.gz
>
>
> I extend my sincere apologies if there is a much easier way of doing this,
> but so far I haven't found any.
> There should be some way to ensure order of plugin executions through
> dependencies on other executions. See attached project for example, or see
> below for the applicable example in a pom.xml. When plugins are defined in
> pom.xml in the following manner to ensure correct execution order, they are
> not executed sequentially and there is no way to indicate dependencies, as
> would be expected (note- I'm not expecting that it interpret the "step 1...",
> ..., "step 5..." IDs, I'm only suggesting that either the plugins be executed
> in order that they are found in the XML (most intuitive) or that there be
> some concept of priority/ordinal added, or even perhaps (this would be most
> "ant-like") that plugin executions (and maybe even plugin goal executions) be
> allowed to define prequisite execution IDs to be run (even if they are IDs
> not defined in the pom, but maybe a parent pom, even though I don't need that
> right now).
> I know that this could be problematic if a plugin execution from one
> lifecycle phase depends on another from another lifecycle phase (and you
> could get into circular references that way that would have to be recognized
> during pom validation after loading/merging pom.xmls). However, not being
> able to at the very least define order of execution of different (or the
> same) plugin executions as noted below and in attached project makes it
> difficult to chain plugin executions that depend on each other, thereby
> reducing the practicality of the pom.xml and Maven 2.
> For example, these plugin executions cannot be ordered properly in Maven
> 2.0.9, since there appears to be no way to indicate dependencies of one
> execution on another:
> {code}
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.5
> 1.5
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> step 1 - backup-original-web.xml-from-src
> generate-resources
>
> run
>
>
>
>
>
> file="${pom.basedir}/src/main/webapp/WEB-INF/web.xml"
> todir="${pom.basedir}/target/tmpwebxml/"/>
>
>
>
>
>
>
>
> org.codehaus.mojo
> jspc-maven-plugin
>
>
> step 2 - jspc
> generate-resources
>
> compile
>
>
>
>
>
>
>
>
>
> org.apache.pluto
> pluto-taglib
> 1.1.3
>
[jira] Updated: (MNG-3768) [regression] Class folder system dependency doesn't work anymore
[
http://jira.codehaus.org/browse/MNG-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3768:
--
Fix Version/s: (was: 2.1.0-M2)
2.0.x
> [regression] Class folder system dependency doesn't work anymore
>
>
> Key: MNG-3768
> URL: http://jira.codehaus.org/browse/MNG-3768
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.1.0-M1
> Environment: Any
>Reporter: Francois Loison
> Fix For: 2.0.x
>
> Attachments: mng-3288.zip, MNG-3768.patch.txt, mng-3768.zip,
> patch-MNG-3768-distribution.txt
>
>
> My project use system dependencies pointing to class folders.
>
> class-folder
> class-folder
> N
> system
> C:/appli/classes
>
> Such class folders dependencies worked fine with maven 2.0.7
> They are needed by my project as it relies on a legacy application not
> packaged into a jar file.
> Root cause is located in file DefaultArtifactResolver.java:
> if ( !systemFile.isFile() )
> {
> throw new ArtifactNotFoundException( "System artifact: " +
> artifact + " is not a file: " + systemFile,
> artifact );
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3768) [regression] Class folder system dependency doesn't work anymore
[
http://jira.codehaus.org/browse/MNG-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164216#action_164216
]
Brett Porter commented on MNG-3768:
---
Francois... when I apply that patch, 3288 still fails. The cases are certainly
incompatible.
Is there really no way you can package those classes into an artifact?
> [regression] Class folder system dependency doesn't work anymore
>
>
> Key: MNG-3768
> URL: http://jira.codehaus.org/browse/MNG-3768
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.1.0-M1
> Environment: Any
>Reporter: Francois Loison
> Fix For: 2.1.0-M2
>
> Attachments: mng-3288.zip, MNG-3768.patch.txt, mng-3768.zip,
> patch-MNG-3768-distribution.txt
>
>
> My project use system dependencies pointing to class folders.
>
> class-folder
> class-folder
> N
> system
> C:/appli/classes
>
> Such class folders dependencies worked fine with maven 2.0.7
> They are needed by my project as it relies on a legacy application not
> packaged into a jar file.
> Root cause is located in file DefaultArtifactResolver.java:
> if ( !systemFile.isFile() )
> {
> throw new ArtifactNotFoundException( "System artifact: " +
> artifact + " is not a file: " + systemFile,
> artifact );
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPIR-149) Add a qualityManagement goal
Add a qualityManagement goal Key: MPIR-149 URL: http://jira.codehaus.org/browse/MPIR-149 Project: Maven 2.x Project Info Reports Plugin Issue Type: Wish Reporter: Xavier Chatelain Priority: Minor More and more projects use an external quality management tool. So it would be interesting to add a qualityManagement goal similar to the cim and issueTracking goals. With this goal, user could add this kind of configuration in his pom.xml: sonar http://host/sonar/myProject -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
