[jira] [Created] (MPH-191) help:evaluate fails on Java 18 - java.util.Hashtable.table not accessible
Ondrej Zizka created MPH-191:
Summary: help:evaluate fails on Java 18 -
java.util.Hashtable.table not accessible
Key: MPH-191
URL: https://issues.apache.org/jira/browse/MPH-191
Project: Maven Help Plugin
Issue Type: Bug
Components: evaluate
Affects Versions: 3.3.0
Reporter: Ondrej Zizka
When running help:evaluate:
{noformat}
com.thoughtworks.xstream.converters.reflection.ReflectionConverter[ERROR]
message[2] : Unable to make field private transient
java.util.Hashtable$Entry[] java.util.Hashtable.table accessible: module
java.base does not "opens java.util" to unnamed module @4fc3529
{noformat}
{noformat}
$ $MVN $MVN_OPTS help:system help:effective-settings help:effective-pom
dependency:tree help:evaluate -Dexpression=project.properties -q
-DforceStdout[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-help-plugin:3.3.0:evaluate (default-cli) on
project tracker-service-app: Execution default-cli of goal
org.apache.maven.plugins:maven-help-plugin:3.3.0:evaluate failed: No converter
available[ERROR] Debugging information [ERROR] message :
No converter available[ERROR] type:
org.apache.maven.plugins.help.AbstractEffectiveMojo$SortedProperties[ERROR]
converter :
com.thoughtworks.xstream.converters.reflection.SerializableConverter[ERROR]
message[1] : Unable to make private void
java.util.Hashtable.readObject(java.io.ObjectInputStream) throws
java.io.IOException,java.lang.ClassNotFoundException accessible: module
java.base does not "opens java.util" to unnamed module @4fc3529[ERROR]
converter[1]:
com.thoughtworks.xstream.converters.reflection.ReflectionConverter[ERROR]
message[2] : Unable to make field private transient
java.util.Hashtable$Entry[] java.util.Hashtable.table accessible: module
java.base does not "opens java.util" to unnamed module @4fc3529{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] Created: (MDEP-318) Dependency plugin: copy-dependencies -DfailOnMissingClassifierArtifact=false does not work.
Dependency plugin: copy-dependencies -DfailOnMissingClassifierArtifact=false
does not work.
---
Key: MDEP-318
URL: https://jira.codehaus.org/browse/MDEP-318
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: copy-dependencies
Affects Versions: 2.2
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_24
Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.35-30-generic" arch: "amd64" Family: "unix"
Reporter: Ondrej Zizka
Assignee: Brian Fox
STR:
1) Have a project with some artifact which does not have sources jar.
2) Run `mvn dependency:copy-dependencies -Dclassifier=sources
-DfailOnMissingClassifierArtifact=false`
3) Task will fail on that artifact.
Reference:
http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html
{code}
maven-dependency-plugin
2.2
{code}
{code}
$ mvn dependency:copy-dependencies -Dclassifier=sources
-DfailOnMissingClassifierArtifact=false
[INFO] Scanning for projects...
Downloading:
https://repository.jboss.org/nexus/content/groups/public//org/apache/maven/plugins/maven-dependency-plugin/2.2/maven-dependency-plugin-2.2.pom
[INFO] Unable to find resource
'org.apache.maven.plugins:maven-dependency-plugin:pom:2.2' in repository
jboss-plugins (https://repository.jboss.org/nexus/content/groups/public/)
Downloading:
http://uk.maven.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/2.2/maven-dependency-plugin-2.2.pom
Downloading:
https://repository.jboss.org/nexus/content/groups/public//org/apache/maven/plugins/maven-dependency-plugin/2.2/maven-dependency-plugin-2.2.jar
[INFO] Unable to find resource
'org.apache.maven.plugins:maven-dependency-plugin:maven-plugin:2.2' in
repository jboss-plugins
(https://repository.jboss.org/nexus/content/groups/public/)
Downloading:
http://uk.maven.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/2.2/maven-dependency-plugin-2.2.jar
...
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] not found in any repository: asm:asm:java-source:sources:3.1
Embedded error: Unable to download the artifact from any repository
...
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-334) Can not generate class-path from Manifest
[
https://jira.codehaus.org/browse/MASSEMBLY-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=275189#comment-275189
]
Ondrej Zizka commented on MASSEMBLY-334:
Stevo, does that mean that you invoke maven-war-plugin in a jar artifact?
> Can not generate class-path from Manifest
> -
>
> Key: MASSEMBLY-334
> URL: https://jira.codehaus.org/browse/MASSEMBLY-334
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: Pc - Windows XP sp2
>Reporter: Damien
>
> I have a maven's projet multi-module.
> I have a problem when i launch mvn package assembly:assembly
> In the Manifest file, the class path does not generated.
> Pom project
> {code:xml}
>
> 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/maven-v4_0_0.xsd";>
> 4.0.0
> com.ipsis.pacha
> Pacha
> pom
> 1.0-SNAPSHOT
> PACHA
>
>
>
>
>
> maven-antrun-plugin
>
>
>
> print-maven-runtime-classpath
> compile
>
>
>name="runtime-classpath"
>
> refid="maven.runtime.classpath" />
>
> message="maven.runtime.classpath=${runtime-classpath}" />
>
>
>
> run
>
>
>
>
> print-maven-test-classpath
> test-compile
>
>
>name="test-classpath"
>
> refid="maven.test.classpath" />
>
> message="maven.test.classpath=${test-classpath}" />
>
>
>
> run
>
>
>
>
>
>
> maven-compiler-plugin
>
>
> 1.6
> 1.6
> 512m
> 1024m
> true
> true
> true
>
> ${JAVA_HOME}\bin\javac.exe
> 1.6
>
>
>
>
>
> true
> maven-deploy-plugin
>
>
> true
>
>
>
>
> org.apache.maven.plugins
> maven-release-plugin
>
> deploy
>
>
>
>
> maven-surefire-plugin
>
>
>
> maven-eclipse-plugin
>
>
[jira] Commented: (MASSEMBLY-334) Can not generate class-path from Manifest
[
https://jira.codehaus.org/browse/MASSEMBLY-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=275190#comment-275190
]
Ondrej Zizka commented on MASSEMBLY-334:
I have the same issue with Maven 2 - unable to make it put classpath to
MANIFEST.MF.
My project's structure is:
root
* core
* ...
* assembly - depends on all other modules.
> Can not generate class-path from Manifest
> -
>
> Key: MASSEMBLY-334
> URL: https://jira.codehaus.org/browse/MASSEMBLY-334
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: Pc - Windows XP sp2
>Reporter: Damien
>
> I have a maven's projet multi-module.
> I have a problem when i launch mvn package assembly:assembly
> In the Manifest file, the class path does not generated.
> Pom project
> {code:xml}
>
> 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/maven-v4_0_0.xsd";>
> 4.0.0
> com.ipsis.pacha
> Pacha
> pom
> 1.0-SNAPSHOT
> PACHA
>
>
>
>
>
> maven-antrun-plugin
>
>
>
> print-maven-runtime-classpath
> compile
>
>
>name="runtime-classpath"
>
> refid="maven.runtime.classpath" />
>
> message="maven.runtime.classpath=${runtime-classpath}" />
>
>
>
> run
>
>
>
>
> print-maven-test-classpath
> test-compile
>
>
>name="test-classpath"
>
> refid="maven.test.classpath" />
>
> message="maven.test.classpath=${test-classpath}" />
>
>
>
> run
>
>
>
>
>
>
> maven-compiler-plugin
>
>
> 1.6
> 1.6
> 512m
> 1024m
> true
> true
> true
>
> ${JAVA_HOME}\bin\javac.exe
> 1.6
>
>
>
>
>
> true
> maven-deploy-plugin
>
>
> true
>
>
>
>
> org.apache.maven.plugins
> maven-release-plugin
>
> deploy
>
>
>
>
> maven-surefire-plugin
>
>
>
>
[jira] Issue Comment Edited: (MASSEMBLY-334) Can not generate class-path from Manifest
[
https://jira.codehaus.org/browse/MASSEMBLY-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=275190#comment-275190
]
Ondrej Zizka edited comment on MASSEMBLY-334 at 8/7/11 5:54 AM:
I have the same issue with Maven 2 - unable to make it put classpath to
MANIFEST.MF.
My project's structure is:
* root
* core
* ...
* assembly - depends on all other modules.
was (Author: pekarna):
I have the same issue with Maven 2 - unable to make it put classpath to
MANIFEST.MF.
My project's structure is:
root
* core
* ...
* assembly - depends on all other modules.
> Can not generate class-path from Manifest
> -
>
> Key: MASSEMBLY-334
> URL: https://jira.codehaus.org/browse/MASSEMBLY-334
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: Pc - Windows XP sp2
>Reporter: Damien
>
> I have a maven's projet multi-module.
> I have a problem when i launch mvn package assembly:assembly
> In the Manifest file, the class path does not generated.
> Pom project
> {code:xml}
>
> 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/maven-v4_0_0.xsd";>
> 4.0.0
> com.ipsis.pacha
> Pacha
> pom
> 1.0-SNAPSHOT
> PACHA
>
>
>
>
>
> maven-antrun-plugin
>
>
>
> print-maven-runtime-classpath
> compile
>
>
>name="runtime-classpath"
>
> refid="maven.runtime.classpath" />
>
> message="maven.runtime.classpath=${runtime-classpath}" />
>
>
>
> run
>
>
>
>
> print-maven-test-classpath
> test-compile
>
>
>name="test-classpath"
>
> refid="maven.test.classpath" />
>
> message="maven.test.classpath=${test-classpath}" />
>
>
>
> run
>
>
>
>
>
>
> maven-compiler-plugin
>
>
> 1.6
> 1.6
> 512m
> 1024m
> true
> true
> true
>
> ${JAVA_HOME}\bin\javac.exe
> 1.6
>
>
>
>
>
> true
> maven-deploy-plugin
>
>
> true
>
>
>
>
> org.apache.maven.plugins
> maven-release-plugin
>
> dep
[jira] Issue Comment Edited: (MASSEMBLY-334) Can not generate class-path from Manifest
[
https://jira.codehaus.org/browse/MASSEMBLY-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=275190#comment-275190
]
Ondrej Zizka edited comment on MASSEMBLY-334 at 8/7/11 5:55 AM:
I have the same issue with Maven 2 - unable to make it put classpath to
MANIFEST.MF.
My project's structure is:
* root
** core
** ...
** assembly - depends on all other modules.
was (Author: pekarna):
I have the same issue with Maven 2 - unable to make it put classpath to
MANIFEST.MF.
My project's structure is:
* root
* core
* ...
* assembly - depends on all other modules.
> Can not generate class-path from Manifest
> -
>
> Key: MASSEMBLY-334
> URL: https://jira.codehaus.org/browse/MASSEMBLY-334
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: Pc - Windows XP sp2
>Reporter: Damien
>
> I have a maven's projet multi-module.
> I have a problem when i launch mvn package assembly:assembly
> In the Manifest file, the class path does not generated.
> Pom project
> {code:xml}
>
> 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/maven-v4_0_0.xsd";>
> 4.0.0
> com.ipsis.pacha
> Pacha
> pom
> 1.0-SNAPSHOT
> PACHA
>
>
>
>
>
> maven-antrun-plugin
>
>
>
> print-maven-runtime-classpath
> compile
>
>
>name="runtime-classpath"
>
> refid="maven.runtime.classpath" />
>
> message="maven.runtime.classpath=${runtime-classpath}" />
>
>
>
> run
>
>
>
>
> print-maven-test-classpath
> test-compile
>
>
>name="test-classpath"
>
> refid="maven.test.classpath" />
>
> message="maven.test.classpath=${test-classpath}" />
>
>
>
> run
>
>
>
>
>
>
> maven-compiler-plugin
>
>
> 1.6
> 1.6
> 512m
> 1024m
> true
> true
> true
>
> ${JAVA_HOME}\bin\javac.exe
> 1.6
>
>
>
>
>
> true
> maven-deploy-plugin
>
>
> true
>
>
>
>
> org.apache.maven.plugins
> maven-release-plugin
>
>
[jira] Created: (SUREFIRE-781) Filter JVM's challenge to connect to debugger and print it to console even if redirectTestOutputToFile == true.
Filter JVM's challenge to connect to debugger and print it to console even if redirectTestOutputToFile == true. --- Key: SUREFIRE-781 URL: https://jira.codehaus.org/browse/SUREFIRE-781 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Affects Versions: 2.10 Reporter: Ondrej Zizka We have come to an interesting problem with Arquillian. It starts a container instance from within the test. If one wants to start the server in debug mode with server=y,suspend=y then the JVM's notice that it's waiting for the debugger to connect is not shown to user. Instead, the test run looks like being stuck. This is quite confusing, especially in complex continuous integration use cases. I suggest to (optionally) filter test's output for these notices and print them to the console, even if redirectTestOutputToFile == true. ConsoleOutputFileReporter#writeMessage( byte[] b, int off, int len ) could be adjusted for this purpose. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5189) Provide a way to specify module ordering when they are activated in profiles.
Provide a way to specify module ordering when they are activated in profiles.
-
Key: MNG-5189
URL: https://jira.codehaus.org/browse/MNG-5189
Project: Maven 2 & 3
Issue Type: Improvement
Components: Reactor and workspace
Reporter: Ondrej Zizka
In our project, sub-modules are activated in profiles.
However, due to unflexible way Maven orders profiles, it's not possible to
enforce certain submodule being run last. Only possibility is to move it one
level above.
My suggestion is to allow specifying modules order in which they would run iif
they are activated:
{code}
module1
module2
lastButOneModule
lastModule
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5194) Profile activation: Allow expressions in
Profile activation: Allow expressions in - Key: MNG-5194 URL: https://jira.codehaus.org/browse/MNG-5194 Project: Maven 2 & 3 Issue Type: Improvement Components: Profiles Affects Versions: 3.0.3 Reporter: Ondrej Zizka Current profile activation capabilities are insufficient. Makes using large projects harder, especially with complex testsuites. Having a possibility to have profiles activated by an expression would help a lot. property1 == "true" || (property2 && property3) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-794) JUnit4 - ClassNotFoundException in second execution if tests are in different directory.
JUnit4 - ClassNotFoundException in second execution if tests are in different
directory.
Key: SUREFIRE-794
URL: https://jira.codehaus.org/browse/SUREFIRE-794
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support, Maven Surefire Plugin
Reporter: Ondrej Zizka
I have a structure where the test sources are in ../src/test/java .
Compiled classes are in default target/test-classes .
When I have two executions with some includes and excludes, the second
execution throws:
{code}
org.apache.maven.surefire.util.SurefireReflectionException:
java.lang.reflect.InvocationTargetException; nested exception is
java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
at
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
Caused by: org.apache.maven.surefire.util.NestedRuntimeException: Unable to
create test class 'org.jboss.as.test.integration.ws.anonymousPojos.web'; nested
exception is java.lang.ClassNotFoundException:
org.jboss.as.test.integration.ws.anonymousPojos.web
at
org.apache.maven.surefire.util.DefaultDirectoryScanner.loadClass(DefaultDirectoryScanner.java:102)
at
org.apache.maven.surefire.util.DefaultDirectoryScanner.locateTestClasses(DefaultDirectoryScanner.java:78)
at
org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:174)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:83)
... 9 more
Caused by: java.lang.ClassNotFoundException:
org.jboss.as.test.integration.ws.anonymousPojos.web
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at
org.apache.maven.surefire.util.DefaultDirectoryScanner.loadClass(DefaultDirectoryScanner.java:98)
... 12 more
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-794) JUnit4 - ClassNotFoundException in second execution if tests are in different directory.
[
https://jira.codehaus.org/browse/SUREFIRE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=283827#comment-283827
]
Ondrej Zizka edited comment on SUREFIRE-794 at 11/18/11 11:31 PM:
--
STR:
1) Check out
https://github.com/OndraZizka/jboss-as/commit/64ba2869d62d21ed5e3655b7b16b0713f0fd
2) cd testsuite/integration
3) mvn clean install -DwebProfile -Dts.basic -Dts.noSmoke
was (Author: pekarna):
STR:
1) Check out
https://github.com/OndraZizka/jboss-as/commit/64ba2869d62d21ed5e3655b7b16b0713f0fd
2) mvn clean install -DwebProfile -Dts.basic -Dts.noSmoke
> JUnit4 - ClassNotFoundException in second execution if tests are in different
> directory.
>
>
> Key: SUREFIRE-794
> URL: https://jira.codehaus.org/browse/SUREFIRE-794
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Reporter: Ondrej Zizka
>
> I have a structure where the test sources are in ../src/test/java .
> Compiled classes are in default target/test-classes .
> When I have two executions with some includes and excludes, the second
> execution throws:
> {code}
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> at
> org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> at
> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
> Caused by: org.apache.maven.surefire.util.NestedRuntimeException: Unable to
> create test class 'org.jboss.as.test.integration.ws.anonymousPojos.web';
> nested exception is java.lang.ClassNotFoundException:
> org.jboss.as.test.integration.ws.anonymousPojos.web
> at
> org.apache.maven.surefire.util.DefaultDirectoryScanner.loadClass(DefaultDirectoryScanner.java:102)
> at
> org.apache.maven.surefire.util.DefaultDirectoryScanner.locateTestClasses(DefaultDirectoryScanner.java:78)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:174)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:83)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException:
> org.jboss.as.test.integration.ws.anonymousPojos.web
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> at
> org.apache.maven.surefire.util.DefaultDirectoryScanner.loadClass(DefaultDirectoryScanner.java:98)
> ... 12 more
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-794) JUnit4 - ClassNotFoundException in second execution if tests are in different directory.
[
https://jira.codehaus.org/browse/SUREFIRE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=283827#comment-283827
]
Ondrej Zizka commented on SUREFIRE-794:
---
STR:
1) Check out
https://github.com/OndraZizka/jboss-as/commit/64ba2869d62d21ed5e3655b7b16b0713f0fd
2) mvn clean install -DwebProfile -Dts.basic -Dts.noSmoke
> JUnit4 - ClassNotFoundException in second execution if tests are in different
> directory.
>
>
> Key: SUREFIRE-794
> URL: https://jira.codehaus.org/browse/SUREFIRE-794
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Reporter: Ondrej Zizka
>
> I have a structure where the test sources are in ../src/test/java .
> Compiled classes are in default target/test-classes .
> When I have two executions with some includes and excludes, the second
> execution throws:
> {code}
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> at
> org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> at
> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
> Caused by: org.apache.maven.surefire.util.NestedRuntimeException: Unable to
> create test class 'org.jboss.as.test.integration.ws.anonymousPojos.web';
> nested exception is java.lang.ClassNotFoundException:
> org.jboss.as.test.integration.ws.anonymousPojos.web
> at
> org.apache.maven.surefire.util.DefaultDirectoryScanner.loadClass(DefaultDirectoryScanner.java:102)
> at
> org.apache.maven.surefire.util.DefaultDirectoryScanner.locateTestClasses(DefaultDirectoryScanner.java:78)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:174)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:83)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException:
> org.jboss.as.test.integration.ws.anonymousPojos.web
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> at
> org.apache.maven.surefire.util.DefaultDirectoryScanner.loadClass(DefaultDirectoryScanner.java:98)
> ... 12 more
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-794) JUnit4 - ClassNotFoundException in second execution if tests are in different directory.
[
https://jira.codehaus.org/browse/SUREFIRE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=283828#comment-283828
]
Ondrej Zizka commented on SUREFIRE-794:
---
Figured it out - there was a .xml file being caught by
.../**/*
I think this should be handled better - with a better message, containing path
to the file being scanned, like:
"Unable to load a test class from file .../web.xml. Was it included by mistake?"
> JUnit4 - ClassNotFoundException in second execution if tests are in different
> directory.
>
>
> Key: SUREFIRE-794
> URL: https://jira.codehaus.org/browse/SUREFIRE-794
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Reporter: Ondrej Zizka
>
> I have a structure where the test sources are in ../src/test/java .
> Compiled classes are in default target/test-classes .
> When I have two executions with some includes and excludes, the second
> execution throws:
> {code}
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> at
> org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> at
> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
> Caused by: org.apache.maven.surefire.util.NestedRuntimeException: Unable to
> create test class 'org.jboss.as.test.integration.ws.anonymousPojos.web';
> nested exception is java.lang.ClassNotFoundException:
> org.jboss.as.test.integration.ws.anonymousPojos.web
> at
> org.apache.maven.surefire.util.DefaultDirectoryScanner.loadClass(DefaultDirectoryScanner.java:102)
> at
> org.apache.maven.surefire.util.DefaultDirectoryScanner.locateTestClasses(DefaultDirectoryScanner.java:78)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:174)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:83)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException:
> org.jboss.as.test.integration.ws.anonymousPojos.web
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> at
> org.apache.maven.surefire.util.DefaultDirectoryScanner.loadClass(DefaultDirectoryScanner.java:98)
> ... 12 more
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.
Multiple Surefire executions - FAILURE in an execution prevents successive from running. Key: SUREFIRE-803 URL: https://jira.codehaus.org/browse/SUREFIRE-803 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.10 Reporter: Ondrej Zizka Priority: Critical Let's have multiple Surefire executions in a single module (different config needed). A failure of a test in one of these executions prevents running the successive. Surefire's testFailureIgnore is not an option because it makes a run with failures succeed. This behavior is undocumented. Also, it is undesired - the module as a whole should fail, but all it's tests should run. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.
[ https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285129#comment-285129 ] Ondrej Zizka commented on SUREFIRE-803: --- No, that helps with executions in multiple modules, where each has one. I am talking about **multiple executions** in **single module**. > Multiple Surefire executions - FAILURE in an execution prevents successive > from running. > > > Key: SUREFIRE-803 > URL: https://jira.codehaus.org/browse/SUREFIRE-803 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.10 >Reporter: Ondrej Zizka >Priority: Critical > > Let's have multiple Surefire executions in a single module (different config > needed). > A failure of a test in one of these executions prevents running the > successive. > Surefire's testFailureIgnore is not an option because it makes a run with > failures succeed. > This behavior is undocumented. > Also, it is undesired - the module as a whole should fail, but all it's tests > should run. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-806) Make ignoring of and on -Dtest=... optional (for multiple Surefire executions)
Make ignoring of and on -Dtest=... optional (for multiple
Surefire executions)
Key: SUREFIRE-806
URL: https://jira.codehaus.org/browse/SUREFIRE-806
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.11
Reporter: Ondrej Zizka
Let's have a single module with multiple Surefire executions (e.g. with
different Arquillian configs)
Tests are divided to run in either one, using and .
Then, if you use -Dtest=..., the specified test(s) is run twice - once for each
execution (and usually fails in one of them in our scenario).
My suggestion is to introduce a Surefire config property which would make this
behavior optional:
{code}
false
{code}
This would cause Surefire to run the intersection of the two sets -
one created by the mask from -Dtest=...,
second created by the includes and excludes of the respective execution.
Current description from
http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html :
{quote}
Specify this parameter to run individual tests by file name, overriding the
includes/excludes parameters. Each pattern you specify here will be used to
create an include pattern formatted like **/${test}.java, so you can just type
"-Dtest=MyTest" to run a single test called "foo/MyTest.java".
This parameter overrides the includes/excludes parameters, and the TestNG
suiteXmlFiles parameter.
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.
[ https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285307#comment-285307 ] Ondrej Zizka commented on SUREFIRE-803: --- Running a set of tests is a natural concept of the build process. I'd say that Maven core should be aware of this concept and should be given the information about how the tests ran. I don't know how it's implemented but I'd imagine some broader interface for Surefire, with methods to get the results info. > Multiple Surefire executions - FAILURE in an execution prevents successive > from running. > > > Key: SUREFIRE-803 > URL: https://jira.codehaus.org/browse/SUREFIRE-803 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.10 >Reporter: Ondrej Zizka >Priority: Critical > Attachments: surefire-803-failure-prevents-subsequent-executions.zip > > > Let's have multiple Surefire executions in a single module (different config > needed). > A failure of a test in one of these executions prevents running the > successive. > Surefire's testFailureIgnore is not an option because it makes a run with > failures succeed. > This behavior is undocumented. > Also, it is undesired - the module as a whole should fail, but all it's tests > should run. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-808) Selectable "grouping mode" for test groups - UNION or INTERSECTION.
Ondrej Zizka created SUREFIRE-808:
-
Summary: Selectable "grouping mode" for test groups - UNION or
INTERSECTION.
Key: SUREFIRE-808
URL: https://jira.codehaus.org/browse/SUREFIRE-808
Project: Maven Surefire
Issue Type: Improvement
Components: Junit 4.7+ (parallel) support, Junit 4.x support
Affects Versions: 2.11, 2.10
Reporter: Ondrej Zizka
Currently, the `groups` and `excludedGroups` work like:
{code}
( include1 OR include2 ... ) AND NOT ( exclude1 OR exclude2 OR ... )
{code}
This doesn't cover many usecases. For instance, if the groups overlap.
Example: user needs to run only EJB tests under security manager, while only
some EJB tests can run under security manager.
In such case, this is needed:
{code}
( EJB AND SecurityManager )
{code}
The suggestion is to introduce two new params:
{code}
groupingMode = union|intersection
excludeGroupingMode = union|intersection
{code}
They would switch AND and OR behavior.
Union would be the default (preserving current behavior).
Would be implemented in a filter, see:
https://github.com/apache/maven-surefire/blob/trunk/surefire-providers/common-junit48/src/main/java/org/apache/maven/surefire/common/junit48/FilterFactory.java#L115
--
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-808) Selectable "grouping mode" for test groups - UNION or INTERSECTION.
[
https://jira.codehaus.org/browse/SUREFIRE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285699#comment-285699
]
Ondrej Zizka commented on SUREFIRE-808:
---
BTW other option would be to implent a logical expression for groups selection,
like
{code}
groups= ( JMS || EJB ) && Security
groups= ( EJB && CommonCriteria ) && ! Clustering
{code}
but that's for another improvement request...
> Selectable "grouping mode" for test groups - UNION or INTERSECTION.
> ---
>
> Key: SUREFIRE-808
> URL: https://jira.codehaus.org/browse/SUREFIRE-808
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Junit 4.7+ (parallel) support, Junit 4.x support
>Affects Versions: 2.10, 2.11
>Reporter: Ondrej Zizka
>
> Currently, the `groups` and `excludedGroups` work like:
> {code}
> ( include1 OR include2 ... ) AND NOT ( exclude1 OR exclude2 OR ... )
> {code}
> This doesn't cover many usecases. For instance, if the groups overlap.
> Example: user needs to run only EJB tests under security manager, while only
> some EJB tests can run under security manager.
> In such case, this is needed:
> {code}
> ( EJB AND SecurityManager )
> {code}
> The suggestion is to introduce two new params:
> {code}
> groupingMode = union|intersection
> excludeGroupingMode = union|intersection
> {code}
> They would switch AND and OR behavior.
> Union would be the default (preserving current behavior).
> Would be implemented in a filter, see:
> https://github.com/apache/maven-surefire/blob/trunk/surefire-providers/common-junit48/src/main/java/org/apache/maven/surefire/common/junit48/FilterFactory.java#L115
--
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-808) Selectable "grouping mode" for test groups - UNION or INTERSECTION.
[
https://jira.codehaus.org/browse/SUREFIRE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285699#comment-285699
]
Ondrej Zizka edited comment on SUREFIRE-808 at 12/12/11 3:54 PM:
-
BTW other option would be to implement a logical expression for groups
selection, like
{code}
groups= ( JMS || EJB ) && Security
groups= ( EJB && CommonCriteria ) && ! Clustering
{code}
but that's for another improvement request...
was (Author: pekarna):
BTW other option would be to implent a logical expression for groups
selection, like
{code}
groups= ( JMS || EJB ) && Security
groups= ( EJB && CommonCriteria ) && ! Clustering
{code}
but that's for another improvement request...
> Selectable "grouping mode" for test groups - UNION or INTERSECTION.
> ---
>
> Key: SUREFIRE-808
> URL: https://jira.codehaus.org/browse/SUREFIRE-808
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Junit 4.7+ (parallel) support, Junit 4.x support
>Affects Versions: 2.10, 2.11
>Reporter: Ondrej Zizka
>
> Currently, the `groups` and `excludedGroups` work like:
> {code}
> ( include1 OR include2 ... ) AND NOT ( exclude1 OR exclude2 OR ... )
> {code}
> This doesn't cover many usecases. For instance, if the groups overlap.
> Example: user needs to run only EJB tests under security manager, while only
> some EJB tests can run under security manager.
> In such case, this is needed:
> {code}
> ( EJB AND SecurityManager )
> {code}
> The suggestion is to introduce two new params:
> {code}
> groupingMode = union|intersection
> excludeGroupingMode = union|intersection
> {code}
> They would switch AND and OR behavior.
> Union would be the default (preserving current behavior).
> Would be implemented in a filter, see:
> https://github.com/apache/maven-surefire/blob/trunk/surefire-providers/common-junit48/src/main/java/org/apache/maven/surefire/common/junit48/FilterFactory.java#L115
--
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-809) Implement boolean expression to define test group to be run.
Ondrej Zizka created SUREFIRE-809:
-
Summary: Implement boolean expression to define test group to be
run.
Key: SUREFIRE-809
URL: https://jira.codehaus.org/browse/SUREFIRE-809
Project: Maven Surefire
Issue Type: Improvement
Components: Junit 4.x support
Affects Versions: 2.11
Reporter: Ondrej Zizka
This is an alternative to SUREFIRE-808.
Instead of having hard-coded filtering structure combining two lists.
an expression could be parsed and evaluated for each test.
Each test would be "tagged" using
{code}
@Categories({ MyCateg1.class, MyCateg2.class, ... })
{code}
Surefire's `group` config param would be an expression like:
{code}
( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )
{code}
Presence of a category of given name would be evaluated as true, absence of it
as false.
Interface inheritance would be taken into account.
This mechanism would provide unlimited possibilities of grouping tests, and
would be very beneficial for huge testuites counting thousands of tests.
--
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-809) Implement boolean expression to define test group to be run.
[
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ondrej Zizka updated SUREFIRE-809:
--
Attachment: BooleanExpression.g
> Implement boolean expression to define test group to be run.
>
>
> Key: SUREFIRE-809
> URL: https://jira.codehaus.org/browse/SUREFIRE-809
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Junit 4.x support
>Affects Versions: 2.11
>Reporter: Ondrej Zizka
> Attachments: BooleanExpression.g
>
>
> This is an alternative to SUREFIRE-808.
> Instead of having hard-coded filtering structure combining two lists.
> an expression could be parsed and evaluated for each test.
> Each test would be "tagged" using
> {code}
> @Categories({ MyCateg1.class, MyCateg2.class, ... })
> {code}
> Surefire's `group` config param would be an expression like:
> {code}
> ( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )
> {code}
> Presence of a category of given name would be evaluated as true, absence of
> it as false.
> Interface inheritance would be taken into account.
> This mechanism would provide unlimited possibilities of grouping tests, and
> would be very beneficial for huge testuites counting thousands of tests.
--
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-809) Implement boolean expression to define test group to be run.
[
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285701#comment-285701
]
Ondrej Zizka commented on SUREFIRE-809:
---
For parsing and evaluation, JEXL library could be used -
http://commons.apache.org/jexl/ .
Other approach is to use ANTLR grammar, parse the expression and code the
evaluation. Example of grammar is attached.
Also, there's older 2.x release of JEP library which was under GPL:
http://sourceforge.net/projects/jep/
> Implement boolean expression to define test group to be run.
>
>
> Key: SUREFIRE-809
> URL: https://jira.codehaus.org/browse/SUREFIRE-809
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Junit 4.x support
>Affects Versions: 2.11
>Reporter: Ondrej Zizka
> Attachments: BooleanExpression.g
>
>
> This is an alternative to SUREFIRE-808.
> Instead of having hard-coded filtering structure combining two lists.
> an expression could be parsed and evaluated for each test.
> Each test would be "tagged" using
> {code}
> @Categories({ MyCateg1.class, MyCateg2.class, ... })
> {code}
> Surefire's `group` config param would be an expression like:
> {code}
> ( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )
> {code}
> Presence of a category of given name would be evaluated as true, absence of
> it as false.
> Interface inheritance would be taken into account.
> This mechanism would provide unlimited possibilities of grouping tests, and
> would be very beneficial for huge testuites counting thousands of tests.
--
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-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
Ondrej Zizka created MNG-5218:
-
Summary: Allow properties containing ${basedir} to retain same
value in sub-modules.
Key: MNG-5218
URL: https://jira.codehaus.org/browse/MNG-5218
Project: Maven 2 & 3
Issue Type: Improvement
Reporter: Ondrej Zizka
Currently, if a property contains ${basedir}, it's value in a submodule
contains submodule's base dir.
I.e., each submodule has this value different.
While it's handy for some cases (it allows nice recursive solution for some
tasks),
there's no way to have the property with ${basedir} set in the parent module
and using it unchanged in submodules.
That's quite crucial for e.g. complex testsuites.
The current behavior is surely relied on in many projects, so I'd suggest
something like:
{code}
{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] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285801#comment-285801
]
Ondrej Zizka commented on MNG-5218:
---
{code}
${basedir}/build/target/myCoolProduct
${basedir}/target/myCoolProduct
{code}
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {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] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285926#comment-285926
]
Ondrej Zizka commented on MNG-5218:
---
Oliver, it would break nothing - default behavior would be as it is now.
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {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] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285934#comment-285934
]
Ondrej Zizka commented on MNG-5218:
---
Petr, there already is kind of ${invocationdir} - it's named
${session.executionRootDirectory} .
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {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] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285934#comment-285934
]
Ondrej Zizka edited comment on MNG-5218 at 12/14/11 12:55 PM:
--
Petr, there already is kind of ${invocationdir} - it's named
${session.executionRootDirectory} .
And works everywhere except Ant plugin.
was (Author: pekarna):
Petr, there already is kind of ${invocationdir} - it's named
${session.executionRootDirectory} .
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {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] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286015#comment-286015
]
Ondrej Zizka commented on MNG-5218:
---
Petr, unfortunately, modules are usually not isolated - any time you specify a
, default is "..", and if it's missing, the build fails.
So reaching parent poms is perfectly valid built-in Maven behavior.
Now let me extend the idea - if you have a module, it's submodule, and
sub-sub-module, then during build of sub-sub-module, maven looks for the
../../pom.xml anyway. So reaching ancestor poms is perfectly valid built-in
Maven behavior.
Therefore, there isn't any problem with allowing to specify a property
containing a full path to that root module of a project (or generally any
ancestor module).
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {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] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286015#comment-286015
]
Ondrej Zizka edited comment on MNG-5218 at 12/15/11 9:30 AM:
-
Petr, modules are usually not isolated - any time you specify a ,
default is "..", and if it's missing, the build fails. So
reaching parent poms is perfectly valid built-in Maven behavior.
Now let me extend the idea - if you have a module, it's submodule, and
sub-sub-module, then during build of sub-sub-module, maven looks for the
../../pom.xml anyway. So reaching ancestor poms is perfectly valid built-in
Maven behavior.
Therefore, there isn't any problem with allowing to specify a property
containing a full path to that root module of a project (or generally any
ancestor module).
was (Author: pekarna):
Petr, unfortunately, modules are usually not isolated - any time you
specify a , default is "..", and if it's missing, the
build fails. So reaching parent poms is perfectly valid built-in Maven behavior.
Now let me extend the idea - if you have a module, it's submodule, and
sub-sub-module, then during build of sub-sub-module, maven looks for the
../../pom.xml anyway. So reaching ancestor poms is perfectly valid built-in
Maven behavior.
Therefore, there isn't any problem with allowing to specify a property
containing a full path to that root module of a project (or generally any
ancestor module).
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {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] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286049#comment-286049
]
Ondrej Zizka commented on MNG-5218:
---
{quote}
... not exactly true - if it's missing, Maven resolves it (using parent GAV)
from repo.
{quote}
IMO it first triesto resolve, if not found, it looks in .. - or the other way
around, I don't know, but try it yourself:
1) Have a module in .../root and a submodule in .../root/foo/bar
2) Set a parent in .../root/foo/bar to the root module
3) Look what will maven print. It's looking for a module in the parent dir.
Nevertheless, we may argue how nice it would be to have totally decoupled
modules, but the reality is that having heavily linked modules is the only way
to craft complex builds in Maven, especially the integration test part.
So the point is:
* There is a real need of passing some module's location to the submodules,
which can't be currently satisfied;
* There is no easy way to implement it - as per John's comment
* A workaound might be implemented as a plugin crawling the dirs upwards.
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {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] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.
[
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286051#comment-286051
]
Ondrej Zizka commented on MNG-5218:
---
John, perhaps the location of a module could somehow be pulled from the
reactor? Do the plugins have access to it?
My idea is that a property could be set for each module - like
{code}${session.reactor.modules.jboss-as-parent.location}{code}
WDYT?
> Allow properties containing ${basedir} to retain same value in sub-modules.
> ---
>
> Key: MNG-5218
> URL: https://jira.codehaus.org/browse/MNG-5218
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, if a property contains ${basedir}, it's value in a submodule
> contains submodule's base dir.
> I.e., each submodule has this value different.
> While it's handy for some cases (it allows nice recursive solution for some
> tasks),
> there's no way to have the property with ${basedir} set in the parent module
> and using it unchanged in submodules.
> That's quite crucial for e.g. complex testsuites.
> The current behavior is surely relied on in many projects, so I'd suggest
> something like:
> {code}
> {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-809) Implement boolean expression to define test group to be run.
[
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291378#comment-291378
]
Ondrej Zizka commented on SUREFIRE-809:
---
Hi John, could you please add a link to docs and/or the test cases? Thx.
> Implement boolean expression to define test group to be run.
>
>
> Key: SUREFIRE-809
> URL: https://jira.codehaus.org/browse/SUREFIRE-809
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.x support, TestNG support
>Affects Versions: 2.11
>Reporter: Ondrej Zizka
>Assignee: John Casey
> Fix For: 2.12
>
> Attachments: BooleanExpression.g, category-expression.jj
>
>
> This is an alternative to SUREFIRE-808.
> Instead of having hard-coded filtering structure combining two lists.
> an expression could be parsed and evaluated for each test.
> Each test would be "tagged" using
> {code}
> @Categories({ MyCateg1.class, MyCateg2.class, ... })
> {code}
> Surefire's `group` config param would be an expression like:
> {code}
> ( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )
> {code}
> Presence of a category of given name would be evaluated as true, absence of
> it as false.
> Interface inheritance would be taken into account.
> This mechanism would provide unlimited possibilities of grouping tests, and
> would be very beneficial for huge testuites counting thousands of tests.
--
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] (MANTRUN-172) Properties passed to Maven as -D don't get passed to invocations when a profile sets the same property
[
https://jira.codehaus.org/browse/MANTRUN-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293555#comment-293555
]
Ondrej Zizka commented on MANTRUN-172:
--
Workaround: In a dummy profile, define a property like this:
{code}
ts.ipv6.dummy.node1
node1
${node1}
{code}
Ant plugin will buy that.
> Properties passed to Maven as -D don't get passed to invocations when a
> profile sets the same property
>
>
> Key: MANTRUN-172
> URL: https://jira.codehaus.org/browse/MANTRUN-172
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Derek Lewis
> Attachments: maven-antrun-plugin-bug.zip
>
>
> When I invoke Maven as follows:
> mvn package -Dmy.test.property="from commandline" -Ptest-profile
> Setting my.test.property on the command line, I expect to see the following
> output from the testcase:
> [echo] pom.xml: ptest = from commandline
> [echo] pom.xml: my.test.property = from commandline
> [echo] build.xml: ptest = from commandline
> [echo] build.xml: my.test.property = from commandline
> But instead I see:
> [echo] pom.xml: ptest = from commandline
> [echo] pom.xml: my.test.property = from commandline
> [echo] build.xml: ptest = from commandline
> [echo] build.xml: my.test.property = from profile
> It looks like the task is causing properties set on the command line to
> not be inherited.
> When run without -Ptest-profile, the expected output is seen. The comments
> on MANTRUN-121 would seem to imply that properties set on the commandline
> should always be passed to sub builds, regardless of the value of the
> inheritAll property.
> I've tested with a profile in the pom as well as in settings.xml, and the
> same behavior is observed regardless of where the profile is, so long as it
> is activated.
--
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-5637) NPE in org.apache.maven.DefaultMaven.execute()
Ondrej Zizka created MNG-5637:
-
Summary: NPE in org.apache.maven.DefaultMaven.execute()
Key: MNG-5637
URL: https://jira.codehaus.org/browse/MNG-5637
Project: Maven 2 & 3
Issue Type: Bug
Components: Command Line
Affects Versions: 3.2.1
Reporter: Ondrej Zizka
Priority: Critical
Steps to reproduce:
git clone g...@github.com:windup/windup.git
cd windup
git checkout MavenNPE
mvn clean install
Result:
{code}
[ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:167)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.NullPointerException
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:270)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
... 11 more
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5637) NPE in org.apache.maven.DefaultMaven.execute()
[
https://jira.codehaus.org/browse/MNG-5637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ondrej Zizka updated MNG-5637:
--
Environment:
$ mvn -v
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
2014-02-14T18:37:52+01:00)
Maven home: /home/ondra/sw/prog/maven/3.2.1
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.11.0-20-generic", arch: "amd64", family: "unix"
> NPE in org.apache.maven.DefaultMaven.execute()
> --
>
> Key: MNG-5637
> URL: https://jira.codehaus.org/browse/MNG-5637
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.1
> Environment: $ mvn -v
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:52+01:00)
> Maven home: /home/ondra/sw/prog/maven/3.2.1
> Java version: 1.7.0_55, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.11.0-20-generic", arch: "amd64", family: "unix"
>Reporter: Ondrej Zizka
>Priority: Critical
>
> Steps to reproduce:
> git clone g...@github.com:windup/windup.git
> cd windup
> git checkout MavenNPE
> mvn clean install
> Result:
> {code}
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:167)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:270)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> ... 11 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5637) NPE in org.apache.maven.DefaultMaven.execute()
[
https://jira.codehaus.org/browse/MNG-5637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346903#comment-346903
]
Ondrej Zizka commented on MNG-5637:
---
Seems to be related, if not duplicate, MNG-5628 and MNG-5633
> NPE in org.apache.maven.DefaultMaven.execute()
> --
>
> Key: MNG-5637
> URL: https://jira.codehaus.org/browse/MNG-5637
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.1
> Environment: $ mvn -v
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:52+01:00)
> Maven home: /home/ondra/sw/prog/maven/3.2.1
> Java version: 1.7.0_55, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.11.0-20-generic", arch: "amd64", family: "unix"
>Reporter: Ondrej Zizka
>Priority: Critical
>
> Steps to reproduce:
> git clone g...@github.com:windup/windup.git
> cd windup
> git checkout MavenNPE
> mvn clean install
> Result:
> {code}
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:167)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:270)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> ... 11 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5637) NPE in org.apache.maven.DefaultMaven.execute()
[
https://jira.codehaus.org/browse/MNG-5637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346904#comment-346904
]
Ondrej Zizka commented on MNG-5637:
---
Maven 3.1.1 correctly reveals what's wrong:
Two or more projects in the reactor have the same identifier, please make sure
that :: is unique for each project:
{org.jboss.windup.test.apps.jboss:sample-jee-jboss-web:2.0.0-SNAPSHOT=[/home/ondra/work/Migration/WindUp/sample-apps/jee-example-jboss/jee-example-web/pom.xml,
/home/ondra/work/Migration/WindUp/sample-apps/jee-example-weblogic/jee-example-web/pom.xml]}
-> [Help 1]
> NPE in org.apache.maven.DefaultMaven.execute()
> --
>
> Key: MNG-5637
> URL: https://jira.codehaus.org/browse/MNG-5637
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.1
> Environment: $ mvn -v
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:52+01:00)
> Maven home: /home/ondra/sw/prog/maven/3.2.1
> Java version: 1.7.0_55, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.11.0-20-generic", arch: "amd64", family: "unix"
>Reporter: Ondrej Zizka
>Priority: Critical
>
> Steps to reproduce:
> git clone g...@github.com:windup/windup.git
> cd windup
> git checkout MavenNPE
> mvn clean install
> Result:
> {code}
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:167)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:270)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> ... 11 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5705) NPE in BuilderCommon.handleBuildError(BuilderCommon.java:147)
Ondrej Zizka created MNG-5705:
-
Summary: NPE in
BuilderCommon.handleBuildError(BuilderCommon.java:147)
Key: MNG-5705
URL: https://jira.codehaus.org/browse/MNG-5705
Project: Maven
Issue Type: Bug
Reporter: Ondrej Zizka
STR:
{code}
git clone g...@github.com:windup/windup.git
cd windup
git checkout 91a454b # MavenNPE2
mvn -T 1C clean javadoc:aggregate -PjavadocDist
{code}
{code}
[INFO]
[INFO] Windup Parent . SUCCESS [ 0.132 s]
[INFO] Windup Engine - Frames SUCCESS [ 0.009 s]
[INFO] Windup Engine - Utils . SUCCESS [ 0.035 s]
[INFO] Windup Engine - Graph Parent .. SUCCESS [ 0.004 s]
[INFO] Windup Engine - Graph API . FAILURE [ 0.003 s]
[INFO] Windup Engine - Graph Impl SKIPPED
[INFO] Windup Engine - Graph Addon ... SKIPPED
[INFO] Windup Engine - Graph Tests ... SKIPPED
[INFO] Windup Engine - Config Parent . SUCCESS [ 0.008 s]
[INFO] Windup Engine - Config API SKIPPED
[INFO] Windup Engine - Config Impl ... SKIPPED
[INFO] Windup Engine - Config Addon .. SKIPPED
[INFO] Windup Engine - Decompiler SUCCESS [ 0.011 s]
[INFO] Windup Engine - Decompiler API SUCCESS [ 0.039 s]
[INFO] Windup Engine - Decompiler Procyon SKIPPED
[INFO] Windup Extension - Config - XML ... SKIPPED
[INFO] Windup Engine - Reporting Parent .. SUCCESS [ 0.016 s]
[INFO] Windup Engine - Reporting API . SKIPPED
[INFO] Windup Engine - Reporting Impl SKIPPED
[INFO] Windup Engine - Reporting Addon ... SKIPPED
[INFO] Windup Engine - Execution API Parent .. SUCCESS [ 0.003 s]
[INFO] Windup Engine - Execution API . SKIPPED
[INFO] Windup Engine - Execution API Impl SKIPPED
[INFO] Windup Engine - Execution API Addon ... SKIPPED
[INFO] Windup Rules - XML - Basic SKIPPED
[INFO] Windup Extension - Config - Groovy SKIPPED
[INFO] Windup Rules - Java - Basic ... SKIPPED
[INFO] Windup Engine - Config Tests .. SKIPPED
[INFO] Windup Rules - Java EE - Basic SKIPPED
[INFO] Windup Engine - Execution API Tests ... SKIPPED
[INFO] Windup Engine - Reporting Tests ... SKIPPED
[INFO] Windup Engine - UI SKIPPED
[INFO] Windup Engine - Test Utilities SUCCESS [ 0.004 s]
[INFO] Windup Engine - Tests . SKIPPED
[INFO] Windup - Bootstrap module . SUCCESS [ 0.002 s]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ decompiler-api ---
[INFO] Windup - Distribution Build ... FAILURE [ 0.008 s]
[INFO] Windup Rulesets BOM ... SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1.721 s (Wall Clock)
[INFO] Finished at: 2014-10-22T16:39:30+01:00
[INFO] Final Memory: 21M/211M
[INFO]
[ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at
org.apache.maven.lifecycle.internal.builder.BuilderCommon.handleBuildError(BuilderCommon.java:147)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:121)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at
org.apache.maven.execution.MavenSession.getPluginContext(MavenSession.java:314)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMaven
[jira] (MNG-5705) NPE in BuilderCommon.handleBuildError(BuilderCommon.java:147)
[
https://jira.codehaus.org/browse/MNG-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ondrej Zizka updated MNG-5705:
--
Component/s: Bootstrap & Build
> NPE in BuilderCommon.handleBuildError(BuilderCommon.java:147)
> -
>
> Key: MNG-5705
> URL: https://jira.codehaus.org/browse/MNG-5705
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.2.1
>Reporter: Ondrej Zizka
>
> STR:
> {code}
> git clone g...@github.com:windup/windup.git
> cd windup
> git checkout 91a454b # MavenNPE2
> mvn -T 1C clean javadoc:aggregate -PjavadocDist
> {code}
> {code}
> [INFO]
>
> [INFO] Windup Parent . SUCCESS [ 0.132 s]
> [INFO] Windup Engine - Frames SUCCESS [ 0.009 s]
> [INFO] Windup Engine - Utils . SUCCESS [ 0.035 s]
> [INFO] Windup Engine - Graph Parent .. SUCCESS [ 0.004 s]
> [INFO] Windup Engine - Graph API . FAILURE [ 0.003 s]
> [INFO] Windup Engine - Graph Impl SKIPPED
> [INFO] Windup Engine - Graph Addon ... SKIPPED
> [INFO] Windup Engine - Graph Tests ... SKIPPED
> [INFO] Windup Engine - Config Parent . SUCCESS [ 0.008 s]
> [INFO] Windup Engine - Config API SKIPPED
> [INFO] Windup Engine - Config Impl ... SKIPPED
> [INFO] Windup Engine - Config Addon .. SKIPPED
> [INFO] Windup Engine - Decompiler SUCCESS [ 0.011 s]
> [INFO] Windup Engine - Decompiler API SUCCESS [ 0.039 s]
> [INFO] Windup Engine - Decompiler Procyon SKIPPED
> [INFO] Windup Extension - Config - XML ... SKIPPED
> [INFO] Windup Engine - Reporting Parent .. SUCCESS [ 0.016 s]
> [INFO] Windup Engine - Reporting API . SKIPPED
> [INFO] Windup Engine - Reporting Impl SKIPPED
> [INFO] Windup Engine - Reporting Addon ... SKIPPED
> [INFO] Windup Engine - Execution API Parent .. SUCCESS [ 0.003 s]
> [INFO] Windup Engine - Execution API . SKIPPED
> [INFO] Windup Engine - Execution API Impl SKIPPED
> [INFO] Windup Engine - Execution API Addon ... SKIPPED
> [INFO] Windup Rules - XML - Basic SKIPPED
> [INFO] Windup Extension - Config - Groovy SKIPPED
> [INFO] Windup Rules - Java - Basic ... SKIPPED
> [INFO] Windup Engine - Config Tests .. SKIPPED
> [INFO] Windup Rules - Java EE - Basic SKIPPED
> [INFO] Windup Engine - Execution API Tests ... SKIPPED
> [INFO] Windup Engine - Reporting Tests ... SKIPPED
> [INFO] Windup Engine - UI SKIPPED
> [INFO] Windup Engine - Test Utilities SUCCESS [ 0.004 s]
> [INFO] Windup Engine - Tests . SKIPPED
> [INFO] Windup - Bootstrap module . SUCCESS [ 0.002 s]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ decompiler-api ---
> [INFO] Windup - Distribution Build ... FAILURE [ 0.008 s]
> [INFO] Windup Rulesets BOM ... SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.721 s (Wall Clock)
> [INFO] Finished at: 2014-10-22T16:39:30+01:00
> [INFO] Final Memory: 21M/211M
> [INFO]
>
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at
> org.apache.maven.lifecycle.internal.builder.BuilderCommon.handleBuildError(BuilderCommon.java:147)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPo
[jira] (MNG-5705) NPE on parallel build in BuilderCommon.handleBuildError(BuilderCommon.java:147)
[
https://jira.codehaus.org/browse/MNG-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ondrej Zizka updated MNG-5705:
--
Summary: NPE on parallel build in
BuilderCommon.handleBuildError(BuilderCommon.java:147) (was: NPE in
BuilderCommon.handleBuildError(BuilderCommon.java:147))
> NPE on parallel build in
> BuilderCommon.handleBuildError(BuilderCommon.java:147)
> ---
>
> Key: MNG-5705
> URL: https://jira.codehaus.org/browse/MNG-5705
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.2.1
>Reporter: Ondrej Zizka
>
> STR:
> {code}
> git clone g...@github.com:windup/windup.git
> cd windup
> git checkout 91a454b # MavenNPE2
> mvn -T 1C clean javadoc:aggregate -PjavadocDist
> {code}
> {code}
> [INFO]
>
> [INFO] Windup Parent . SUCCESS [ 0.132 s]
> [INFO] Windup Engine - Frames SUCCESS [ 0.009 s]
> [INFO] Windup Engine - Utils . SUCCESS [ 0.035 s]
> [INFO] Windup Engine - Graph Parent .. SUCCESS [ 0.004 s]
> [INFO] Windup Engine - Graph API . FAILURE [ 0.003 s]
> [INFO] Windup Engine - Graph Impl SKIPPED
> [INFO] Windup Engine - Graph Addon ... SKIPPED
> [INFO] Windup Engine - Graph Tests ... SKIPPED
> [INFO] Windup Engine - Config Parent . SUCCESS [ 0.008 s]
> [INFO] Windup Engine - Config API SKIPPED
> [INFO] Windup Engine - Config Impl ... SKIPPED
> [INFO] Windup Engine - Config Addon .. SKIPPED
> [INFO] Windup Engine - Decompiler SUCCESS [ 0.011 s]
> [INFO] Windup Engine - Decompiler API SUCCESS [ 0.039 s]
> [INFO] Windup Engine - Decompiler Procyon SKIPPED
> [INFO] Windup Extension - Config - XML ... SKIPPED
> [INFO] Windup Engine - Reporting Parent .. SUCCESS [ 0.016 s]
> [INFO] Windup Engine - Reporting API . SKIPPED
> [INFO] Windup Engine - Reporting Impl SKIPPED
> [INFO] Windup Engine - Reporting Addon ... SKIPPED
> [INFO] Windup Engine - Execution API Parent .. SUCCESS [ 0.003 s]
> [INFO] Windup Engine - Execution API . SKIPPED
> [INFO] Windup Engine - Execution API Impl SKIPPED
> [INFO] Windup Engine - Execution API Addon ... SKIPPED
> [INFO] Windup Rules - XML - Basic SKIPPED
> [INFO] Windup Extension - Config - Groovy SKIPPED
> [INFO] Windup Rules - Java - Basic ... SKIPPED
> [INFO] Windup Engine - Config Tests .. SKIPPED
> [INFO] Windup Rules - Java EE - Basic SKIPPED
> [INFO] Windup Engine - Execution API Tests ... SKIPPED
> [INFO] Windup Engine - Reporting Tests ... SKIPPED
> [INFO] Windup Engine - UI SKIPPED
> [INFO] Windup Engine - Test Utilities SUCCESS [ 0.004 s]
> [INFO] Windup Engine - Tests . SKIPPED
> [INFO] Windup - Bootstrap module . SUCCESS [ 0.002 s]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ decompiler-api ---
> [INFO] Windup - Distribution Build ... FAILURE [ 0.008 s]
> [INFO] Windup Rulesets BOM ... SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.721 s (Wall Clock)
> [INFO] Finished at: 2014-10-22T16:39:30+01:00
> [INFO] Final Memory: 21M/211M
> [INFO]
>
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at
> org.apache.maven.lifecycle.internal.builder.BuilderCommon.handleBuildError(BuilderCommon.java:147)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurre
[jira] (MNG-5705) NPE in BuilderCommon.handleBuildError(BuilderCommon.java:147)
[
https://jira.codehaus.org/browse/MNG-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ondrej Zizka updated MNG-5705:
--
Affects Version/s: 3.2.1
> NPE in BuilderCommon.handleBuildError(BuilderCommon.java:147)
> -
>
> Key: MNG-5705
> URL: https://jira.codehaus.org/browse/MNG-5705
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.2.1
>Reporter: Ondrej Zizka
>
> STR:
> {code}
> git clone g...@github.com:windup/windup.git
> cd windup
> git checkout 91a454b # MavenNPE2
> mvn -T 1C clean javadoc:aggregate -PjavadocDist
> {code}
> {code}
> [INFO]
>
> [INFO] Windup Parent . SUCCESS [ 0.132 s]
> [INFO] Windup Engine - Frames SUCCESS [ 0.009 s]
> [INFO] Windup Engine - Utils . SUCCESS [ 0.035 s]
> [INFO] Windup Engine - Graph Parent .. SUCCESS [ 0.004 s]
> [INFO] Windup Engine - Graph API . FAILURE [ 0.003 s]
> [INFO] Windup Engine - Graph Impl SKIPPED
> [INFO] Windup Engine - Graph Addon ... SKIPPED
> [INFO] Windup Engine - Graph Tests ... SKIPPED
> [INFO] Windup Engine - Config Parent . SUCCESS [ 0.008 s]
> [INFO] Windup Engine - Config API SKIPPED
> [INFO] Windup Engine - Config Impl ... SKIPPED
> [INFO] Windup Engine - Config Addon .. SKIPPED
> [INFO] Windup Engine - Decompiler SUCCESS [ 0.011 s]
> [INFO] Windup Engine - Decompiler API SUCCESS [ 0.039 s]
> [INFO] Windup Engine - Decompiler Procyon SKIPPED
> [INFO] Windup Extension - Config - XML ... SKIPPED
> [INFO] Windup Engine - Reporting Parent .. SUCCESS [ 0.016 s]
> [INFO] Windup Engine - Reporting API . SKIPPED
> [INFO] Windup Engine - Reporting Impl SKIPPED
> [INFO] Windup Engine - Reporting Addon ... SKIPPED
> [INFO] Windup Engine - Execution API Parent .. SUCCESS [ 0.003 s]
> [INFO] Windup Engine - Execution API . SKIPPED
> [INFO] Windup Engine - Execution API Impl SKIPPED
> [INFO] Windup Engine - Execution API Addon ... SKIPPED
> [INFO] Windup Rules - XML - Basic SKIPPED
> [INFO] Windup Extension - Config - Groovy SKIPPED
> [INFO] Windup Rules - Java - Basic ... SKIPPED
> [INFO] Windup Engine - Config Tests .. SKIPPED
> [INFO] Windup Rules - Java EE - Basic SKIPPED
> [INFO] Windup Engine - Execution API Tests ... SKIPPED
> [INFO] Windup Engine - Reporting Tests ... SKIPPED
> [INFO] Windup Engine - UI SKIPPED
> [INFO] Windup Engine - Test Utilities SUCCESS [ 0.004 s]
> [INFO] Windup Engine - Tests . SKIPPED
> [INFO] Windup - Bootstrap module . SUCCESS [ 0.002 s]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ decompiler-api ---
> [INFO] Windup - Distribution Build ... FAILURE [ 0.008 s]
> [INFO] Windup Rulesets BOM ... SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.721 s (Wall Clock)
> [INFO] Finished at: 2014-10-22T16:39:30+01:00
> [INFO] Final Memory: 21M/211M
> [INFO]
>
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at
> org.apache.maven.lifecycle.internal.builder.BuilderCommon.handleBuildError(BuilderCommon.java:147)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExec
[jira] (MNG-5705) NPE on parallel build in BuilderCommon.handleBuildError(BuilderCommon.java:147)
[
https://jira.codehaus.org/browse/MNG-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ondrej Zizka updated MNG-5705:
--
Description:
STR:
{code}
git clone g...@github.com:OndraZizka/windup.git
cd windup
git checkout 91a454b # MavenNPE2
mvn -T 1C clean javadoc:aggregate -PjavadocDist
{code}
{code}
[INFO]
[INFO] Windup Parent . SUCCESS [ 0.132 s]
[INFO] Windup Engine - Frames SUCCESS [ 0.009 s]
[INFO] Windup Engine - Utils . SUCCESS [ 0.035 s]
[INFO] Windup Engine - Graph Parent .. SUCCESS [ 0.004 s]
[INFO] Windup Engine - Graph API . FAILURE [ 0.003 s]
[INFO] Windup Engine - Graph Impl SKIPPED
[INFO] Windup Engine - Graph Addon ... SKIPPED
[INFO] Windup Engine - Graph Tests ... SKIPPED
[INFO] Windup Engine - Config Parent . SUCCESS [ 0.008 s]
[INFO] Windup Engine - Config API SKIPPED
[INFO] Windup Engine - Config Impl ... SKIPPED
[INFO] Windup Engine - Config Addon .. SKIPPED
[INFO] Windup Engine - Decompiler SUCCESS [ 0.011 s]
[INFO] Windup Engine - Decompiler API SUCCESS [ 0.039 s]
[INFO] Windup Engine - Decompiler Procyon SKIPPED
[INFO] Windup Extension - Config - XML ... SKIPPED
[INFO] Windup Engine - Reporting Parent .. SUCCESS [ 0.016 s]
[INFO] Windup Engine - Reporting API . SKIPPED
[INFO] Windup Engine - Reporting Impl SKIPPED
[INFO] Windup Engine - Reporting Addon ... SKIPPED
[INFO] Windup Engine - Execution API Parent .. SUCCESS [ 0.003 s]
[INFO] Windup Engine - Execution API . SKIPPED
[INFO] Windup Engine - Execution API Impl SKIPPED
[INFO] Windup Engine - Execution API Addon ... SKIPPED
[INFO] Windup Rules - XML - Basic SKIPPED
[INFO] Windup Extension - Config - Groovy SKIPPED
[INFO] Windup Rules - Java - Basic ... SKIPPED
[INFO] Windup Engine - Config Tests .. SKIPPED
[INFO] Windup Rules - Java EE - Basic SKIPPED
[INFO] Windup Engine - Execution API Tests ... SKIPPED
[INFO] Windup Engine - Reporting Tests ... SKIPPED
[INFO] Windup Engine - UI SKIPPED
[INFO] Windup Engine - Test Utilities SUCCESS [ 0.004 s]
[INFO] Windup Engine - Tests . SKIPPED
[INFO] Windup - Bootstrap module . SUCCESS [ 0.002 s]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ decompiler-api ---
[INFO] Windup - Distribution Build ... FAILURE [ 0.008 s]
[INFO] Windup Rulesets BOM ... SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1.721 s (Wall Clock)
[INFO] Finished at: 2014-10-22T16:39:30+01:00
[INFO] Final Memory: 21M/211M
[INFO]
[ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at
org.apache.maven.lifecycle.internal.builder.BuilderCommon.handleBuildError(BuilderCommon.java:147)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:121)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at
org.apache.maven.execution.MavenSession.getPluginContext(MavenSession.java:314)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:504)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:12
[jira] Commented: (MNGSITE-124) Better documentation related to repository order
[ http://jira.codehaus.org/browse/MNGSITE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=248907#action_248907 ] Ondrej Zizka commented on MNGSITE-124: -- It would be useful if one could modify the order by permuting the order of activated profiles. Which means, mvn -Pabc,def,ghi would give different repo order than mvn -Pghi,abc,def . Does Maven documentation say something about the effect of profile ordering? Since this is not yet documented, this could be a good time to enable such feature before it gets carved to the stone. > Better documentation related to repository order > > > Key: MNGSITE-124 > URL: http://jira.codehaus.org/browse/MNGSITE-124 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Paul Gier > > I was not able to find clear documentation describing the order of > repositories used during a build. For example, the documentation should > answer the following questions. > 1. Which repositories are used first, the ones defined in settings.xml or in > the pom.xml or super pom? > 2. The order of repositories defined in the settings.xml profiles seems to be > the reverse of what one would expect when viewed in the effective-pom, why is > this? > 3. If a repository ID in settings.xml matches one defined in pom.xml which > one takes priority? > Some additional information is available in the JBoss build forum. > http://community.jboss.org/thread/160185 -- 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: (MNGSITE-124) Better documentation related to repository order
[ http://jira.codehaus.org/browse/MNGSITE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=248907#action_248907 ] Ondrej Zizka edited comment on MNGSITE-124 at 12/17/10 12:36 PM: - It would be useful if one could modify the order by permuting the order of activated profiles. Which means, mvn -Pabc,def,ghi would give different repo order than mvn -Pghi,abc,def . Does Maven documentation say something about the effect of profile activation ordering? Since this is not yet documented, this could be a good time to enable such feature before the current state gets carved to the stone. was (Author: pekarna): It would be useful if one could modify the order by permuting the order of activated profiles. Which means, mvn -Pabc,def,ghi would give different repo order than mvn -Pghi,abc,def . Does Maven documentation say something about the effect of profile ordering? Since this is not yet documented, this could be a good time to enable such feature before it gets carved to the stone. > Better documentation related to repository order > > > Key: MNGSITE-124 > URL: http://jira.codehaus.org/browse/MNGSITE-124 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Paul Gier > > I was not able to find clear documentation describing the order of > repositories used during a build. For example, the documentation should > answer the following questions. > 1. Which repositories are used first, the ones defined in settings.xml or in > the pom.xml or super pom? > 2. The order of repositories defined in the settings.xml profiles seems to be > the reverse of what one would expect when viewed in the effective-pom, why is > this? > 3. If a repository ID in settings.xml matches one defined in pom.xml which > one takes priority? > Some additional information is available in the JBoss build forum. > http://community.jboss.org/thread/160185 -- 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-4946) Let the order of profiles in `mvn -P...` determine their order in effective POM
Let the order of profiles in `mvn -P...` determine their order in effective POM --- Key: MNG-4946 URL: http://jira.codehaus.org/browse/MNG-4946 Project: Maven 2 & 3 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.2.1 Reporter: Ondrej Zizka Currently, the order of profile references on the command line does not affect the order in which they are merged to the effective POM. Easy test: 1) Create two profiles in settings-test.xml, say profA and profB 2) add a repository to each, say repoA, repoB 3) run `mvn -s settings-test.xml -PprofA,profB help:effective-pom` 4) run `mvn -s settings-test.xml -PprofB,profA help:effective-pom` You will see that the order of repositories is not affected by the order of profiles after -P. This behavior is not documented, AFAICT, so changing it shouldn't be considered as breaking backward compatibility. A possibility to determine the order in which profiles are applied would be a great improvement since it would allow changing the build dramatically just by slightly changing the command. -- 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: (MNGSITE-124) Better documentation related to repository order
[ http://jira.codehaus.org/browse/MNGSITE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=248996#action_248996 ] Ondrej Zizka commented on MNGSITE-124: -- Paul, done, MNG-4946 . > Better documentation related to repository order > > > Key: MNGSITE-124 > URL: http://jira.codehaus.org/browse/MNGSITE-124 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Paul Gier > > I was not able to find clear documentation describing the order of > repositories used during a build. For example, the documentation should > answer the following questions. > 1. Which repositories are used first, the ones defined in settings.xml or in > the pom.xml or super pom? > 2. The order of repositories defined in the settings.xml profiles seems to be > the reverse of what one would expect when viewed in the effective-pom, why is > this? > 3. If a repository ID in settings.xml matches one defined in pom.xml which > one takes priority? > Some additional information is available in the JBoss build forum. > http://community.jboss.org/thread/160185 -- 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-4947) NPE in at org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType()
NPE in at org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType() Key: MNG-4947 URL: http://jira.codehaus.org/browse/MNG-4947 Project: Maven 2 & 3 Issue Type: Bug Components: Bootstrap & Build Affects Versions: 2.2.1 Reporter: Ondrej Zizka STR: 1) svn co https://anonsvn.jboss.org/repos/hibernate/core/tags/hibernate-3.3.2.GA_CP03 2) cd hibernate-3.3.2.GA_CP03/src/core 3) Download the attached settings-hbn.xml 4) mvn -s ../../settings-hbn.xml site hibernate/src/core $ mvn -s ../../settings-hbn.xml site ... 164K downloaded (plexus-utils-1.1.jar) 16K downloaded (wagon-webdav-1.0-beta-2.jar) [INFO] [INFO] Building Hibernate Core Parent POM [INFO]task-segment: [site] [INFO] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType(DefaultConverterLookup.java:115) at org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.lookupConverterForType(DefaultConverterLookup.java:92) at org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration(CollectionConverter.java:175) at org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137) at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56) at org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:54) at org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:47) at org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhase.execute(AutoConfigurePhase.java:39) at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) at org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.apache.maven.execution.MavenSession.lookup(MavenSession.java:138) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle(DefaultLifecycleExecutor.java:1358) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:1275) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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
[jira] Updated: (MNG-4947) NPE in at org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType()
[ http://jira.codehaus.org/browse/MNG-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Zizka updated MNG-4947: -- Attachment: settings-hbn.xml > NPE in at > org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType() > > > Key: MNG-4947 > URL: http://jira.codehaus.org/browse/MNG-4947 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka > Attachments: MNG-4947 - NPE during site build.txt, settings-hbn.xml > > > STR: > 1) svn co > https://anonsvn.jboss.org/repos/hibernate/core/tags/hibernate-3.3.2.GA_CP03 > 2) cd hibernate-3.3.2.GA_CP03/src/core > 3) Download the attached settings-hbn.xml > 4) mvn -s ../../settings-hbn.xml site > hibernate/src/core $ mvn -s ../../settings-hbn.xml site > ... > 164K downloaded (plexus-utils-1.1.jar) > 16K downloaded (wagon-webdav-1.0-beta-2.jar) > [INFO] > > [INFO] Building Hibernate Core Parent POM > [INFO]task-segment: [site] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType(DefaultConverterLookup.java:115) > at > org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.lookupConverterForType(DefaultConverterLookup.java:92) > at > org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration(CollectionConverter.java:175) > at > org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137) > at > org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56) > at > org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:54) > at > org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:47) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhase.execute(AutoConfigurePhase.java:39) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) > at > org.apache.maven.execution.MavenSession.lookup(MavenSession.java:138) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle(DefaultLifecycleExecutor.java:1358) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1292) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:1275) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at >
[jira] Updated: (MNG-4947) NPE in at org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType()
[ http://jira.codehaus.org/browse/MNG-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Zizka updated MNG-4947: -- Attachment: MNG-4947 - NPE during site build.txt > NPE in at > org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType() > > > Key: MNG-4947 > URL: http://jira.codehaus.org/browse/MNG-4947 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka > Attachments: MNG-4947 - NPE during site build.txt, settings-hbn.xml > > > STR: > 1) svn co > https://anonsvn.jboss.org/repos/hibernate/core/tags/hibernate-3.3.2.GA_CP03 > 2) cd hibernate-3.3.2.GA_CP03/src/core > 3) Download the attached settings-hbn.xml > 4) mvn -s ../../settings-hbn.xml site > hibernate/src/core $ mvn -s ../../settings-hbn.xml site > ... > 164K downloaded (plexus-utils-1.1.jar) > 16K downloaded (wagon-webdav-1.0-beta-2.jar) > [INFO] > > [INFO] Building Hibernate Core Parent POM > [INFO]task-segment: [site] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType(DefaultConverterLookup.java:115) > at > org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.lookupConverterForType(DefaultConverterLookup.java:92) > at > org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration(CollectionConverter.java:175) > at > org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137) > at > org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56) > at > org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:54) > at > org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:47) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhase.execute(AutoConfigurePhase.java:39) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) > at > org.apache.maven.execution.MavenSession.lookup(MavenSession.java:138) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle(DefaultLifecycleExecutor.java:1358) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1292) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:1275) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:
[jira] Commented: (MNG-4947) NPE in at org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType()
[ http://jira.codehaus.org/browse/MNG-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249162#action_249162 ] Ondrej Zizka commented on MNG-4947: --- Can't reproduce. However someone could check the code and handle the pottential null value. > NPE in at > org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType() > > > Key: MNG-4947 > URL: http://jira.codehaus.org/browse/MNG-4947 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka > Attachments: MNG-4947 - NPE during site build.txt, settings-hbn.xml > > > STR: > 1) svn co > https://anonsvn.jboss.org/repos/hibernate/core/tags/hibernate-3.3.2.GA_CP03 > 2) cd hibernate-3.3.2.GA_CP03/src/core > 3) Download the attached settings-hbn.xml > 4) mvn -s ../../settings-hbn.xml site > hibernate/src/core $ mvn -s ../../settings-hbn.xml site > ... > 164K downloaded (plexus-utils-1.1.jar) > 16K downloaded (wagon-webdav-1.0-beta-2.jar) > [INFO] > > [INFO] Building Hibernate Core Parent POM > [INFO]task-segment: [site] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType(DefaultConverterLookup.java:115) > at > org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.lookupConverterForType(DefaultConverterLookup.java:92) > at > org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration(CollectionConverter.java:175) > at > org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137) > at > org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56) > at > org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:54) > at > org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:47) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhase.execute(AutoConfigurePhase.java:39) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) > at > org.apache.maven.execution.MavenSession.lookup(MavenSession.java:138) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle(DefaultLifecycleExecutor.java:1358) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1292) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:1275) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.e
[jira] Commented: (MNG-4946) Let the order of profiles in `mvn -P...` determine their order in effective POM
[ http://jira.codehaus.org/browse/MNG-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249202#action_249202 ] Ondrej Zizka commented on MNG-4946: --- Currently, the resulting order is: 1. settings.xml - Auto-activated profiles (), reverse definition order 2. settings.xml - CLI activated profiles, reverse definition order 3. pom.xml repos 4. parent pom repos And adding auto-activated profile to -P does not change the result. > Let the order of profiles in `mvn -P...` determine their order in effective > POM > --- > > Key: MNG-4946 > URL: http://jira.codehaus.org/browse/MNG-4946 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka > > Currently, the order of profile references on the command line does not > affect the order in which they are merged to the effective POM. > Easy test: > 1) Create two profiles in settings-test.xml, say profA and profB > 2) add a repository to each, say repoA, repoB > 3) run `mvn -s settings-test.xml -PprofA,profB help:effective-pom` > 4) run `mvn -s settings-test.xml -PprofB,profA help:effective-pom` > You will see that the order of repositories is not affected by the order of > profiles after -P. > This behavior is not documented, AFAICT, so changing it shouldn't be > considered as breaking backward compatibility. > A possibility to determine the order in which profiles are applied would be a > great improvement since it would allow changing the build dramatically just > by slightly changing the command. -- 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-4946) Let the order of profiles in `mvn -P...` determine their order in effective POM
[ http://jira.codehaus.org/browse/MNG-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249217#action_249217 ] Ondrej Zizka commented on MNG-4946: --- The use case is any case when you want to have the profiles precedence under control. Since Maven builds customization is based on merging one POM into other, the user should be able to specify the order in which this operation happens for the same-level "entities", e.g. two profiles in settings.xml. Do you really think that CLI param is something unstable? Usually the builds are run from some CI tool or at least script, anyway. Plus, this would apply only when the profiles actually overlap. In that case, it's most probably intentional, and it's their author's responsibility to document the proper order in which they are to be applied. > Let the order of profiles in `mvn -P...` determine their order in effective > POM > --- > > Key: MNG-4946 > URL: http://jira.codehaus.org/browse/MNG-4946 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka > > Currently, the order of profile references on the command line does not > affect the order in which they are merged to the effective POM. > Easy test: > 1) Create two profiles in settings-test.xml, say profA and profB > 2) add a repository to each, say repoA, repoB > 3) run `mvn -s settings-test.xml -PprofA,profB help:effective-pom` > 4) run `mvn -s settings-test.xml -PprofB,profA help:effective-pom` > You will see that the order of repositories is not affected by the order of > profiles after -P. > This behavior is not documented, AFAICT, so changing it shouldn't be > considered as breaking backward compatibility. > A possibility to determine the order in which profiles are applied would be a > great improvement since it would allow changing the build dramatically just > by slightly changing the command. -- 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: (MNG-4946) Let the order of profiles in `mvn -P...` determine their order in effective POM
[ http://jira.codehaus.org/browse/MNG-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249217#action_249217 ] Ondrej Zizka edited comment on MNG-4946 at 12/20/10 7:30 PM: - Hi Benjamin, The use case is any case when you want to have the profiles precedence under control. Since Maven builds customization is based on merging one POM into other, the user should be able to specify the order in which this operation happens for the same-level "entities", e.g. two profiles in settings.xml. Do you really think that CLI param is something unstable? Usually the builds are run from some CI tool or at least script, anyway. Plus, this would apply only when the profiles actually overlap. In that case, it's most probably intentional, and it's their author's responsibility to document the proper order in which they are to be applied. was (Author: pekarna): The use case is any case when you want to have the profiles precedence under control. Since Maven builds customization is based on merging one POM into other, the user should be able to specify the order in which this operation happens for the same-level "entities", e.g. two profiles in settings.xml. Do you really think that CLI param is something unstable? Usually the builds are run from some CI tool or at least script, anyway. Plus, this would apply only when the profiles actually overlap. In that case, it's most probably intentional, and it's their author's responsibility to document the proper order in which they are to be applied. > Let the order of profiles in `mvn -P...` determine their order in effective > POM > --- > > Key: MNG-4946 > URL: http://jira.codehaus.org/browse/MNG-4946 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka > > Currently, the order of profile references on the command line does not > affect the order in which they are merged to the effective POM. > Easy test: > 1) Create two profiles in settings-test.xml, say profA and profB > 2) add a repository to each, say repoA, repoB > 3) run `mvn -s settings-test.xml -PprofA,profB help:effective-pom` > 4) run `mvn -s settings-test.xml -PprofB,profA help:effective-pom` > You will see that the order of repositories is not affected by the order of > profiles after -P. > This behavior is not documented, AFAICT, so changing it shouldn't be > considered as breaking backward compatibility. > A possibility to determine the order in which profiles are applied would be a > great improvement since it would allow changing the build dramatically just > by slightly changing the command. -- 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: (MNG-4946) Let the order of profiles in `mvn -P...` determine their order in effective POM
[ http://jira.codehaus.org/browse/MNG-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249217#action_249217 ] Ondrej Zizka edited comment on MNG-4946 at 12/20/10 7:31 PM: - Hi Benjamin, The use case is any case when the user needs to have the profiles precedence under control. Since Maven builds customization is based on merging one POM into other, the user should be able to specify the order in which this operation happens for the same-level "entities", e.g. two profiles in settings.xml. Do you really think that CLI param is something unstable? Usually the builds are run from some CI tool or at least script, anyway. Plus, this would apply only when the profiles actually overlap. In that case, it's most probably intentional, and it's their author's responsibility to document the proper order in which they are to be applied. was (Author: pekarna): Hi Benjamin, The use case is any case when you want to have the profiles precedence under control. Since Maven builds customization is based on merging one POM into other, the user should be able to specify the order in which this operation happens for the same-level "entities", e.g. two profiles in settings.xml. Do you really think that CLI param is something unstable? Usually the builds are run from some CI tool or at least script, anyway. Plus, this would apply only when the profiles actually overlap. In that case, it's most probably intentional, and it's their author's responsibility to document the proper order in which they are to be applied. > Let the order of profiles in `mvn -P...` determine their order in effective > POM > --- > > Key: MNG-4946 > URL: http://jira.codehaus.org/browse/MNG-4946 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka > > Currently, the order of profile references on the command line does not > affect the order in which they are merged to the effective POM. > Easy test: > 1) Create two profiles in settings-test.xml, say profA and profB > 2) add a repository to each, say repoA, repoB > 3) run `mvn -s settings-test.xml -PprofA,profB help:effective-pom` > 4) run `mvn -s settings-test.xml -PprofB,profA help:effective-pom` > You will see that the order of repositories is not affected by the order of > profiles after -P. > This behavior is not documented, AFAICT, so changing it shouldn't be > considered as breaking backward compatibility. > A possibility to determine the order in which profiles are applied would be a > great improvement since it would allow changing the build dramatically just > by slightly changing the command. -- 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: (MNG-4946) Let the order of profiles in `mvn -P...` determine their order in effective POM
[ http://jira.codehaus.org/browse/MNG-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249217#action_249217 ] Ondrej Zizka edited comment on MNG-4946 at 12/20/10 7:33 PM: - Hi Benjamin, The use case is any case when the user needs to have the profiles precedence under control. Since Maven builds customization is based on merging one POM into other, the user should be able to specify the order in which this operation happens for the same-level "entities", e.g. two profiles in settings.xml. Do you really think that CLI param order is something unstable? Usually the builds are run from some CI tool or at least script, anyway. Plus, this would apply only when the profiles actually overlap. In that case, it's most probably intentional, and it's their author's responsibility to document the proper order in which they are to be applied. was (Author: pekarna): Hi Benjamin, The use case is any case when the user needs to have the profiles precedence under control. Since Maven builds customization is based on merging one POM into other, the user should be able to specify the order in which this operation happens for the same-level "entities", e.g. two profiles in settings.xml. Do you really think that CLI param is something unstable? Usually the builds are run from some CI tool or at least script, anyway. Plus, this would apply only when the profiles actually overlap. In that case, it's most probably intentional, and it's their author's responsibility to document the proper order in which they are to be applied. > Let the order of profiles in `mvn -P...` determine their order in effective > POM > --- > > Key: MNG-4946 > URL: http://jira.codehaus.org/browse/MNG-4946 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka > > Currently, the order of profile references on the command line does not > affect the order in which they are merged to the effective POM. > Easy test: > 1) Create two profiles in settings-test.xml, say profA and profB > 2) add a repository to each, say repoA, repoB > 3) run `mvn -s settings-test.xml -PprofA,profB help:effective-pom` > 4) run `mvn -s settings-test.xml -PprofB,profA help:effective-pom` > You will see that the order of repositories is not affected by the order of > profiles after -P. > This behavior is not documented, AFAICT, so changing it shouldn't be > considered as breaking backward compatibility. > A possibility to determine the order in which profiles are applied would be a > great improvement since it would allow changing the build dramatically just > by slightly changing the command. -- 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: (MNG-4946) Let the order of profiles in `mvn -P...` determine their order in effective POM
[ http://jira.codehaus.org/browse/MNG-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249217#action_249217 ] Ondrej Zizka edited comment on MNG-4946 at 12/20/10 7:51 PM: - Hi Benjamin, The use case is any case when the user needs to have the profiles precedence under control. Since Maven builds customization is based on merging one POM into other, the user should be able to specify the order in which this operation happens for the same-level "entities", e.g. two profiles in settings.xml. Do you really think that CLI param order is something unstable? Usually the builds are run from some CI tool or at least a script, anyway. Plus, this would apply only when the profiles actually overlap. In that case, it's most probably intentional, and it's their author's responsibility to document the proper order in which they are to be applied. was (Author: pekarna): Hi Benjamin, The use case is any case when the user needs to have the profiles precedence under control. Since Maven builds customization is based on merging one POM into other, the user should be able to specify the order in which this operation happens for the same-level "entities", e.g. two profiles in settings.xml. Do you really think that CLI param order is something unstable? Usually the builds are run from some CI tool or at least script, anyway. Plus, this would apply only when the profiles actually overlap. In that case, it's most probably intentional, and it's their author's responsibility to document the proper order in which they are to be applied. > Let the order of profiles in `mvn -P...` determine their order in effective > POM > --- > > Key: MNG-4946 > URL: http://jira.codehaus.org/browse/MNG-4946 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka > > Currently, the order of profile references on the command line does not > affect the order in which they are merged to the effective POM. > Easy test: > 1) Create two profiles in settings-test.xml, say profA and profB > 2) add a repository to each, say repoA, repoB > 3) run `mvn -s settings-test.xml -PprofA,profB help:effective-pom` > 4) run `mvn -s settings-test.xml -PprofB,profA help:effective-pom` > You will see that the order of repositories is not affected by the order of > profiles after -P. > This behavior is not documented, AFAICT, so changing it shouldn't be > considered as breaking backward compatibility. > A possibility to determine the order in which profiles are applied would be a > great improvement since it would allow changing the build dramatically just > by slightly changing the command. -- 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-4946) Let the order of profiles in `mvn -P...` determine their order in effective POM
[ http://jira.codehaus.org/browse/MNG-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249257#action_249257 ] Ondrej Zizka commented on MNG-4946: --- > Which he can be adjusting their declaration order in the settings or POM. It can not if some of them are auto-activated. Those go first, no matter what. One real use case: settings.xml with two profiles, 1) profA, auto-activated, 2) profB, activated by -P profB. They contain different repository definition. I need Maven to query profB's repository first, but there's no way because Maven ignores the order of -P. If this improvement was implemented, I could do "mvn install -PprofB,profA", and voi-la - Maven would do what I need. > Let the order of profiles in `mvn -P...` determine their order in effective > POM > --- > > Key: MNG-4946 > URL: http://jira.codehaus.org/browse/MNG-4946 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka > > Currently, the order of profile references on the command line does not > affect the order in which they are merged to the effective POM. > Easy test: > 1) Create two profiles in settings-test.xml, say profA and profB > 2) add a repository to each, say repoA, repoB > 3) run `mvn -s settings-test.xml -PprofA,profB help:effective-pom` > 4) run `mvn -s settings-test.xml -PprofB,profA help:effective-pom` > You will see that the order of repositories is not affected by the order of > profiles after -P. > This behavior is not documented, AFAICT, so changing it shouldn't be > considered as breaking backward compatibility. > A possibility to determine the order in which profiles are applied would be a > great improvement since it would allow changing the build dramatically just > by slightly changing the command. -- 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: (MNG-4946) Let the order of profiles in `mvn -P...` determine their order in effective POM
[ http://jira.codehaus.org/browse/MNG-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249257#action_249257 ] Ondrej Zizka edited comment on MNG-4946 at 12/21/10 6:33 AM: - > Which he can be adjusting their declaration order in the settings or POM. That's my point - changing settings.xml everytime you need to change your build is not much user-friendly, and when you need to do int programatically, it's kind of annoying. And even when defining in XML, you can *not* set the order in all cases: if some of the profiles are auto-activated. Those go first, no matter what. One real use case: settings.xml with two profiles, 1) profA, auto-activated, 2) profB, activated by -P profB. They contain different repository definition. I need Maven to query profB's repository first, but there's no way because Maven ignores the order of -P. If this improvement was implemented, I could do "mvn install -PprofB,profA", and voi-la - Maven would do what I need. was (Author: pekarna): > Which he can be adjusting their declaration order in the settings or POM. It can not if some of them are auto-activated. Those go first, no matter what. One real use case: settings.xml with two profiles, 1) profA, auto-activated, 2) profB, activated by -P profB. They contain different repository definition. I need Maven to query profB's repository first, but there's no way because Maven ignores the order of -P. If this improvement was implemented, I could do "mvn install -PprofB,profA", and voi-la - Maven would do what I need. > Let the order of profiles in `mvn -P...` determine their order in effective > POM > --- > > Key: MNG-4946 > URL: http://jira.codehaus.org/browse/MNG-4946 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka > > Currently, the order of profile references on the command line does not > affect the order in which they are merged to the effective POM. > Easy test: > 1) Create two profiles in settings-test.xml, say profA and profB > 2) add a repository to each, say repoA, repoB > 3) run `mvn -s settings-test.xml -PprofA,profB help:effective-pom` > 4) run `mvn -s settings-test.xml -PprofB,profA help:effective-pom` > You will see that the order of repositories is not affected by the order of > profiles after -P. > This behavior is not documented, AFAICT, so changing it shouldn't be > considered as breaking backward compatibility. > A possibility to determine the order in which profiles are applied would be a > great improvement since it would allow changing the build dramatically just > by slightly changing the command. -- 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-4946) Let the order of profiles in `mvn -P...` determine their order in effective POM
[ http://jira.codehaus.org/browse/MNG-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249259#action_249259 ] Ondrej Zizka commented on MNG-4946: --- Ok how about limiting this effect only to the repositories? > Let the order of profiles in `mvn -P...` determine their order in effective > POM > --- > > Key: MNG-4946 > URL: http://jira.codehaus.org/browse/MNG-4946 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka > > Currently, the order of profile references on the command line does not > affect the order in which they are merged to the effective POM. > Easy test: > 1) Create two profiles in settings-test.xml, say profA and profB > 2) add a repository to each, say repoA, repoB > 3) run `mvn -s settings-test.xml -PprofA,profB help:effective-pom` > 4) run `mvn -s settings-test.xml -PprofB,profA help:effective-pom` > You will see that the order of repositories is not affected by the order of > profiles after -P. > This behavior is not documented, AFAICT, so changing it shouldn't be > considered as breaking backward compatibility. > A possibility to determine the order in which profiles are applied would be a > great improvement since it would allow changing the build dramatically just > by slightly changing the command. -- 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-4972) NPE in DefaultConverterLookup.findConverterForType()
NPE in DefaultConverterLookup.findConverterForType() Key: MNG-4972 URL: http://jira.codehaus.org/browse/MNG-4972 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 2.2.1 Reporter: Ondrej Zizka $ mvn --version Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_22 Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: "linux" version: "2.6.24-28-server" arch: "i386" Family: "unix" Steps to reproduce: 1) Check out Hibernate Core 3.3.2 2) Download the attached settings-hbn.xml and change the to some empty dir 2) cd src/core 3) mvn -s settings-hbn.xml clean install (no profile) 4) When I run this for the first time (empty repo), I've got the exception below. ... Downloading: http://uk.maven.org/maven2/commons-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.jar Downloading: http://uk.maven.org/maven2/jdom/jdom/1.0/jdom-1.0.jar Downloading: http://uk.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar Downloading: http://uk.maven.org/maven2/de/zeigermann/xml/xml-im-exporter/1.1/xml-im-exporter-1.1.jar Downloading: http://uk.maven.org/maven2/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar Downloading: http://uk.maven.org/maven2/slide/slide-webdavlib/2.1/slide-webdavlib-2.1.jar Downloading: http://uk.maven.org/maven2/org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.jar [INFO] [INFO] Building Hibernate Core Parent POM [INFO]task-segment: [clean, install] [INFO] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType(DefaultConverterLookup.java:115) at org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.lookupConverterForType(DefaultConverterLookup.java:92) at org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration(CollectionConverter.java:175) at org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137) at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56) at org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:54) at org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:47) at org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhase.execute(AutoConfigurePhase.java:39) at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) at org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.apache.maven.execution.MavenSession.lookup(MavenSession.java:138) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle(DefaultLifecycleExecutor.java:1358) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:1275) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLife
[jira] Updated: (MNG-4972) NPE in DefaultConverterLookup.findConverterForType()
[ http://jira.codehaus.org/browse/MNG-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Zizka updated MNG-4972: -- Attachment: settings-hbn.xml Attaching settings.xml. Also change the path to the JDK 1.6. Build with JDK 1.5 !! > NPE in DefaultConverterLookup.findConverterForType() > > > Key: MNG-4972 > URL: http://jira.codehaus.org/browse/MNG-4972 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka > Attachments: settings-hbn.xml > > > $ mvn --version > Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > Java version: 1.6.0_22 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre > Default locale: en_US, platform encoding: ANSI_X3.4-1968 > OS name: "linux" version: "2.6.24-28-server" arch: "i386" Family: "unix" > Steps to reproduce: > 1) Check out Hibernate Core 3.3.2 > 2) Download the attached settings-hbn.xml and change the to > some empty dir > 2) cd src/core > 3) mvn -s settings-hbn.xml clean install (no profile) > 4) When I run this for the first time (empty repo), I've got the exception > below. > ... > Downloading: > http://uk.maven.org/maven2/commons-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.jar > Downloading: http://uk.maven.org/maven2/jdom/jdom/1.0/jdom-1.0.jar > Downloading: > http://uk.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > Downloading: > http://uk.maven.org/maven2/de/zeigermann/xml/xml-im-exporter/1.1/xml-im-exporter-1.1.jar > Downloading: > http://uk.maven.org/maven2/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar > Downloading: > http://uk.maven.org/maven2/slide/slide-webdavlib/2.1/slide-webdavlib-2.1.jar > Downloading: > http://uk.maven.org/maven2/org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.jar > [INFO] > > [INFO] Building Hibernate Core Parent POM > [INFO]task-segment: [clean, install] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType(DefaultConverterLookup.java:115) > at > org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.lookupConverterForType(DefaultConverterLookup.java:92) > at > org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration(CollectionConverter.java:175) > at > org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137) > at > org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56) > at > org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:54) > at > org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:47) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhase.execute(AutoConfigurePhase.java:39) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) > at > org.apache.maven.execution.MavenSession.lookup(MavenSession.java:138) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle(DefaultLifecycleExecutor.java:1358) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1292) > at > org.apache.
[jira] Commented: (MNG-4972) NPE in DefaultConverterLookup.findConverterForType()
[ http://jira.codehaus.org/browse/MNG-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=251556#action_251556 ] Ondrej Zizka commented on MNG-4972: --- I, sorry for duplicate, I couldn't find so I thought I didn't file. 1) Some of your assumptions are correct. It's ..._CR3, 2) The src/core came from my build structure. So, I meant the root pom, Hibernate Agregator 3) I intentionally wrote (no profile) because that's what I done when I got the exception. I know that it's not the way to build the project, but it's a record how I got the bug which bugs me now and then in correctly configured builds. 4) I also get this bug rarely. However when I get it, it spoils quite a long chain of runs in continuous integration. 5) Anyway, the bug does not appear often, so if it's going to be buried with upcoming Maven 3, so be it. Thanks for trying. > NPE in DefaultConverterLookup.findConverterForType() > > > Key: MNG-4972 > URL: http://jira.codehaus.org/browse/MNG-4972 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Ondrej Zizka >Assignee: Benjamin Bentmann > Attachments: settings-hbn.xml > > > $ mvn --version > Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > Java version: 1.6.0_22 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre > Default locale: en_US, platform encoding: ANSI_X3.4-1968 > OS name: "linux" version: "2.6.24-28-server" arch: "i386" Family: "unix" > Steps to reproduce: > 1) Check out Hibernate Core 3.3.2 > 2) Download the attached settings-hbn.xml and change the to > some empty dir > 2) cd src/core > 3) mvn -s settings-hbn.xml clean install (no profile) > 4) When I run this for the first time (empty repo), I've got the exception > below. > ... > Downloading: > http://uk.maven.org/maven2/commons-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.jar > Downloading: http://uk.maven.org/maven2/jdom/jdom/1.0/jdom-1.0.jar > Downloading: > http://uk.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > Downloading: > http://uk.maven.org/maven2/de/zeigermann/xml/xml-im-exporter/1.1/xml-im-exporter-1.1.jar > Downloading: > http://uk.maven.org/maven2/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar > Downloading: > http://uk.maven.org/maven2/slide/slide-webdavlib/2.1/slide-webdavlib-2.1.jar > Downloading: > http://uk.maven.org/maven2/org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.jar > [INFO] > > [INFO] Building Hibernate Core Parent POM > [INFO]task-segment: [clean, install] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType(DefaultConverterLookup.java:115) > at > org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.lookupConverterForType(DefaultConverterLookup.java:92) > at > org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration(CollectionConverter.java:175) > at > org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137) > at > org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56) > at > org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:54) > at > org.codehaus.plexus.component.configurator.AbstractComponentConfigurator.configureComponent(AbstractComponentConfigurator.java:47) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhase.execute(AutoConfigurePhase.java:39) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) > at > org.codehaus.ple
[jira] Created: (MCOMPILER-145) Compiler: ${non-existent} resolved as "null", should emit a warning.
Compiler: ${non-existent} resolved as "null", should
emit a warning.
-
Key: MCOMPILER-145
URL: http://jira.codehaus.org/browse/MCOMPILER-145
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Reporter: Ondrej Zizka
Priority: Trivial
When having the following in a profile,
org.apache.maven.plugins
maven-compiler-plugin
1.6
1.6
1.6
${jdk16_home}/bin/javac
true
true
the build with ${jdk16_home} not set would fail with:
Embedded error: Error while executing the external compiler.
java.io.IOException: null/bin/javac: not found
I think that the unresolved property should emit a warning rather than being
converted to "null" since that is harder to track the issue down that way.
--
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] (MJAVADOC-344) -Dfooter doesn't set the Javadoc footer.
Ondrej Zizka created MJAVADOC-344:
-
Summary: -Dfooter doesn't set the Javadoc footer.
Key: MJAVADOC-344
URL: https://jira.codehaus.org/browse/MJAVADOC-344
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Reporter: Ondrej Zizka
This
http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#footer
says that the footer property has expression {code}$\{footer}{code}.
However, if I try
{code}
mvn javadoc:aggregate -PjavadocDist -Ddoctitle='FOO' -Dfooter='BAR'
{code}
I get
{code}
-doctitle
'FOO'
-footer
'Test project: Build 1.0-SNAPSHOT'
{code}
Setting {{}} in pom.xml works.
--
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-5289) -Dmaven.repo.local not honored
[
https://jira.codehaus.org/browse/MNG-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299892#comment-299892
]
Ondrej Zizka commented on MNG-5289:
---
Last command should have been: {code}mvn -o install -DallTests
-DskipTests{code}
> -Dmaven.repo.local not honored
> --
>
> Key: MNG-5289
> URL: https://jira.codehaus.org/browse/MNG-5289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
> Environment: Linux
>Reporter: Ondrej Zizka
>
> STR:
> 1) Checkout a multimodule project, e.g. JBoss AS 7
> {code}git clone git://github.com/jbossas/jboss-as.git{code}
> 2) {code}mvn -Dmaven.repo.local=foo dependencies:go-offline clean install
> -DallTests -DskipTests{code}
> 3) {code}mvn -Dmaven.repo.local=foo -o install -DallTests -DskipTests{code}
> This will complain about not having artifact XYZ.
> 4) On the other hand, this works:
> {code}
> mv ~/.m2/repository ~/.m2/repository_
> ln -s `pwd`/localRepo ~/.m2/repository
> mvn -o install
> {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] (MNG-5289) -Dmaven.repo.local not honored
Ondrej Zizka created MNG-5289:
-
Summary: -Dmaven.repo.local not honored
Key: MNG-5289
URL: https://jira.codehaus.org/browse/MNG-5289
Project: Maven 2 & 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0.3
Environment: Linux
Reporter: Ondrej Zizka
STR:
1) Checkout a multimodule project, e.g. JBoss AS 7
{code}git clone git://github.com/jbossas/jboss-as.git{code}
2) {code}mvn -Dmaven.repo.local=foo dependencies:go-offline clean install
-DallTests -DskipTests{code}
3) {code}mvn -Dmaven.repo.local=foo -o install -DallTests -DskipTests{code}
This will complain about not having artifact XYZ.
4) On the other hand, this works:
{code}
mv ~/.m2/repository ~/.m2/repository_
ln -s `pwd`/localRepo ~/.m2/repository
mvn -o install
{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] (MNG-5289) -Dmaven.repo.local not honored
[
https://jira.codehaus.org/browse/MNG-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299893#comment-299893
]
Ondrej Zizka commented on MNG-5289:
---
in settings.xml works too.
> -Dmaven.repo.local not honored
> --
>
> Key: MNG-5289
> URL: https://jira.codehaus.org/browse/MNG-5289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
> Environment: Linux
>Reporter: Ondrej Zizka
>
> STR:
> 1) Checkout a multimodule project, e.g. JBoss AS 7
> {code}git clone git://github.com/jbossas/jboss-as.git{code}
> 2) {code}mvn -Dmaven.repo.local=foo dependencies:go-offline clean install
> -DallTests -DskipTests{code}
> 3) {code}mvn -Dmaven.repo.local=foo -o install -DallTests -DskipTests{code}
> This will complain about not having artifact XYZ.
> 4) On the other hand, this works:
> {code}
> mv ~/.m2/repository ~/.m2/repository_
> ln -s `pwd`/localRepo ~/.m2/repository
> mvn -o install
> {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] (MNG-5289) -Dmaven.repo.local not honored
[
https://jira.codehaus.org/browse/MNG-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299894#comment-299894
]
Ondrej Zizka commented on MNG-5289:
---
To be precise, Maven complains:
{code}Non-resolvable import POM: The repository system is offline but the
artifact org.jboss.arquillian:arquillian-bom:pom:1.0.0.Final is not available
in the local repository. @ line 158, column 25 -> [Help 2]{code}
However, this file exists in the specified local repo:
{code}
ondra@lenovo:~/work/AS7/ozizka-git2$ ls -l
localRepo/org/jboss/arquillian/arquillian-bom/1.0.0.Final/
-rw-r--r-- 1 ondra ondra 10616 2012-05-17 16:48 arquillian-bom-1.0.0.Final.pom
-rw-r--r-- 1 ondra ondra 488 2012-05-29 00:53
arquillian-bom-1.0.0.Final.pom.lastUpdated
-rw-r--r-- 1 ondra ondra40 2012-05-17 16:48
arquillian-bom-1.0.0.Final.pom.sha1
-rw-r--r-- 1 ondra ondra 234 2012-05-29 00:53 _maven.repositorie
{code}
> -Dmaven.repo.local not honored
> --
>
> Key: MNG-5289
> URL: https://jira.codehaus.org/browse/MNG-5289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
> Environment: Linux
>Reporter: Ondrej Zizka
>
> STR:
> 1) Checkout a multimodule project, e.g. JBoss AS 7
> {code}git clone git://github.com/jbossas/jboss-as.git{code}
> 2) {code}mvn -Dmaven.repo.local=foo dependencies:go-offline clean install
> -DallTests -DskipTests{code}
> 3) {code}mvn -Dmaven.repo.local=foo -o install -DallTests -DskipTests{code}
> This will complain about not having artifact XYZ.
> 4) On the other hand, this works:
> {code}
> mv ~/.m2/repository ~/.m2/repository_
> ln -s `pwd`/localRepo ~/.m2/repository
> mvn -o install
> {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] (MNG-5289) -Dmaven.repo.local not honored
[
https://jira.codehaus.org/browse/MNG-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299893#comment-299893
]
Ondrej Zizka edited comment on MNG-5289 at 5/28/12 8:40 PM:
in settings.xml doesn't work either.
was (Author: pekarna):
in settings.xml works too.
> -Dmaven.repo.local not honored
> --
>
> Key: MNG-5289
> URL: https://jira.codehaus.org/browse/MNG-5289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
> Environment: Linux
>Reporter: Ondrej Zizka
>
> STR:
> 1) Checkout a multimodule project, e.g. JBoss AS 7
> {code}git clone git://github.com/jbossas/jboss-as.git{code}
> 2) {code}mvn -Dmaven.repo.local=foo dependencies:go-offline clean install
> -DallTests -DskipTests{code}
> 3) {code}mvn -Dmaven.repo.local=foo -o install -DallTests -DskipTests{code}
> This will complain about not having artifact XYZ.
> 4) On the other hand, this works:
> {code}
> mv ~/.m2/repository ~/.m2/repository_
> ln -s `pwd`/localRepo ~/.m2/repository
> mvn -o install
> {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] (MNG-5289) -Dmaven.repo.local not honored
[
https://jira.codehaus.org/browse/MNG-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299895#comment-299895
]
Ondrej Zizka commented on MNG-5289:
---
Hmm, interesting:
*When I removed the {{_maven.repositories}} file, it started working.*
This is an example of content:
{code}
#NOTE: This is an internal implementation file, its format can be changed
without prior notice.
#Tue May 29 00:53:54 CEST 2012
shrinkwrap-descriptors-bom-2.0.0-alpha-2.pom>jboss-public-repository-group=
shrinkwrap-descriptors-bom-2.0.0-alpha-2.pom>central-eap6=
{code}
> -Dmaven.repo.local not honored
> --
>
> Key: MNG-5289
> URL: https://jira.codehaus.org/browse/MNG-5289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
> Environment: Linux
>Reporter: Ondrej Zizka
>
> STR:
> 1) Checkout a multimodule project, e.g. JBoss AS 7
> {code}git clone git://github.com/jbossas/jboss-as.git{code}
> 2) {code}mvn -Dmaven.repo.local=foo dependencies:go-offline clean install
> -DallTests -DskipTests{code}
> 3) {code}mvn -Dmaven.repo.local=foo -o install -DallTests -DskipTests{code}
> This will complain about not having artifact XYZ.
> 4) On the other hand, this works:
> {code}
> mv ~/.m2/repository ~/.m2/repository_
> ln -s `pwd`/localRepo ~/.m2/repository
> mvn -o install
> {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] (MNG-5289) -Dmaven.repo.local not honored
[
https://jira.codehaus.org/browse/MNG-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299896#comment-299896
]
Ondrej Zizka commented on MNG-5289:
---
Workaround: {code}find localRepo/ -name _maven.repositories | xargs rm{code}
> -Dmaven.repo.local not honored
> --
>
> Key: MNG-5289
> URL: https://jira.codehaus.org/browse/MNG-5289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
> Environment: Linux
>Reporter: Ondrej Zizka
>
> STR:
> 1) Checkout a multimodule project, e.g. JBoss AS 7
> {code}git clone git://github.com/jbossas/jboss-as.git{code}
> 2) {code}mvn -Dmaven.repo.local=foo dependencies:go-offline clean install
> -DallTests -DskipTests{code}
> 3) {code}mvn -Dmaven.repo.local=foo -o install -DallTests -DskipTests{code}
> This will complain about not having artifact XYZ.
> 4) On the other hand, this works:
> {code}
> mv ~/.m2/repository ~/.m2/repository_
> ln -s `pwd`/localRepo ~/.m2/repository
> mvn -o install
> {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] (MNG-5181) New resolution from local repository is very confusing
[
https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=300183#comment-300183
]
Ondrej Zizka commented on MNG-5181:
---
It's good that this feature is present; but I don't like having it forcibly
enabled. At least for my use case, i.e. creating a repo for offline use which
contains artifacts from various sources (EAP repo zip, JBoss repo, central).
I'd like to have a switch for this.
Also, when someone uses {{--offline}}, then it's probable that he knows what
he's doing and has everything in the local repo; so with {{--offline}}, this
should be off by default.
And is every URL a different repo? So e.g. Nexus "public" group alias is
different from "releases" repo? Despite having the very same artifacts? Or do
some metadata tell this to Maven client?
> New resolution from local repository is very confusing
> --
>
> Key: MNG-5181
> URL: https://jira.codehaus.org/browse/MNG-5181
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3
>Reporter: Arnaud Heritier
>
> I just discover the change introduced in Maven 3.x to try to improve the
> resolution mechanism and to avoid to use a local artifact which may not be
> available in its remote repository :
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
> Even if the feature is interesting it has several problems :
> # When an artifact isn't accessible from its remote repository it isn't used
> by maven which replies a classical "dependency not found error". It is really
> annoying for a user with some Maven 2 skills which will have a look at his
> local repo, will find the artifact and won't understand why Maven doesn't use
> it. At least the error reported by Maven should be clear that even if the
> dependency is available locally, it isn't used because it's remote repository
> isn't available.
> # This behavior cannot be configured to be only a warning for example. It is
> really annoying because it doesn't take care of some context and constraints
> we may have in a development team. Let's imagine that the remote artifact is
> really removed. Cool Maven broke the build to warn us. But it brakes the
> build of all the team whereas perhaps only one of them may try to solve the
> issue (and it can be a long resolution). Thus having the ability to configure
> if this control is blocker or warning may allow the team to configure it as
> blocker on the CI server and as warning on the development environment.
> # This behavior may introduce some bad practices for example when we are
> using a staging feature on a repository manager. In our case my teams have a
> dedicated profile to activate a staging repository when we are validating a
> release. I recommend to not have this profile always activated but to do it
> only on-demand to avoid them to DL staging stuffs they don't need. With this
> new feature they need for all builds they run to activate this staging
> profile while binaries are stored in it. When you have to do it 20 times per
> day minimum let's imagine what the developer does : It adds it as an
> alwaysActive profile and then forget to remove it when the release is ended.
> For all these reason I would like we improve this feature to make it more
> usable and before all bet understandable for ours users.
--
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-5289) -Dmaven.repo.local not honored
[
https://jira.codehaus.org/browse/MNG-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299897#comment-299897
]
Ondrej Zizka commented on MNG-5289:
---
http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
> -Dmaven.repo.local not honored
> --
>
> Key: MNG-5289
> URL: https://jira.codehaus.org/browse/MNG-5289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
> Environment: Linux
>Reporter: Ondrej Zizka
>
> STR:
> 1) Checkout a multimodule project, e.g. JBoss AS 7
> {code}git clone git://github.com/jbossas/jboss-as.git{code}
> 2) {code}mvn -Dmaven.repo.local=foo dependencies:go-offline clean install
> -DallTests -DskipTests{code}
> 3) {code}mvn -Dmaven.repo.local=foo -o install -DallTests -DskipTests{code}
> This will complain about not having artifact XYZ.
> 4) On the other hand, this works:
> {code}
> mv ~/.m2/repository ~/.m2/repository_
> ln -s `pwd`/localRepo ~/.m2/repository
> mvn -o install
> {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] (MNG-5289) -Dmaven.repo.local not honored
[
https://jira.codehaus.org/browse/MNG-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299897#comment-299897
]
Ondrej Zizka edited comment on MNG-5289 at 5/28/12 9:10 PM:
Jason van Zyl:
{quote}
The artifacts have an identity. It matters where the artifacts were downloaded
from. Artifact A downloaded from X is not the same thing to Maven 3 as A
downloaded from Y. This can happen when you flip your settings.xml to go from
using a repository manager to using Maven Central directly for example.
There is currently no way to turn that off. But you can vote for the issue[1].
[1]: http://jira.codehaus.org/browse/MNG-5181
{quote}
http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
was (Author: pekarna):
http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
> -Dmaven.repo.local not honored
> --
>
> Key: MNG-5289
> URL: https://jira.codehaus.org/browse/MNG-5289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
> Environment: Linux
>Reporter: Ondrej Zizka
>
> STR:
> 1) Checkout a multimodule project, e.g. JBoss AS 7
> {code}git clone git://github.com/jbossas/jboss-as.git{code}
> 2) {code}mvn -Dmaven.repo.local=foo dependencies:go-offline clean install
> -DallTests -DskipTests{code}
> 3) {code}mvn -Dmaven.repo.local=foo -o install -DallTests -DskipTests{code}
> This will complain about not having artifact XYZ.
> 4) On the other hand, this works:
> {code}
> mv ~/.m2/repository ~/.m2/repository_
> ln -s `pwd`/localRepo ~/.m2/repository
> mvn -o install
> {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] (MNG-5289) -Dmaven.repo.local not honored
[
https://jira.codehaus.org/browse/MNG-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299897#comment-299897
]
Ondrej Zizka edited comment on MNG-5289 at 5/28/12 9:15 PM:
Jason van Zyl:
http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
{quote}
The artifacts have an identity. It matters where the artifacts were downloaded
from. Artifact A downloaded from X is not the same thing to Maven 3 as A
downloaded from Y. This can happen when you flip your settings.xml to go from
using a repository manager to using Maven Central directly for example.
There is currently no way to turn that off. But you can vote for the issue[1].
[1]: http://jira.codehaus.org/browse/MNG-5181
{quote}
OMG. Killing evil with greater evil.
was (Author: pekarna):
Jason van Zyl:
{quote}
The artifacts have an identity. It matters where the artifacts were downloaded
from. Artifact A downloaded from X is not the same thing to Maven 3 as A
downloaded from Y. This can happen when you flip your settings.xml to go from
using a repository manager to using Maven Central directly for example.
There is currently no way to turn that off. But you can vote for the issue[1].
[1]: http://jira.codehaus.org/browse/MNG-5181
{quote}
http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
> -Dmaven.repo.local not honored
> --
>
> Key: MNG-5289
> URL: https://jira.codehaus.org/browse/MNG-5289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
> Environment: Linux
>Reporter: Ondrej Zizka
>
> STR:
> 1) Checkout a multimodule project, e.g. JBoss AS 7
> {code}git clone git://github.com/jbossas/jboss-as.git{code}
> 2) {code}mvn -Dmaven.repo.local=foo dependencies:go-offline clean install
> -DallTests -DskipTests{code}
> 3) {code}mvn -Dmaven.repo.local=foo -o install -DallTests -DskipTests{code}
> This will complain about not having artifact XYZ.
> 4) On the other hand, this works:
> {code}
> mv ~/.m2/repository ~/.m2/repository_
> ln -s `pwd`/localRepo ~/.m2/repository
> mvn -o install
> {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] (MNG-5289) -Dmaven.repo.local not honored
[
https://jira.codehaus.org/browse/MNG-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299898#comment-299898
]
Ondrej Zizka commented on MNG-5289:
---
What I don't understand is why this comes into action when I use {{mvn
--offline}} ?? In that case, this behavior is meaningless as I appearantly
intend to take everything from local repo.
Also, it seems that {{--offline}} disables FS repos - {{file:///...}}. It
shoudn't.
> -Dmaven.repo.local not honored
> --
>
> Key: MNG-5289
> URL: https://jira.codehaus.org/browse/MNG-5289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
> Environment: Linux
>Reporter: Ondrej Zizka
>
> STR:
> 1) Checkout a multimodule project, e.g. JBoss AS 7
> {code}git clone git://github.com/jbossas/jboss-as.git{code}
> 2) {code}mvn -Dmaven.repo.local=foo dependencies:go-offline clean install
> -DallTests -DskipTests{code}
> 3) {code}mvn -Dmaven.repo.local=foo -o install -DallTests -DskipTests{code}
> This will complain about not having artifact XYZ.
> 4) On the other hand, this works:
> {code}
> mv ~/.m2/repository ~/.m2/repository_
> ln -s `pwd`/localRepo ~/.m2/repository
> mvn -o install
> {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-783) release:update-versions should not need SCM config
Ondrej Zizka created MRELEASE-783:
-
Summary: release:update-versions should not need SCM config
Key: MRELEASE-783
URL: https://jira.codehaus.org/browse/MRELEASE-783
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Reporter: Ondrej Zizka
Currently, on a project without configured, {{mvn
release:update-versions}} ends up with:
{code}
Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.0:update-versions (default-cli)
on project wicketstuff-dojo: Missing required setting: scm connection or
developerConnection must be specified.
{code}
Updating versions recursively definitely does not need SCM.
Could this restriction be removed? Thanks.
--
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-783) release:update-versions should not need SCM config
[
https://jira.codehaus.org/browse/MRELEASE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304259#comment-304259
]
Ondrej Zizka commented on MRELEASE-783:
---
Maven 3.0.4
> release:update-versions should not need SCM config
> --
>
> Key: MRELEASE-783
> URL: https://jira.codehaus.org/browse/MRELEASE-783
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, on a project without configured, {{mvn
> release:update-versions}} ends up with:
> {code}
> Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.0:update-versions
> (default-cli) on project wicketstuff-dojo: Missing required setting: scm
> connection or developerConnection must be specified.
> {code}
> Updating versions recursively definitely does not need SCM.
> Could this restriction be removed? Thanks.
--
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-783) release:update-versions should not need SCM config
[
https://jira.codehaus.org/browse/MRELEASE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304261#comment-304261
]
Ondrej Zizka commented on MRELEASE-783:
---
Probably, thanks for the tip; but still :)
> release:update-versions should not need SCM config
> --
>
> Key: MRELEASE-783
> URL: https://jira.codehaus.org/browse/MRELEASE-783
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, on a project without configured, {{mvn
> release:update-versions}} ends up with:
> {code}
> Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.0:update-versions
> (default-cli) on project wicketstuff-dojo: Missing required setting: scm
> connection or developerConnection must be specified.
> {code}
> Updating versions recursively definitely does not need SCM.
> Could this restriction be removed? Thanks.
--
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-5319) Better formatting of "missing dependencies" error message - add newlines
Ondrej Zizka created MNG-5319:
-
Summary: Better formatting of "missing dependencies" error message
- add newlines
Key: MNG-5319
URL: https://jira.codehaus.org/browse/MNG-5319
Project: Maven 2 & 3
Issue Type: Improvement
Components: Dependencies, Errors, Logging
Affects Versions: 3.0.4
Reporter: Ondrej Zizka
Priority: Critical
When a build fails with missing dependencies, the error message given is a
plain single line concatenated to unreadable blob.
{code}
[ERROR] Failed to execute goal on project jboss-as-testsuite: Could not resolve
dependencies for project
org.jboss.as:jboss-as-testsuite:pom:7.1.3.Final-redhat-1: The following
artifacts could not be resolved:
org.picketlink:picketlink-core:jar:2.1.1.Final,
org.picketlink.distribution:picketlink-jbas7:jar:2.1.1.Final,
org.picketbox:picketbox:jar:4.0.9.Final,
org.picketbox:picketbox-commons:jar:1.0.0.final,
org.picketbox:picketbox-infinispan:jar:4.0.9.Final: The repository system is
offline but the artifact org.picketlink:picketlink-core:jar:2.1.1.Final is not
available in the local repository. -> [Help 1]
{code}
It would be very useful if this was nicely formated in format such as:
{code}
[ERROR] Failed to execute goal on project jboss-as-testsuite:
Could not resolve dependencies for project
org.jboss.as:jboss-as-testsuite:pom:7.1.3.Final-redhat-1:
The following artifacts could not be resolved:
org.picketlink:picketlink-core:jar:2.1.1.Final
org.picketlink.distribution:picketlink-jbas7:jar:2.1.1.Final
org.picketbox:picketbox:jar:4.0.9.Final
org.picketbox:picketbox-commons:jar:1.0.0.final
org.picketbox:picketbox-infinispan:jar:4.0.9.Final
The repository system is offline but the artifact
org.picketlink:picketlink-core:jar:2.1.1.Final is not available in the local
repository. -> [Help 1]
{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-856) Running single test in Failsafe using CLI does not override configuration
[
https://jira.codehaus.org/browse/SUREFIRE-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305636#comment-305636
]
Ondrej Zizka commented on SUREFIRE-856:
---
Actually, this behavior is the correct default one, and Surefire should be
fixed to behave like this.
Whether to ignore / or not should be optional.
> Running single test in Failsafe using CLI does not override
> configuration
>
>
> Key: SUREFIRE-856
> URL: https://jira.codehaus.org/browse/SUREFIRE-856
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.12
> Environment: Mac OS X 10.7, Maven 3.0.3, JDK 1.7.0_04-ea
>Reporter: David Drake
>Priority: Minor
>
> h4. Description
> If a single test is specified from using CLI parameters, but the test does
> not match the pattern for failsafe, then the test will not run.
> This is different from the behavior for the surefire plugin, which will run
> any test specified using CLI parameters. If the test does match the
> pattern for failsafe, then it will run.
> h4. Reproduction steps
> # Create a project with a single test named "Sample.java".
> # Add the following block to the failsafe configuration:
> {code:xml}
>
> **/Sample.java
>
> {code}
> # Run "mvn clean verify -Dit.test=Sample" from the command line (and verify
> that test runs).
> # Remove the block shown above from the pom.
> # Run "mvn clean verify -Dit.test=Sample" from the command line.
> h4. Expected results
> Sample test is run, as before, and no other tests are run.
> h4. Actual results
> No tests are run.
--
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-856) Running single test in Failsafe using CLI does not override configuration
[
https://jira.codehaus.org/browse/SUREFIRE-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305637#comment-305637
]
Ondrej Zizka commented on SUREFIRE-856:
---
And why it's correct?
Imagine multiple executions of Surefire with different setups (for complex
testsuites).
Without includes, you'd end up with the single tests running once for each
execution.
With includes, the test will only run in the proper execution.
The use case when you want to run test which is not included should be covered
by aforementioned option to ignore/follow .
> Running single test in Failsafe using CLI does not override
> configuration
>
>
> Key: SUREFIRE-856
> URL: https://jira.codehaus.org/browse/SUREFIRE-856
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.12
> Environment: Mac OS X 10.7, Maven 3.0.3, JDK 1.7.0_04-ea
>Reporter: David Drake
>Priority: Minor
>
> h4. Description
> If a single test is specified from using CLI parameters, but the test does
> not match the pattern for failsafe, then the test will not run.
> This is different from the behavior for the surefire plugin, which will run
> any test specified using CLI parameters. If the test does match the
> pattern for failsafe, then it will run.
> h4. Reproduction steps
> # Create a project with a single test named "Sample.java".
> # Add the following block to the failsafe configuration:
> {code:xml}
>
> **/Sample.java
>
> {code}
> # Run "mvn clean verify -Dit.test=Sample" from the command line (and verify
> that test runs).
> # Remove the block shown above from the pom.
> # Run "mvn clean verify -Dit.test=Sample" from the command line.
> h4. Expected results
> Sample test is run, as before, and no other tests are run.
> h4. Actual results
> No tests are run.
--
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] (MRESOURCES-170) More readable format of list of "[DEBUG] properties used { ..."
Ondrej Zizka created MRESOURCES-170:
---
Summary: More readable format of list of "[DEBUG] properties used
{ ..."
Key: MRESOURCES-170
URL: https://jira.codehaus.org/browse/MRESOURCES-170
Project: Maven 2.x Resources Plugin
Issue Type: Improvement
Components: filtering
Affects Versions: 2.6
Reporter: Ondrej Zizka
Currently, the properties are dumped in a single line.
That leads to unreadable blobs like the one below.
It would be nice if the properties were printed one per line.
{code}
[DEBUG] properties used {version.scm.plugin=1.5-redhat-1,
env.BUILD_URL=http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBoss-EAP-6.0.x-MEAD/671/,
public-repos=true, env.SSH_CLIENT=10.16.90.43 43044 22,
version.org.jboss.shrinkwrap.resolver=1.0.0-beta-5,
version.gpg.plugin=1.4-redhat-1, version.antrun.plugin=1.6-redhat-1,
version.org.apache.commons.ssl.not-yet-commons-ssl=0.3.11-redhat-2,
env.SOURCE_REPO=/qa/tools/src,
env.HUDSON_CONFIG_DIR=/home/hudson/config_repository,
version.org.jboss.ws.cxf=4.0.6.GA-redhat-1, version.args4j=2.0.12-redhat-2,
version.com.github.relaxng=2011.1-redhat-3, version.ear.plugin=2.4.2-redhat-1,
version.commons-httpclient=3.1-redhat-2,
user.dir=/mnt/hudson_workspace/workspace/JBoss-EAP-6.0.x-MEAD,
version.slide=2.1, version.tomcat7=7.0.27, version.tomcat6=6.0.35,
java.vm.version=20.5-b03, version.org.jboss.invocation=1.1.1.Final-redhat-2,
version.org.apache.maven.wagon.http-lightweight=1.0,
env.HUDSON_STATIC_ENV=/home/hudson/static_build_env,
version.org.apache.aries=0.3-redhat-2, version.cxf.plugin=2.3.2-redhat-1,
env.HISTFILESIZE=1,
env.HUDSON_SERVER_COOKIE=4d54d696d35619860de79dcf00b434f1,
version.install.plugin=2.3.1-redhat-1, env.HISTSIZE=1000,
version.net.sourceforge.jchardet=1.0-redhat-2, version.emma=2.0.5312,
version.shade.plugin=1.5-redhat-1, version.jaxen=1.1.3-redhat-2,
version.org.codehaus.jackson=1.9.2-redhat-2,
version.site.plugin=3.0-beta-3-redhat-1, version.clirr.plugin=2.2.2-redhat-1,
version.xdoc.plugin=1.9.2-redhat-1,
env.JENKINS_HOME=/qa/hudson_master/hudson_home/hudson_workspace,
version.org.jboss.stdio=1.0.1.GA-redhat-2,
version.retrotranslator.plugin=1.0-alpha-4-redhat-1,
version.org.jboss.weld.weld=1.1.10.Final-redhat-1, sun.os.patch.level=unknown,
env.HUDSON_HOME=/qa/hudson_master/hudson_home/hudson_workspace,
version.protobuf-java=2.3.0,
version.org.jboss.osgi.resolver=2.1.0.Final-redhat-3,
version.javax.mail=1.4.4-redhat-2, version.injection.plugin=1.0.2-redhat-1,
java.vm.specification.name=Java Virtual Machine Specification,
jdk.min.version=1.6, version.org.infinispan=5.1.7.Final-redhat-1,
version.rar.plugin=2.2-redhat-1, version.xml-apis=1.3.04,
version.google-license.plugin=1.4.0-redhat-1,
version.org.apache.neethi=3.0.2-redhat-2, os.name=Linux,
version.org.jboss.jboss-transaction-spi=7.0.0.Final-redhat-2,
version.org.yaml.snakeyaml=1.8-redhat-2,
version.org.jboss.security.jbossxacml=2.0.8.Final-redhat-2,
version.org.jboss.marshalling.jboss-marshalling=1.3.15.GA-redhat-1,
version.com.gwtplatform=0.6-redhat-2,
version.com.google.code.findbugs=1.3.9-redhat-2,
version.org.jboss.osgi.xerces=2.9.1.SP7-redhat-1,
version.wsdl4j=1.6.2-redhat-2, version.jboss-packaging.plugin=2.1-redhat-1,
version.qdox=1.6.1,
java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi,
version.org.apache.santuario=1.5.2-redhat-1,
version.com.google.guava=11.0.2-redhat-2,
jboss.releases.repo.url=https://repository.jboss.org/nexus/service/local/staging/deploy/maven2/,
version.org.jboss.spec.javax.xml.rpc.jboss-jaxrpc-api_1.1_spec=1.0.1.Final-redhat-2,
arguments=-Pjboss-release, os.arch=amd64, user.name=hudson,
version.org.jboss.modules.jboss-modules=1.1.3.GA-redhat-1,
version.org.jboss.jbossts.jbossxts=4.16.6.Final-redhat-1,
version.org.jboss.spec.javax.interceptor.jboss-interceptors-api_1.1_spec=1.0.1.Final-redhat-2,
version.org.codehaus.jra=1.0-alpha-4-redhat-2,
sun.java.command=org.codehaus.plexus.classworlds.launcher.Launcher -f
jboss-as/pom.xml -DJBOSS_AS_VERSION=7.1.3.Final-redhat-3
-DJBOSS_EAP_VERSION=6.0.1.ER3 -Dsurefire.test.failure.ignore=true
-Dmaven.test.failure.ignore=true
-DaltDeploymentRepository=local::default::file:///mnt/hudson_workspace/workspace/JBoss-EAP-6.0.x-MEAD/jboss-eap-6.0.1.ER3-jenkins-build-output-repo
-Dsurefire.forked.process.timeout=2600 -DallTests=true
-Dmaven.repo.local=/mnt/hudson_workspace/workspace/JBoss-EAP-6.0.x-MEAD/.repository
-X clean install -B -s
/mnt/hudson_workspace/workspace/JBoss-EAP-6.0.x-MEAD/jboss-as/tools/maven/conf/settings.xml
-Dpublic-repos -Prelease, env.USER=hudson,
version.org.apache.james.james-project=1.2-redhat-1,
version.resources.plugin=2.5-redhat-1, env.SSH_CONNECTION=10.16.90.43 43044
10.16.88.209 22,
version.org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.4_spec=1.0.2.Final-redhat-2,
env.MAVEN_OPTS=-Xmx1024m -X
[jira] (MNG-5347) Support expressions for plugin parameters
[
https://jira.codehaus.org/browse/MNG-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313328#comment-313328
]
Ondrej Zizka commented on MNG-5347:
---
This is rather a question of supporting expression language in pom.xml's a
whole.
Probably, the expresion would need to be whole surrounded by delimiters, e.g.
${foo or bar}.
You might also want to check related Karel Piwko's EL profile activator:
https://github.com/kpiwko/el-profile-activator-extension .
> Support expressions for plugin parameters
> -
>
> Key: MNG-5347
> URL: https://jira.codehaus.org/browse/MNG-5347
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: General
>Affects Versions: 3.0.4
> Environment: mistria@mistria--rh:~$ mvn -version
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: /home/mistria/apps/apache-maven-3.0.4
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.2.0-30-generic", arch: "amd64", family: "unix"
>Reporter: Mickael Istria
>
> Use-case:
> I want to give as input of my surefire-plugin
> {code}
>
> ${skipTests} || ${skipDownloadRuntimes}
>
> {code}
> This won't work because the expressions are not evaluated. Boolean arguments
> in plugin are set to something like Boolean.parseBoolean, which is quite
> limited.
> Instead, we could think of introducing an expression language, such as
> Groovy, that would allow expressions as parameters for plugins.
> Then let's say skipTests=false and skipDownloadRuntimes=true, Maven would
> first replace "${skipTests} || ${skipDownloadRuntimes}" by "false || true"
> and then this evaluator would evaluate that to "false", and skip will receive
> the value "false".
> This would for sure make maven less verbose in some cases.
--
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-4565) Multiple profile activation conditions does not work
[ https://jira.codehaus.org/browse/MNG-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313329#comment-313329 ] Ondrej Zizka commented on MNG-4565: --- Seems that Karel's extension solves MNG-5194. > Multiple profile activation conditions does not work > > > Key: MNG-4565 > URL: https://jira.codehaus.org/browse/MNG-4565 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.2.1 > Environment: All platforms. >Reporter: Nicholas Allen >Assignee: Brian Fox > Fix For: Issues to be reviewed for 3.x > > > According to the documentation at > http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-activation.html > a profile is activated when all activation conditions are met (which makes > sense of course). But when I try to use this it does not work. It seems maven > does an OR instead of an AND (which is not rearly as useful and is the > opposite of what the documentation says at the previous link). > For example, if I have one profile that is activated like this: > > false > >linux > > > and another profile that is activated like this: > > false > >linux > > > release > true > > > Then I would expect the second profile to only be activated if the OS is > linux and the release property is defined. > When I run 'mvn help:active-profiles' however, maven shows that both profiles > are active even though the release property is not defined. -- 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-5194) Profile activation: Allow expressions in
[ https://jira.codehaus.org/browse/MNG-5194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313330#comment-313330 ] Ondrej Zizka commented on MNG-5194: --- This seems to be targetted by https://github.com/kpiwko/el-profile-activator-extension . > Profile activation: Allow expressions in > - > > Key: MNG-5194 > URL: https://jira.codehaus.org/browse/MNG-5194 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Profiles >Affects Versions: 3.0.3 >Reporter: Ondrej Zizka > > Current profile activation capabilities are insufficient. > Makes using large projects harder, especially with complex testsuites. > Having a possibility to have profiles activated by an expression would help a > lot. > > property1 == "true" || (property2 && property3) > -- 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-5181) New resolution from local repository is very confusing
[
https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313500#comment-313500
]
Ondrej Zizka commented on MNG-5181:
---
How about instead of having G:A:V:R, the identity of the artifact would be
verified using a hash. Simply, G:A:V:H. Same G:A:V and hash => same artifact,
dependency satisfied, no matter what repo does it come from.
{code}
foo
bar
1.0
0c9ab296701a8
{code}
I guess this approach was considered, but I wonder why not chosen.
> New resolution from local repository is very confusing
> --
>
> Key: MNG-5181
> URL: https://jira.codehaus.org/browse/MNG-5181
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3
>Reporter: Arnaud Heritier
>Assignee: Jason van Zyl
>
> I just discover the change introduced in Maven 3.x to try to improve the
> resolution mechanism and to avoid to use a local artifact which may not be
> available in its remote repository :
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
> Even if the feature is interesting it has several problems :
> # When an artifact isn't accessible from its remote repository it isn't used
> by maven which replies a classical "dependency not found error". It is really
> annoying for a user with some Maven 2 skills which will have a look at his
> local repo, will find the artifact and won't understand why Maven doesn't use
> it. At least the error reported by Maven should be clear that even if the
> dependency is available locally, it isn't used because it's remote repository
> isn't available.
> # This behavior cannot be configured to be only a warning for example. It is
> really annoying because it doesn't take care of some context and constraints
> we may have in a development team. Let's imagine that the remote artifact is
> really removed. Cool Maven broke the build to warn us. But it brakes the
> build of all the team whereas perhaps only one of them may try to solve the
> issue (and it can be a long resolution). Thus having the ability to configure
> if this control is blocker or warning may allow the team to configure it as
> blocker on the CI server and as warning on the development environment.
> # This behavior may introduce some bad practices for example when we are
> using a staging feature on a repository manager. In our case my teams have a
> dedicated profile to activate a staging repository when we are validating a
> release. I recommend to not have this profile always activated but to do it
> only on-demand to avoid them to DL staging stuffs they don't need. With this
> new feature they need for all builds they run to activate this staging
> profile while binaries are stored in it. When you have to do it 20 times per
> day minimum let's imagine what the developer does : It adds it as an
> alwaysActive profile and then forget to remove it when the release is ended.
> For all these reason I would like we improve this feature to make it more
> usable and before all bet understandable for ours users.
--
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] Created: (MNG-4599) Provide a way to create "virtual artifacts" out of plain .jar file.
Provide a way to create "virtual artifacts" out of plain .jar file. --- Key: MNG-4599 URL: http://jira.codehaus.org/browse/MNG-4599 Project: Maven 2 & 3 Issue Type: Improvement Reporter: Ondrej Zizka During the time I have been using Maven, I have come across numerous cases when I desperately needed to turn a simple .jar file into a dependency. Currently, this involves installing it properly to the repository first, and only then it can be used. I suggest to introduce some construct which would take a list of .jar files and turn them into dependencies in the sense they would be added to the classpaths, could be used for WAR overlays, etc. Of course, they would not have any transitional dependencies. ../../releases/50GAAS/jboss-as/common/lib ... This would greately improve Maven's openness to non-mavenized world, and usability in cases when you really get a plain .jar/.war/.ear/... before every build cycle. -- 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-4599) Provide a way to create "virtual artifacts" out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=214531#action_214531 ] Ondrej Zizka commented on MNG-4599: --- I know this is a common feature request, which Maven devs ignore. I understand that this is Sonatype's business decision, aimed to force people to Mavenize everything and to strenghten the need for a good local repository. But from the usability POV, it's a bad decision. The suggested solution is not appropriate, because what bothers me (and 80 % of Maven users) is the need to create the artifact and to list each of them in POM. * This requires another pre-build step every time I perform the build - creating a maven artifact out of the .jar created by some other tool. * Since the dependency must be ready BEFORE calling Maven, this can't be done in POM. * If I have 200 .jars, I need to create 200 artifacts for each build WHICH WILL NEVER BE USED AGAIN. More than that, I have to list 200 dependencies in POM. This is ridiculous, totally useless, and the only reason is this bad "deliberate design decision". It's time to change the design desicion. There's no technical drawback. It will be backward compatible, so it won't harm anything. And I don't believe people would start misusing it as it's not easier than mavenizing some persistent artifact. It would only serve for cases when you need to use too many .jars which are not in the repository (for whatever reason). I am filing this feature request just to assure that the need of most Maven users is really disregarded and disdained, before we start to patch Maven four ourselves. > Provide a way to create "virtual artifacts" out of plain .jar file. > --- > > Key: MNG-4599 > URL: http://jira.codehaus.org/browse/MNG-4599 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Ondrej Zizka >Assignee: Brett Porter > > During the time I have been using Maven, I have come across numerous cases > when I desperately needed to turn a simple .jar file into a dependency. > Currently, this involves installing it properly to the repository first, and > only then it can be used. > I suggest to introduce some construct which would take a list of .jar files > and turn them into dependencies in the sense they would be added to the > classpaths, could be used for WAR overlays, etc. Of course, they would not > have any transitional dependencies. > > > ../../releases/50GAAS/jboss-as/common/lib > >... > > This would greately improve Maven's openness to non-mavenized world, and > usability in cases when you really get a plain .jar/.war/.ear/... before > every build cycle. -- 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-3328) Allow multiple profile activation properties.
[
http://jira.codehaus.org/browse/MNG-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=214846#action_214846
]
Ondrej Zizka commented on MNG-3328:
---
+1 to Elifarley Callado Coelho for boolean logic,
-1 to Marco Sandrini for too verbose syntax.
> Allow multiple profile activation properties.
> -
>
> Key: MNG-3328
> URL: http://jira.codehaus.org/browse/MNG-3328
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 2.0.8
>Reporter: Paul Gier
> Fix For: Backlog
>
>
> The pom model should be changed to allow multiple properties to activate a
> profile. So the profile activation section could look something like this:
> {code:xml}
>
>
> some-value
> another-value
>
>
> {code}
> This would provide more flexibility in profile activation.
--
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-4599) Provide a way to create "virtual artifacts" out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=214851#action_214851 ] Ondrej Zizka commented on MNG-4599: --- Jason, thanks for the comment. Sorry for the tone of my previous one. It seems that you still don't see my point. Let me put it short: Maven is good as a build tool, but quite bad for integration testing. Perhaps it's not intended for it, but it's natural for the QEs to try it with Maven, because developers want to reproduce bugs and they don't want to use other tool than for building. Reproducing is done on released products, because whatever you may think, Maven is not (yet) so universal to be able to build a whole product from the sources - there are even things that can't be done that way, like signing the jars etc. because of process matters. So then, QA dept gets the product as a ZIP or whatever archive/package, which contains many many .jars from various sources, not only Maven. These jars differ for each release, including internal and candidate. Stuffing them to Maven repo is a non-sense - they are used only once, they are used by tools which will hardly be ever Mavenized, sometimes they need to stay in the same directory because of security constraints, etc. Please, please at least admit that these are valid needs, so I really have confirmed the "Maven decision" facing to these needs. As you suggest, I will try the user space, just - what exactly do you mean by that? Could recommend some mailing list or forum please? Resolved issues can't be voted. If this was changed, perhaps RFEs like this would not get lost. > Provide a way to create "virtual artifacts" out of plain .jar file. > --- > > Key: MNG-4599 > URL: http://jira.codehaus.org/browse/MNG-4599 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Ondrej Zizka >Assignee: Brett Porter > > During the time I have been using Maven, I have come across numerous cases > when I desperately needed to turn a simple .jar file into a dependency. > Currently, this involves installing it properly to the repository first, and > only then it can be used. > I suggest to introduce some construct which would take a list of .jar files > and turn them into dependencies in the sense they would be added to the > classpaths, could be used for WAR overlays, etc. Of course, they would not > have any transitional dependencies. > > > ../../releases/50GAAS/jboss-as/common/lib > >... > > This would greately improve Maven's openness to non-mavenized world, and > usability in cases when you really get a plain .jar/.war/.ear/... before > every build cycle. -- 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-4599) Provide a way to create "virtual artifacts" out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215058#action_215058 ] Ondrej Zizka commented on MNG-4599: --- **Paul**, the problem is that I need to do it at all, because it's pointless and the ONLY REASON to do it is just to make Maven happy. These artifact would never be used again. See above. **Brett**, I am 100 % that it would be misused. But is that a reason not to give the users possibility? I can think of countless Maven features which can be "misused" - e.g. * using various archiving plugin to actually build WAR/EAR/..., * using the Ant Plugin to do everything, setting test and source path to the same directory to get the classes of the test to the result (another Maven flaw complicating usage of JSFUnit), * completely re-mapping the build phases to accomodate all steps that the build process needs, etc etc., I could continue but that's not what this issue is about. My collegue already wrote a plugin which puts the .jar's on the classpath, but it's a ad-hoc solution and does not work e.g. with WAR overlays. Brett, Jason, before I move this discussion to the mailing list, * could you please point me where should I look to add this feature? * Is it possible to write it as a plugin, or does it need some changes Maven core? * Would it be similar to the jarPath (should I look at it first)? Thanks. > Provide a way to create "virtual artifacts" out of plain .jar file. > --- > > Key: MNG-4599 > URL: http://jira.codehaus.org/browse/MNG-4599 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Ondrej Zizka >Assignee: Brett Porter > > During the time I have been using Maven, I have come across numerous cases > when I desperately needed to turn a simple .jar file into a dependency. > Currently, this involves installing it properly to the repository first, and > only then it can be used. > I suggest to introduce some construct which would take a list of .jar files > and turn them into dependencies in the sense they would be added to the > classpaths, could be used for WAR overlays, etc. Of course, they would not > have any transitional dependencies. > > > ../../releases/50GAAS/jboss-as/common/lib > >... > > This would greately improve Maven's openness to non-mavenized world, and > usability in cases when you really get a plain .jar/.war/.ear/... before > every build cycle. -- 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: (MNG-4599) Provide a way to create "virtual artifacts" out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215058#action_215058 ] Ondrej Zizka edited comment on MNG-4599 at 3/23/10 7:31 PM: *Paul*, the problem is that I don't want to do it at all, because it's pointless and the ONLY REASON to do it is just to make Maven happy. These artifact would never be used again. See above. *Brett*, I am 100 % sure that it would be misused. But is that a reason not to give the users possibility? I can think of countless Maven features which can be "misused" - e.g. * using various archiving plugin to actually build WAR/EAR/..., * using the Ant Plugin to do everything, setting test and source path to the same directory to get the classes of the test to the result (another Maven flaw complicating usage of JSFUnit), * completely re-mapping the build phases to accomodate all steps that the build process needs, etc etc., I could continue but that's not what this issue is about. My collegue already wrote a plugin which puts the .jar's on the classpath, but it's a ad-hoc solution and does not work e.g. with WAR overlays. Brett, Jason, before I move this discussion to the mailing list, * could you please point me where should I look to add this feature? * Is it possible to write it as a plugin, or does it need some changes Maven core? * Would it be similar to the jarPath (should I look at it first)? Thanks. was (Author: pekarna): *Paul*, the problem is that I need to do it at all, because it's pointless and the ONLY REASON to do it is just to make Maven happy. These artifact would never be used again. See above. *Brett*, I am 100 % sure that it would be misused. But is that a reason not to give the users possibility? I can think of countless Maven features which can be "misused" - e.g. * using various archiving plugin to actually build WAR/EAR/..., * using the Ant Plugin to do everything, setting test and source path to the same directory to get the classes of the test to the result (another Maven flaw complicating usage of JSFUnit), * completely re-mapping the build phases to accomodate all steps that the build process needs, etc etc., I could continue but that's not what this issue is about. My collegue already wrote a plugin which puts the .jar's on the classpath, but it's a ad-hoc solution and does not work e.g. with WAR overlays. Brett, Jason, before I move this discussion to the mailing list, * could you please point me where should I look to add this feature? * Is it possible to write it as a plugin, or does it need some changes Maven core? * Would it be similar to the jarPath (should I look at it first)? Thanks. > Provide a way to create "virtual artifacts" out of plain .jar file. > --- > > Key: MNG-4599 > URL: http://jira.codehaus.org/browse/MNG-4599 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Ondrej Zizka >Assignee: Brett Porter > > During the time I have been using Maven, I have come across numerous cases > when I desperately needed to turn a simple .jar file into a dependency. > Currently, this involves installing it properly to the repository first, and > only then it can be used. > I suggest to introduce some construct which would take a list of .jar files > and turn them into dependencies in the sense they would be added to the > classpaths, could be used for WAR overlays, etc. Of course, they would not > have any transitional dependencies. > > > ../../releases/50GAAS/jboss-as/common/lib > >... > > This would greately improve Maven's openness to non-mavenized world, and > usability in cases when you really get a plain .jar/.war/.ear/... before > every build cycle. -- 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: (MNG-4599) Provide a way to create "virtual artifacts" out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215058#action_215058 ] Ondrej Zizka edited comment on MNG-4599 at 3/23/10 7:31 PM: *Paul*, the problem is that I need to do it at all, because it's pointless and the ONLY REASON to do it is just to make Maven happy. These artifact would never be used again. See above. *Brett*, I am 100 % sure that it would be misused. But is that a reason not to give the users possibility? I can think of countless Maven features which can be "misused" - e.g. * using various archiving plugin to actually build WAR/EAR/..., * using the Ant Plugin to do everything, setting test and source path to the same directory to get the classes of the test to the result (another Maven flaw complicating usage of JSFUnit), * completely re-mapping the build phases to accomodate all steps that the build process needs, etc etc., I could continue but that's not what this issue is about. My collegue already wrote a plugin which puts the .jar's on the classpath, but it's a ad-hoc solution and does not work e.g. with WAR overlays. Brett, Jason, before I move this discussion to the mailing list, * could you please point me where should I look to add this feature? * Is it possible to write it as a plugin, or does it need some changes Maven core? * Would it be similar to the jarPath (should I look at it first)? Thanks. was (Author: pekarna): **Paul**, the problem is that I need to do it at all, because it's pointless and the ONLY REASON to do it is just to make Maven happy. These artifact would never be used again. See above. **Brett**, I am 100 % that it would be misused. But is that a reason not to give the users possibility? I can think of countless Maven features which can be "misused" - e.g. * using various archiving plugin to actually build WAR/EAR/..., * using the Ant Plugin to do everything, setting test and source path to the same directory to get the classes of the test to the result (another Maven flaw complicating usage of JSFUnit), * completely re-mapping the build phases to accomodate all steps that the build process needs, etc etc., I could continue but that's not what this issue is about. My collegue already wrote a plugin which puts the .jar's on the classpath, but it's a ad-hoc solution and does not work e.g. with WAR overlays. Brett, Jason, before I move this discussion to the mailing list, * could you please point me where should I look to add this feature? * Is it possible to write it as a plugin, or does it need some changes Maven core? * Would it be similar to the jarPath (should I look at it first)? Thanks. > Provide a way to create "virtual artifacts" out of plain .jar file. > --- > > Key: MNG-4599 > URL: http://jira.codehaus.org/browse/MNG-4599 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Ondrej Zizka >Assignee: Brett Porter > > During the time I have been using Maven, I have come across numerous cases > when I desperately needed to turn a simple .jar file into a dependency. > Currently, this involves installing it properly to the repository first, and > only then it can be used. > I suggest to introduce some construct which would take a list of .jar files > and turn them into dependencies in the sense they would be added to the > classpaths, could be used for WAR overlays, etc. Of course, they would not > have any transitional dependencies. > > > ../../releases/50GAAS/jboss-as/common/lib > >... > > This would greately improve Maven's openness to non-mavenized world, and > usability in cases when you really get a plain .jar/.war/.ear/... before > every build cycle. -- 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: (MNG-4599) Provide a way to create "virtual artifacts" out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215058#action_215058 ] Ondrej Zizka edited comment on MNG-4599 at 3/23/10 7:47 PM: *Paul*, the problem is that I don't want to do it at all, because it's pointless and the ONLY REASON to do it is just to make Maven happy. These artifact would never be used again. See above. *Brett*, I am 100 % sure that it would be misused. But is that a reason not to give the users possibility? I can think of countless Maven features which can be "misused" - e.g. * using various archiving plugin to actually build WAR/EAR/..., * using the Ant Plugin to do everything, setting test and source path to the same directory to get the classes of the test to the result (another Maven flaw complicating usage of JSFUnit), * completely re-mapping the build phases to accomodate all steps that the build process needs, etc etc., I could continue but that's not what this issue is about. My collegue already wrote a plugin which puts the .jar's on the classpath, but it's a ad-hoc solution and does not work e.g. with WAR overlays. Brett, Jason, before I move this discussion to the mailing list, * could you please point me where should I look to add this feature? * Is it possible to write it as a plugin, or does it need some changes to the Maven core? * Would it be similar to the jarPath (should I look at it first)? Thanks. was (Author: pekarna): *Paul*, the problem is that I don't want to do it at all, because it's pointless and the ONLY REASON to do it is just to make Maven happy. These artifact would never be used again. See above. *Brett*, I am 100 % sure that it would be misused. But is that a reason not to give the users possibility? I can think of countless Maven features which can be "misused" - e.g. * using various archiving plugin to actually build WAR/EAR/..., * using the Ant Plugin to do everything, setting test and source path to the same directory to get the classes of the test to the result (another Maven flaw complicating usage of JSFUnit), * completely re-mapping the build phases to accomodate all steps that the build process needs, etc etc., I could continue but that's not what this issue is about. My collegue already wrote a plugin which puts the .jar's on the classpath, but it's a ad-hoc solution and does not work e.g. with WAR overlays. Brett, Jason, before I move this discussion to the mailing list, * could you please point me where should I look to add this feature? * Is it possible to write it as a plugin, or does it need some changes Maven core? * Would it be similar to the jarPath (should I look at it first)? Thanks. > Provide a way to create "virtual artifacts" out of plain .jar file. > --- > > Key: MNG-4599 > URL: http://jira.codehaus.org/browse/MNG-4599 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Ondrej Zizka >Assignee: Brett Porter > > During the time I have been using Maven, I have come across numerous cases > when I desperately needed to turn a simple .jar file into a dependency. > Currently, this involves installing it properly to the repository first, and > only then it can be used. > I suggest to introduce some construct which would take a list of .jar files > and turn them into dependencies in the sense they would be added to the > classpaths, could be used for WAR overlays, etc. Of course, they would not > have any transitional dependencies. > > > ../../releases/50GAAS/jboss-as/common/lib > >... > > This would greately improve Maven's openness to non-mavenized world, and > usability in cases when you really get a plain .jar/.war/.ear/... before > every build cycle. -- 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: (MNG-4599) Provide a way to create "virtual artifacts" out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215058#action_215058 ] Ondrej Zizka edited comment on MNG-4599 at 3/23/10 8:19 PM: *Paul*, the problem is that I don't want to do it at all, because it's pointless and the ONLY REASON to do it is just to make Maven happy. These artifact would never be used again. See above. *Brett*, I am 100 % sure that it would be misused. But is that a reason not to give the users possibility? I can think of countless Maven features which can be "misused" - e.g. * using various archiving plugin to actually build WAR/EAR/..., * using the Ant Plugin to do everything, setting test and source path to the same directory to get the classes of the test to the result (another Maven flaw complicating usage of JSFUnit), * completely re-mapping the build phases to accomodate all steps that the build process needs, etc etc. (I could continue but that's not what this issue is about) - are these going to be removed for being misused? My collegue already wrote a plugin which puts the .jar's on the classpath, but it's a ad-hoc solution and does not work e.g. with WAR overlays. Brett, Jason, before I move this discussion to the mailing list, * could you please point me where should I look to add this feature? * Is it possible to write it as a plugin, or does it need some changes to the Maven core? * Would it be similar to the jarPath (should I look at it first)? Thanks. was (Author: pekarna): *Paul*, the problem is that I don't want to do it at all, because it's pointless and the ONLY REASON to do it is just to make Maven happy. These artifact would never be used again. See above. *Brett*, I am 100 % sure that it would be misused. But is that a reason not to give the users possibility? I can think of countless Maven features which can be "misused" - e.g. * using various archiving plugin to actually build WAR/EAR/..., * using the Ant Plugin to do everything, setting test and source path to the same directory to get the classes of the test to the result (another Maven flaw complicating usage of JSFUnit), * completely re-mapping the build phases to accomodate all steps that the build process needs, etc etc., I could continue but that's not what this issue is about. My collegue already wrote a plugin which puts the .jar's on the classpath, but it's a ad-hoc solution and does not work e.g. with WAR overlays. Brett, Jason, before I move this discussion to the mailing list, * could you please point me where should I look to add this feature? * Is it possible to write it as a plugin, or does it need some changes to the Maven core? * Would it be similar to the jarPath (should I look at it first)? Thanks. > Provide a way to create "virtual artifacts" out of plain .jar file. > --- > > Key: MNG-4599 > URL: http://jira.codehaus.org/browse/MNG-4599 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Ondrej Zizka >Assignee: Brett Porter > > During the time I have been using Maven, I have come across numerous cases > when I desperately needed to turn a simple .jar file into a dependency. > Currently, this involves installing it properly to the repository first, and > only then it can be used. > I suggest to introduce some construct which would take a list of .jar files > and turn them into dependencies in the sense they would be added to the > classpaths, could be used for WAR overlays, etc. Of course, they would not > have any transitional dependencies. > > > ../../releases/50GAAS/jboss-as/common/lib > >... > > This would greately improve Maven's openness to non-mavenized world, and > usability in cases when you really get a plain .jar/.war/.ear/... before > every build cycle. -- 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: (MNG-4599) Provide a way to create "virtual artifacts" out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215058#action_215058 ] Ondrej Zizka edited comment on MNG-4599 at 3/23/10 8:20 PM: *Paul*, the problem is that I don't want to do it at all, because it's pointless and the ONLY REASON to do it is just to make Maven happy. These artifact would never be used again. See above. *Brett*, I am 100 % sure that it would be misused. But is that a reason not to give the users possibility? I can think of countless Maven features which can be "misused" - e.g. * using various archiving plugin to actually build WAR/EAR/..., * using the Ant Plugin to do everything, * setting test and source path to the same directory to get the classes of the test to the result (another Maven flaw complicating usage of JSFUnit), * completely re-mapping the build phases to accomodate all steps that the build process needs, * using XSLT plugin to modify POMs of other module, etc etc. (I could continue but that's not what this issue is about) - are these going to be removed for being misused? My collegue already wrote a plugin which puts the .jar's on the classpath, but it's a ad-hoc solution and does not work e.g. with WAR overlays. Brett, Jason, before I move this discussion to the mailing list, * could you please point me where should I look to add this feature? * Is it possible to write it as a plugin, or does it need some changes to the Maven core? * Would it be similar to the jarPath (should I look at it first)? Thanks. was (Author: pekarna): *Paul*, the problem is that I don't want to do it at all, because it's pointless and the ONLY REASON to do it is just to make Maven happy. These artifact would never be used again. See above. *Brett*, I am 100 % sure that it would be misused. But is that a reason not to give the users possibility? I can think of countless Maven features which can be "misused" - e.g. * using various archiving plugin to actually build WAR/EAR/..., * using the Ant Plugin to do everything, setting test and source path to the same directory to get the classes of the test to the result (another Maven flaw complicating usage of JSFUnit), * completely re-mapping the build phases to accomodate all steps that the build process needs, etc etc. (I could continue but that's not what this issue is about) - are these going to be removed for being misused? My collegue already wrote a plugin which puts the .jar's on the classpath, but it's a ad-hoc solution and does not work e.g. with WAR overlays. Brett, Jason, before I move this discussion to the mailing list, * could you please point me where should I look to add this feature? * Is it possible to write it as a plugin, or does it need some changes to the Maven core? * Would it be similar to the jarPath (should I look at it first)? Thanks. > Provide a way to create "virtual artifacts" out of plain .jar file. > --- > > Key: MNG-4599 > URL: http://jira.codehaus.org/browse/MNG-4599 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Ondrej Zizka >Assignee: Brett Porter > > During the time I have been using Maven, I have come across numerous cases > when I desperately needed to turn a simple .jar file into a dependency. > Currently, this involves installing it properly to the repository first, and > only then it can be used. > I suggest to introduce some construct which would take a list of .jar files > and turn them into dependencies in the sense they would be added to the > classpaths, could be used for WAR overlays, etc. Of course, they would not > have any transitional dependencies. > > > ../../releases/50GAAS/jboss-as/common/lib > >... > > This would greately improve Maven's openness to non-mavenized world, and > usability in cases when you really get a plain .jar/.war/.ear/... before > every build cycle. -- 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-4599) Provide a way to create "virtual artifacts" out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215226#action_215226 ] Ondrej Zizka commented on MNG-4599: --- Paul, the way people make dinner is: * Peel the potatoes * Salt the potatoes * Boil the potatoes * Fry some steak * Put it on the plate So if I want to make a tea, I should: * Peel the potatoes * Salt the potatoes * Boil the potatoes because that's the way how potatoes are prepared. > Provide a way to create "virtual artifacts" out of plain .jar file. > --- > > Key: MNG-4599 > URL: http://jira.codehaus.org/browse/MNG-4599 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Ondrej Zizka >Assignee: Brett Porter > > During the time I have been using Maven, I have come across numerous cases > when I desperately needed to turn a simple .jar file into a dependency. > Currently, this involves installing it properly to the repository first, and > only then it can be used. > I suggest to introduce some construct which would take a list of .jar files > and turn them into dependencies in the sense they would be added to the > classpaths, could be used for WAR overlays, etc. Of course, they would not > have any transitional dependencies. > > > ../../releases/50GAAS/jboss-as/common/lib > >... > > This would greately improve Maven's openness to non-mavenized world, and > usability in cases when you really get a plain .jar/.war/.ear/... before > every build cycle. -- 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: (MNG-4599) Provide a way to create "virtual artifacts" out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215226#action_215226 ] Ondrej Zizka edited comment on MNG-4599 at 3/24/10 10:49 PM: - Paul, the way people make dinner is: * Peel the potatoes * Salt the potatoes * Boil the potatoes * Fry some steak * Put it on the plate So if I want to make a tea, I should: * Peel the potatoes * Salt the potatoes * Boil the potatoes * Pour the water to a cup with a tea bag because that's the way how potatoes are prepared. was (Author: pekarna): Paul, the way people make dinner is: * Peel the potatoes * Salt the potatoes * Boil the potatoes * Fry some steak * Put it on the plate So if I want to make a tea, I should: * Peel the potatoes * Salt the potatoes * Boil the potatoes * Pour the water to a cup with a tea bag because that's the way how potatoes are prepared. > Provide a way to create "virtual artifacts" out of plain .jar file. > --- > > Key: MNG-4599 > URL: http://jira.codehaus.org/browse/MNG-4599 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Ondrej Zizka >Assignee: Brett Porter > > During the time I have been using Maven, I have come across numerous cases > when I desperately needed to turn a simple .jar file into a dependency. > Currently, this involves installing it properly to the repository first, and > only then it can be used. > I suggest to introduce some construct which would take a list of .jar files > and turn them into dependencies in the sense they would be added to the > classpaths, could be used for WAR overlays, etc. Of course, they would not > have any transitional dependencies. > > > ../../releases/50GAAS/jboss-as/common/lib > >... > > This would greately improve Maven's openness to non-mavenized world, and > usability in cases when you really get a plain .jar/.war/.ear/... before > every build cycle. -- 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
