[jira] [Commented] (MCOMPILER-446) Compiler is crashing while setting JPMS module version
[
https://issues.apache.org/jira/browse/MCOMPILER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754365#comment-17754365
]
Bruno Medeiros commented on MCOMPILER-446:
--
Ticket was closed with:
> As described in the JIRA ticket, the maven-compiler-plugin should always use
> --module-version based on the project version.
Given it's in the original description that:
> Because we set versions in pom to local-SNAPHOT
This issue was never about setting a different version, it's was suggested as a
workaround, it was about `maven-compiler-plugin` crashing when a non-semver
version is being used.
> JDK-8250678 fixed with Java 18
This is an upstream issue, then? No fixes for Java 17 should be expected, right?
> Compiler is crashing while setting JPMS module version
> --
>
> Key: MCOMPILER-446
> URL: https://issues.apache.org/jira/browse/MCOMPILER-446
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Bruno Medeiros
>Assignee: Robert Scholte
>Priority: Major
>
> I have upgraded maven compiler plugin to 3.8.1 and I started getting this
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Fatal error compiling: error: bad value
> for --module-version option: 'local-SNAPSHOT' -> [Help 1]{code}
> Because we set versions in pom to local-SNAPHOT (and use maven-version-plugin
> when we actually realease to set a proper version), all our builds are
> failing locally.
> It seems javac does not like versions that do not have just alpha characters,
> like ours local-SNAPHOT.
> I thought about a few ways to fix that:
> * Allow the use of --module-version to be optional through config
> * Allow the version itself to be configurable
> * Validate if the version is a valid version for --module-version and not
> set it in case it is not
> Let me know what you guys think, I can try to provide a PR with the given
> solution.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MCOMPILER-446) Compiler is crashing while setting JPMS module version
[
https://issues.apache.org/jira/browse/MCOMPILER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Medeiros updated MCOMPILER-446:
-
Summary: Compiler is crashing while setting JPMS module version (was:
Compiler is crashing while setting module version)
> Compiler is crashing while setting JPMS module version
> --
>
> Key: MCOMPILER-446
> URL: https://issues.apache.org/jira/browse/MCOMPILER-446
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Bruno Medeiros
>Priority: Major
>
> I have upgraded maven compiler plugin to 3.8.1 and I started getting this
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Fatal error compiling: error: bad value
> for --module-version option: 'local-SNAPSHOT' -> [Help 1]{code}
> Because we set versions in pom to local-SNAPHOT (and use maven-version-plugin
> when we actually realease to set a proper version), all our builds are
> failing locally.
> It seems javac does not like versions that do not have just alpha characters,
> like ours local-SNAPHOT.
> I thought about a few ways to fix that:
> * Allow the use of --module-version to be optional through config
> * Allow the version itself to be configurable
> * Validate if the version is a valid version for --module-version and not
> set it in case it is not
> Let me know what you guys think, I can try to provide a PR with the given
> solution.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-124) Need better plan for getting dependency-reduced-pom.xml out of basedir
[ https://issues.apache.org/jira/browse/MSHADE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265692#comment-17265692 ] Bruno Medeiros commented on MSHADE-124: --- Writing this temporary file may be the cause of this other issue. > Need better plan for getting dependency-reduced-pom.xml out of basedir > -- > > Key: MSHADE-124 > URL: https://issues.apache.org/jira/browse/MSHADE-124 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 1.7.1 >Reporter: Benson Margulies >Priority: Major > > MSHADE-123 reported that putting the d-r-p into some location other > than 'basedir' causes 'basedir' to follow it around, which can break builds. > This is hard to fix, given the core maven definition of basedir as 'the dir > containing the pom' with no option to change it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (MSHADE-124) Need better plan for getting dependency-reduced-pom.xml out of basedir
[ https://issues.apache.org/jira/browse/MSHADE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Medeiros updated MSHADE-124: -- Comment: was deleted (was: Writing this temporary file may be the cause of this other issue.) > Need better plan for getting dependency-reduced-pom.xml out of basedir > -- > > Key: MSHADE-124 > URL: https://issues.apache.org/jira/browse/MSHADE-124 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 1.7.1 >Reporter: Benson Margulies >Priority: Major > > MSHADE-123 reported that putting the d-r-p into some location other > than 'basedir' causes 'basedir' to follow it around, which can break builds. > This is hard to fix, given the core maven definition of basedir as 'the dir > containing the pom' with no option to change it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-329) Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad infinitum
[
https://issues.apache.org/jira/browse/MSHADE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265656#comment-17265656
]
Bruno Medeiros commented on MSHADE-329:
---
> There is no problem running {{mvn}} in single-thread mode.
I can confirm this bug, same thing happening here if `-T4C` is added to the
build.
I'm attaching a thread dump taken while maven build was stuck, we can seem some
builder threads in `RUNNABLE` state, but writing to files like crazy.
As disabling parallel build seems a very harsh workaround, we are doing this
here:
{code:java}
org.apache.maven.plugins
maven-shade-plugin
3.2.4
false
{code}
I even dare to suggest we disable reduced pom generation by default as most
people using it are just generating a uber jar and don't need a pom for that
(personal opinion).
> Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad
> infinitum
>
>
> Key: MSHADE-329
> URL: https://issues.apache.org/jira/browse/MSHADE-329
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Håkon Hallingstad
>Priority: Major
> Attachments: mshade-329-thread-dump.txt
>
>
> I have a multi-threaded {{mvn install}} that seems to halt but ends up using
> 200% CPU, in about 50% of the invocations. The {{mvn}} command used is:
> {panel}
> mvn -T1C -nsu -Dmaven.source.skip -Dmaven.javadoc.skip -Dmaven.test.skip
> install -rf :MODULE
> {panel}
> Using {{mvnDebug}} I have found out that there are 2 running Java threads,
> each writing {{dependency-reduced-pom.xml}} in two different modules {{A}}
> and {{B}}, respectively. These files seems to become several MB large, before
> they're deleted and then written again, and so forth.
> I have looked into one of the threads, and there is a
> {{rewriteDependencyReducedPomIfWeHaveReduction}} in ShadeMojo with a
> {{loopCounter}} with value 2735, that just keeps increasing. Presumably there
> is something like one dependency-reduced-pom.xml written per iteration.
> From the source code it seems this can only happen if
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L1172
> is hit at least that number of times, meaning the ShadeMojo adds that many
> exclusions, which seems to correspond to hamcrest-core:
> {noformat}
>
>
> junit
> junit
> 4.12
> test
>
>
> hamcrest-core
> org.hamcrest
>
>
> hamcrest-core
> org.hamcrest
>
> ...
> {noformat}
> {panel}
> grep hamcrest-core dependency-reduced-pom.xml | wc -l
> 2735
> {panel}
>
> The same exclusion is added {{loopCounter}} times in {{updateExcludesInDeps}}.
> There is no problem running {{mvn}} in single-thread mode.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-329) Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad infinitum
[
https://issues.apache.org/jira/browse/MSHADE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Medeiros updated MSHADE-329:
--
Attachment: mshade-329-thread-dump.txt
> Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad
> infinitum
>
>
> Key: MSHADE-329
> URL: https://issues.apache.org/jira/browse/MSHADE-329
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Håkon Hallingstad
>Priority: Major
> Attachments: mshade-329-thread-dump.txt
>
>
> I have a multi-threaded {{mvn install}} that seems to halt but ends up using
> 200% CPU, in about 50% of the invocations. The {{mvn}} command used is:
> {panel}
> mvn -T1C -nsu -Dmaven.source.skip -Dmaven.javadoc.skip -Dmaven.test.skip
> install -rf :MODULE
> {panel}
> Using {{mvnDebug}} I have found out that there are 2 running Java threads,
> each writing {{dependency-reduced-pom.xml}} in two different modules {{A}}
> and {{B}}, respectively. These files seems to become several MB large, before
> they're deleted and then written again, and so forth.
> I have looked into one of the threads, and there is a
> {{rewriteDependencyReducedPomIfWeHaveReduction}} in ShadeMojo with a
> {{loopCounter}} with value 2735, that just keeps increasing. Presumably there
> is something like one dependency-reduced-pom.xml written per iteration.
> From the source code it seems this can only happen if
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L1172
> is hit at least that number of times, meaning the ShadeMojo adds that many
> exclusions, which seems to correspond to hamcrest-core:
> {noformat}
>
>
> junit
> junit
> 4.12
> test
>
>
> hamcrest-core
> org.hamcrest
>
>
> hamcrest-core
> org.hamcrest
>
> ...
> {noformat}
> {panel}
> grep hamcrest-core dependency-reduced-pom.xml | wc -l
> 2735
> {panel}
>
> The same exclusion is added {{loopCounter}} times in {{updateExcludesInDeps}}.
> There is no problem running {{mvn}} in single-thread mode.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-329) Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad infinitum
[
https://issues.apache.org/jira/browse/MSHADE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Medeiros updated MSHADE-329:
--
Attachment: (was: mshade-329-stacktrace.txt)
> Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad
> infinitum
>
>
> Key: MSHADE-329
> URL: https://issues.apache.org/jira/browse/MSHADE-329
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Håkon Hallingstad
>Priority: Major
>
> I have a multi-threaded {{mvn install}} that seems to halt but ends up using
> 200% CPU, in about 50% of the invocations. The {{mvn}} command used is:
> {panel}
> mvn -T1C -nsu -Dmaven.source.skip -Dmaven.javadoc.skip -Dmaven.test.skip
> install -rf :MODULE
> {panel}
> Using {{mvnDebug}} I have found out that there are 2 running Java threads,
> each writing {{dependency-reduced-pom.xml}} in two different modules {{A}}
> and {{B}}, respectively. These files seems to become several MB large, before
> they're deleted and then written again, and so forth.
> I have looked into one of the threads, and there is a
> {{rewriteDependencyReducedPomIfWeHaveReduction}} in ShadeMojo with a
> {{loopCounter}} with value 2735, that just keeps increasing. Presumably there
> is something like one dependency-reduced-pom.xml written per iteration.
> From the source code it seems this can only happen if
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L1172
> is hit at least that number of times, meaning the ShadeMojo adds that many
> exclusions, which seems to correspond to hamcrest-core:
> {noformat}
>
>
> junit
> junit
> 4.12
> test
>
>
> hamcrest-core
> org.hamcrest
>
>
> hamcrest-core
> org.hamcrest
>
> ...
> {noformat}
> {panel}
> grep hamcrest-core dependency-reduced-pom.xml | wc -l
> 2735
> {panel}
>
> The same exclusion is added {{loopCounter}} times in {{updateExcludesInDeps}}.
> There is no problem running {{mvn}} in single-thread mode.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-329) Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad infinitum
[
https://issues.apache.org/jira/browse/MSHADE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Medeiros updated MSHADE-329:
--
Attachment: mshade-329-stacktrace.txt
> Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad
> infinitum
>
>
> Key: MSHADE-329
> URL: https://issues.apache.org/jira/browse/MSHADE-329
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Håkon Hallingstad
>Priority: Major
> Attachments: mshade-329-stacktrace.txt
>
>
> I have a multi-threaded {{mvn install}} that seems to halt but ends up using
> 200% CPU, in about 50% of the invocations. The {{mvn}} command used is:
> {panel}
> mvn -T1C -nsu -Dmaven.source.skip -Dmaven.javadoc.skip -Dmaven.test.skip
> install -rf :MODULE
> {panel}
> Using {{mvnDebug}} I have found out that there are 2 running Java threads,
> each writing {{dependency-reduced-pom.xml}} in two different modules {{A}}
> and {{B}}, respectively. These files seems to become several MB large, before
> they're deleted and then written again, and so forth.
> I have looked into one of the threads, and there is a
> {{rewriteDependencyReducedPomIfWeHaveReduction}} in ShadeMojo with a
> {{loopCounter}} with value 2735, that just keeps increasing. Presumably there
> is something like one dependency-reduced-pom.xml written per iteration.
> From the source code it seems this can only happen if
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L1172
> is hit at least that number of times, meaning the ShadeMojo adds that many
> exclusions, which seems to correspond to hamcrest-core:
> {noformat}
>
>
> junit
> junit
> 4.12
> test
>
>
> hamcrest-core
> org.hamcrest
>
>
> hamcrest-core
> org.hamcrest
>
> ...
> {noformat}
> {panel}
> grep hamcrest-core dependency-reduced-pom.xml | wc -l
> 2735
> {panel}
>
> The same exclusion is added {{loopCounter}} times in {{updateExcludesInDeps}}.
> There is no problem running {{mvn}} in single-thread mode.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MCOMPILER-446) Compiler is crashing while setting module version
Bruno Medeiros created MCOMPILER-446:
Summary: Compiler is crashing while setting module version
Key: MCOMPILER-446
URL: https://issues.apache.org/jira/browse/MCOMPILER-446
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.8.1
Reporter: Bruno Medeiros
I have upgraded maven compiler plugin to 3.8.1 and I started getting this error:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile)
on project common: Fatal error compiling: error: bad value for --module-version
option: 'local-SNAPSHOT' -> [Help 1]{code}
Because we set versions in pom to local-SNAPHOT (and use maven-version-plugin
when we actually realease to set a proper version), all our builds are failing
locally.
It seems javac does not like versions that do not have just alpha characters,
like ours local-SNAPHOT.
I thought about a few ways to fix that:
* Allow the use of --module-version to be optional through config
* Allow the version itself to be configurable
* Validate if the version is a valid version for --module-version and not set
it in case it is not
Let me know what you guys think, I can try to provide a PR with the given
solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MWAR-279) WAR plugin fails during incremental build with JDK7
[
https://issues.apache.org/jira/browse/MWAR-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15007579#comment-15007579
]
Bruno Medeiros commented on MWAR-279:
-
It happens all the time for me with cache enabled on prepape-package and war
plugin versions 2.1 e 2.2 with java 7 e 8.
Java 7 and war plugin 2.4 seems to fix this.
> WAR plugin fails during incremental build with JDK7
> ---
>
> Key: MWAR-279
> URL: https://issues.apache.org/jira/browse/MWAR-279
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1.1, 2.2
> Environment: Windows7 64bit
> maven 3.0.3
> jdk-1.7.0_03
>Reporter: Liya Katz
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
>
> Same error for war-plugin 2.2 and 2.1.1
> Appears when running incremental build with jdk 7.
> Build from clean works fine.
> From the log:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project
> xxx-web: Execution default-war of goal
> org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Cannot construct
> org.apache.maven.plugin.war.util.WebappStructure as it does not have a
> no-args constructor : Cannot construct
> org.apache.maven.plugin.war.util.WebappStructure as it does not have a
> no-args constructor
> [ERROR] Debugging information
> [ERROR] message : Cannot construct
> org.apache.maven.plugin.war.util.WebappStructure as it does not have a
> no-args constructor
> [ERROR] cause-exception :
> com.thoughtworks.xstream.converters.reflection.ObjectAccessException
> [ERROR] cause-message : Cannot construct
> org.apache.maven.plugin.war.util.WebappStructure as it does not have a
> no-args constructor
> [ERROR] class : org.apache.maven.plugin.war.util.WebappStructure
> [ERROR] required-type : org.apache.maven.plugin.war.util.WebappStructure
> [ERROR] path: /webapp-structure
> [ERROR] ---
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on
> project skyboxview-system-web: Execution default-war of goal
> org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Cannot construct
> org.apache.maven.plugin.war.util.WebappStructure as it does not have a
> no-args constructor : Cannot construct
> org.apache.maven.plugin.war.util.WebappStructure as it does not have a
> no-args constructor
> Debugging information
> message : Cannot construct
> org.apache.maven.plugin.war.util.WebappStructure as it does not have a
> no-args constructor
> cause-exception :
> com.thoughtworks.xstream.converters.reflection.ObjectAccessException
> cause-message : Cannot construct
> org.apache.maven.plugin.war.util.WebappStructure as it does not have a
> no-args constructor
> class : org.apache.maven.plugin.war.util.WebappStructure
> required-type : org.apache.maven.plugin.war.util.WebappStructure
> path: /webapp-structure
> ---
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war
> failed: Cannot construct org.apache.maven.plugin.war.util.WebappStructure as
> it does not have a no-args constructor : Cannot construct
> org.apache.maven.plugin.war.util.WebappStructure as it does not have a
> no-args constructor
> Debugging
[jira] [Commented] (MNG-5873) .mvn/extensions.xml ignored under Cygwin
[
https://issues.apache.org/jira/browse/MNG-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991774#comment-14991774
]
Bruno Medeiros commented on MNG-5873:
-
Running mvn.cmd from Cygwin shell, seems to work fine. Why doesn't the mvn
script simply redirect to mvn.cmd in Windows?
> .mvn/extensions.xml ignored under Cygwin
>
>
> Key: MNG-5873
> URL: https://issues.apache.org/jira/browse/MNG-5873
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.3
> Environment: Cygwin on Windows 8.1
>Reporter: Dominykas Mostauskis
> Labels: cygwin, extensions
>
> Suppose I download example maven projects that use .mvn/extensions.xml and do
> mvn install:
> {code}
> git clone https://github.com/takari/polyglot-maven-examples
> cd polyglot-maven-examples/yaml
> mvn install
> {code}
> under Cygwin the extensions.xml is not accounted for:
> {code:title=Cygwin error}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.187 s
> [INFO] Finished at: 2015-08-19T10:07:05+03:00
> [INFO] Final Memory: 4M/75M
> [INFO]
>
> [ERROR] The goal you specified requires a project to execute but there is no
> POM in this directory
> (D:\ivairus\cygwin\home\Domas\projektai\another-test\polyglot-maven-examples\yaml).
> Please verify you invoked Maven from the correct directory. -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MissingProjectException
> {code}
> Under Windows CMD mvn install works fine.
> {code:title=Windows CMD success}
> [INFO] Scanning for projects...
> D:\ivairus\cygwin\home\Domas\projektai\another-test\polyglot-maven-examples\yaml\.polyglot.pom.yml
> [INFO]
> [INFO]
>
> [INFO] Building YAML Maven Love 0.0.1-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> yaml-project ---
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources, i.e. build is platfo
> rm dependent!
> [INFO] skip non existing resourceDirectory
> D:\ivairus\cygwin\home\Domas\projektai\another-test\polyg
> lot-maven-examples\yaml\src\main\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ yaml-project
> ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> yaml-project ---
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources, i.e. build is platfo
> rm dependent!
> [INFO] skip non existing resourceDirectory
> D:\ivairus\cygwin\home\Domas\projektai\another-test\polyg
> lot-maven-examples\yaml\src\test\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
> yaml-project ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ yaml-project ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ yaml-project ---
> [INFO] Building jar:
> D:\ivairus\cygwin\home\Domas\projektai\another-test\polyglot-maven-examples\yam
> l\target\yaml-project-0.0.1-SNAPSHOT.jar
> [INFO]
> [INFO] --- maven-install-plugin:2.4:install (default-install) @ yaml-project
> ---
> [INFO] Installing
> D:\ivairus\cygwin\home\Domas\projektai\another-test\polyglot-maven-examples\yaml\t
> arget\yaml-project-0.0.1-SNAPSHOT.jar to
> C:\Users\Domas\.m2\repository\io\takari\polyglot\yaml-proje
> ct\0.0.1-SNAPSHOT\yaml-project-0.0.1-SNAPSHOT.jar
> [INFO] Installing
> D:\ivairus\cygwin\home\Domas\projektai\another-test\polyglot-maven-examples\yaml\.
> polyglot.pom.yml to
> C:\Users\Domas\.m2\repository\io\takari\polyglot\yaml-project\0.0.1-SNAPSHOT\yam
> l-project-0.0.1-SNAPSHOT.pom
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 10.038 s
> [INFO] Finished at: 2015-08-19T10:10:15+03:00
> [INFO] Final Memory: 13M/178M
> [INFO]
>
> {code}
--
[jira] (WAGON-421) Not authorized when deploying artifact following HTTP redirect
[
https://jira.codehaus.org/browse/WAGON-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356290#comment-356290
]
Bruno Medeiros commented on WAGON-421:
--
Nobody has anything to say about it?
Not authorized when deploying artifact following HTTP redirect
Key: WAGON-421
URL: https://jira.codehaus.org/browse/WAGON-421
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Affects Versions: 2.4, 2.5, 2.6, 2.7
Environment: Maven 3.0.4+
Reporter: Bruno Medeiros
Priority: Critical
I always deployed artifacts to my repository without problems, until last
week when I was forced to migrate my repository to a different URL. I still
have control of the old domain, so I set a redirect in Apache on the old
domain, like this:
bq. Redirect permanent /maven2 http://newsubdomain.company.com/maven2
Deploys works perfect with the old URL for maven 2.2.1 and 3.0.3, but all
maven 3.0.4+ are broken (even 3.1.1 and 3.2.3). Here follows my test:
# ~/apache-maven-3.2.3/bin/mvn -X deploy
error (full stacktrace):
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
project jcompany_flex_util: Failed to retrieve remote metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml: Could
not transfer metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml from/to
company-repo (http://dev.company.com.br:80/maven2/libs-snapshots-local): Not
authorized , ReasonPhrase:Unauthorized. - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy
(default-deploy) on project jcompany_flex_util: Failed to retrieve remote
metadata br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml:
Could not transfer metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml from/to
company-repo (http://dev.company.com.br:80/maven2/libs-snapshots-local): Not
authorized , ReasonPhrase:Unauthorized.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
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: org.apache.maven.plugin.MojoExecutionException: Failed to retrieve
remote metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml: Could
not transfer metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml from/to
company-repo (http://dev.company.com.br:80/maven2/libs-snapshots-local): Not
authorized , ReasonPhrase:Unauthorized.
at
org.apache.maven.plugin.deploy.DeployMojo.deployProject(DeployMojo.java:284)
at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:169)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
Failed to retrieve remote metadata
[jira] (WAGON-421) Not authorized when deploying artifact following HTTP redirect
Bruno Medeiros created WAGON-421:
Summary: Not authorized when deploying artifact following HTTP
redirect
Key: WAGON-421
URL: https://jira.codehaus.org/browse/WAGON-421
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Affects Versions: 2.7, 2.6, 2.5, 2.4
Environment: Maven 3.0.4+
Reporter: Bruno Medeiros
Priority: Critical
I always deployed artifacts to my repository without problems, until last week
when I was forced to migrate my repository to a different URL. I still have
control of the old domain, so I set a redirect in Apache on the old domain,
like this:
bq. Redirect permanent /maven2 http://newsubdomain.company.com/maven2
Deploys works perfect with the old URL for maven 2.2.1 and 3.0.3, but all maven
3.0.4+ are broken (even 3.1.1 and 3.2.3). Here follows my test:
# ~/apache-maven-3.2.3/bin/mvn -X deploy
error (full stacktrace):
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
project jcompany_flex_util: Failed to retrieve remote metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml: Could not
transfer metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml from/to
company-repo (http://dev.company.com.br:80/maven2/libs-snapshots-local): Not
authorized , ReasonPhrase:Unauthorized. - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
project jcompany_flex_util: Failed to retrieve remote metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml: Could not
transfer metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml from/to
company-repo (http://dev.company.com.br:80/maven2/libs-snapshots-local): Not
authorized , ReasonPhrase:Unauthorized.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
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: org.apache.maven.plugin.MojoExecutionException: Failed to retrieve
remote metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml: Could not
transfer metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml from/to
company-repo (http://dev.company.com.br:80/maven2/libs-snapshots-local): Not
authorized , ReasonPhrase:Unauthorized.
at
org.apache.maven.plugin.deploy.DeployMojo.deployProject(DeployMojo.java:284)
at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:169)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
Failed to retrieve remote metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml: Could not
transfer metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml from/to
company-repo (http://dev.company.com.br:80/maven2/libs-snapshots-local): Not
authorized , ReasonPhrase:Unauthorized.
[jira] (WAGON-369) wagon http doesn't follow HTTP 302 redirects for PUT
[
https://jira.codehaus.org/browse/WAGON-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=352971#comment-352971
]
Bruno Medeiros commented on WAGON-369:
--
Mukarram, I have a very similar problem, but I get the wrong Unauthorized
problem when following redirects with any maven above 3.0.4, even 3.1.1 a 3.2.3.
I've just created a new issue for that:
https://jira.codehaus.org/browse/WAGON-421
wagon http doesn't follow HTTP 302 redirects for PUT
Key: WAGON-369
URL: https://jira.codehaus.org/browse/WAGON-369
Project: Maven Wagon
Issue Type: Bug
Affects Versions: 2.2
Reporter: James Baldassari
Assignee: Olivier Lamy
Fix For: 2.3
We have a reverse proxy server sitting in front of our Artifactory
repository. We've been running with this configuration for over a year with
no problems until we upgraded to Maven 3.0.4 and maven-deploy-plugin 2.7.
When deploying an artifact to a repository, if the request returns a 302
redirect, maven-deploy-plugin 2.7 does not follow the redirect and simply
fails. It seems like a regression was introduced in maven-deploy-plugin some
time after v2.5 (the default version used by Maven 3.0.3, which works). The
full stack trace follows:
{noformat}
[INFO] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
project myartifact: Failed to deploy artifacts: Could not transfer artifact
mycompany:myartifact:pom:4.4.4 from/to maven01
(http://maven.mycompany.net/libs-releases-local): Failed to transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found. - [Help 1]
[INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
(default-deploy) on project myartifact: Failed to deploy artifacts: Could not
transfer artifact mycompany:myartifact:pom:4.4.4 from/to dxmaven01
(http://maven.mycompany.net/libs-releases-local): Failed to transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found.
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
[INFO]at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
[INFO]at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
[INFO]at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
[INFO]at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
[INFO]at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
[INFO]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO]at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO]at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO]at java.lang.reflect.Method.invoke(Method.java:597)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[INFO] Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
deploy artifacts: Could not transfer artifact mycompany:myartifact:pom:4.4.4
from/to dxmaven01 (http://maven.mycompany.net/libs-releases-local): Failed to
transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found.
[INFO]at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:193)
[INFO]at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
[INFO]at
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=343708#comment-343708 ] Bruno Medeiros commented on MNG-3092: - I sadly agree with Scott, the time for hope has gone. I use maven as it has no version range feature, I simply pretend it doesn't exist. I tried to use version ranges, migrated a lot of projects, and suddenly, ignoring the spec, the maven team changed the behaviour, with no feasible workaround. I spend days rolling back my changes. I'd love to trust and use maven version ranges again, but I face it as dream: if it happens, great. If it doesn't... Well, maybe one day I can have some free time and fork maven to do it right. Version ranges with non-snapshot bounds can contain snapshot versions - Key: MNG-3092 URL: https://jira.codehaus.org/browse/MNG-3092 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Mark Hobson Assignee: Jason van Zyl Fix For: 3.2.x Attachments: MNG-3092.patch, MNG-3092.patch Contrary to the 2.0 design docs: Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. -- from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification The following is equates to true: VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new DefaultArtifactVersion( 1.1-SNAPSHOT ) ) The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-279) WAR plugin fails during incremental build with JDK7
[
https://jira.codehaus.org/browse/MWAR-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=337571#comment-337571
]
Bruno Medeiros commented on MWAR-279:
-
I'm getting this error, even with clean, using the 'exploded' goal in the
'prepare-package' phase. Is it expected?
WAR plugin fails during incremental build with JDK7
---
Key: MWAR-279
URL: https://jira.codehaus.org/browse/MWAR-279
Project: Maven WAR Plugin
Issue Type: Bug
Affects Versions: 2.1.1, 2.2
Environment: Windows7 64bit
maven 3.0.3
jdk-1.7.0_03
Reporter: Liya Katz
Priority: Blocker
Fix For: 2.5
Same error for war-plugin 2.2 and 2.1.1
Appears when running incremental build with jdk 7.
Build from clean works fine.
From the log:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project
xxx-web: Execution default-war of goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
[ERROR] Debugging information
[ERROR] message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
[ERROR] cause-exception :
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
[ERROR] cause-message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
[ERROR] class : org.apache.maven.plugin.war.util.WebappStructure
[ERROR] required-type : org.apache.maven.plugin.war.util.WebappStructure
[ERROR] path: /webapp-structure
[ERROR] ---
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on
project skyboxview-system-web: Execution default-war of goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
Debugging information
message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
cause-exception :
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
class : org.apache.maven.plugin.war.util.WebappStructure
required-type : org.apache.maven.plugin.war.util.WebappStructure
path: /webapp-structure
---
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war
failed: Cannot construct org.apache.maven.plugin.war.util.WebappStructure as
it does not have a no-args constructor : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
Debugging information
message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317682#comment-317682 ] Bruno Medeiros commented on MNG-3092: - Caspar, for me it's also clear that it is a bug. We've also spent a lot of time to use version ranges in our projects, and double time to remove all versions from all projects, because of this and other version ranges bugs. Considering the age of this ticket, and the posts made by maven maintainers (mainly Jason van Zyl) recently, I don't think we'll have a decent fix for this soon. The only short term solution I can see is fork, which unfortunately I don't have resources to do. Version ranges with non-snapshot bounds can contain snapshot versions - Key: MNG-3092 URL: https://jira.codehaus.org/browse/MNG-3092 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Mark Hobson Assignee: Jason van Zyl Fix For: 3.1.1 Attachments: MNG-3092.patch Contrary to the 2.0 design docs: Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. -- from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification The following is equates to true: VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new DefaultArtifactVersion( 1.1-SNAPSHOT ) ) The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- 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-5353) version ranges: Ignore qualifiers in exclusive upper bound [lw,up)
[ https://jira.codehaus.org/browse/MNG-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=313496#comment-313496 ] Bruno Medeiros commented on MNG-5353: - It would be awesome to see ranges working like that! I Hope you can fix that in time to 3.1! version ranges: Ignore qualifiers in exclusive upper bound [lw,up) -- Key: MNG-5353 URL: https://jira.codehaus.org/browse/MNG-5353 Project: Maven 2 3 Issue Type: Wish Components: Dependencies Affects Versions: 2.0.11, 2.2.1, 3.0.4 Reporter: Jesse Long Fix For: 3.1.0 Please change the behaviour of exclusive upper bounds to the following: In a version range, like [1.7.0,1.8.0), 1.8.0-alpha1 should not be included in the range. 1.8.0* should not be included in the range. This allows for us configure natural ranges for projects using semantic versioning. Please see: http://markmail.org/message/4tubas4uok6ahbcp http://markmail.org/message/s2ry2uru4ibub43q -- 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] Commented: (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=279691#comment-279691 ] Bruno Medeiros commented on MNG-3092: - I agree someone can find some usefulness in resolving a snapshot with neither the lower limit nor upper limit of the range being a SNAPSHOT, but to support these cases we're transforming version ranges in a useless function IMHO. Resolving a snapshot without any snapshot boundary makes no sense to me. It's against the own concept of ranges. If you declare a range, you are saying that you project WILL work with any version that matches this range, so why people say that the snapshot should be resolved? why would you choose a snapshot if you can choose a release as both match? If you need something that is only on the latest snapshot, you should go to you pom and change the range boundary to say that. Have such a bug open for this long time, without a workaround, is a shame! If the community don't agree about a solution, so let's use the most voted, the one the project leader decides, or whatever. Do NOTHING just to be backward compatible is the WORST option. Version ranges with non-snapshot bounds can contain snapshot versions - Key: MNG-3092 URL: https://jira.codehaus.org/browse/MNG-3092 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Mark Hobson Attachments: MNG-3092.patch Contrary to the 2.0 design docs: Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. -- from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification The following is equates to true: VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new DefaultArtifactVersion( 1.1-SNAPSHOT ) ) The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-249) War plugin doesn't let modify the contents of the exploded directory
[ http://jira.codehaus.org/browse/MWAR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262834#action_262834 ] Bruno Medeiros commented on MWAR-249: - It would be good to see this fixed. Is there any rules to patch proposal? War plugin doesn't let modify the contents of the exploded directory -- Key: MWAR-249 URL: http://jira.codehaus.org/browse/MWAR-249 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1, 2.2 Environment: maven 3 Reporter: cem koc Attachments: Test.zip Shortly I am trying to modify the contents of the exploded directory before package phase. I was successfully modifying contents of the exploded directories before updating my war plugin. My goal was 1) Creating an exploded directory of the sources. 2) Modifying contents with Replace plugin 3) Creating a war file including modified files To recreate issue, *) mvn clean prepare-package -- This will create as expected file. *) mvn clean package -- This will replace again modified file with old one. Thanks -- 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: (MRELEASE-414) NullPointerException at DefaultVersionInfo.java line 122
[ http://jira.codehaus.org/browse/MRELEASE-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=223171#action_223171 ] Bruno Medeiros commented on MRELEASE-414: - I got the same error on maven 2.0.10, 2.0.11 and 2.2.1. My dependency declaration omits the version number, that is in the dependency management of parent pom, declared as a range. I think this bug should be reopened. Snnipets: dep: dependency groupIdbr.com.company/groupId artifactIdjcompany_util/artifactId /dependency parent: dependencyManagement dependencies ... dependency groupIdbr.com.company/groupId artifactIdjcompany_util/artifactId version[1.0.0,2.0.0)/version /dependency /dependencies /dependencyManagement Stack: [INFO] Trace java.lang.NullPointerException at java.util.regex.Matcher.getTextLength(Matcher.java:1140) at java.util.regex.Matcher.reset(Matcher.java:291) at java.util.regex.Matcher.init(Matcher.java:211) at java.util.regex.Pattern.matcher(Pattern.java:888) at org.apache.maven.shared.release.versions.DefaultVersionInfo.init(DefaultVersionInfo.java:123) at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.processSnapshot(CheckDependencySnapshotsPhase.java:399) at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.resolveSnapshots(CheckDependencySnapshotsPhase.java:346) at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:228) at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:107) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:196) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:133) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:96) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:161) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:345) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:132) at org.apache.maven.cli.MavenCli.main(MavenCli.java:290) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) NullPointerException at DefaultVersionInfo.java line 122 Key: MRELEASE-414 URL: http://jira.codehaus.org/browse/MRELEASE-414 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-8 Environment: Windows XP Home SP3 JDK 1.6.0_11 Reporter: Markus KARG Priority: Blocker Attachments: pom.xml mvn release:prepare produces NullPointerException: C:\addressbookmvn release:prepare [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'release'. WAGON_VERSION: 1.0-beta-2 [INFO] [INFO] Building WebDAV Support for JAX-RS Address-Book Sample [INFO]task-segment: [release:prepare] (aggregator-style) [INFO]
[jira] Commented: (MRELEASE-350) Option '0' for specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): is broken
[ http://jira.codehaus.org/browse/MRELEASE-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=195501#action_195501 ] Bruno Medeiros commented on MRELEASE-350: - I can confirm that bug, with option 1 all works fine. Option '0' for specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): is broken -- Key: MRELEASE-350 URL: http://jira.codehaus.org/browse/MRELEASE-350 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-8 Reporter: Craig Priority: Minor CheckDependencySnapshotsPhase.java has a bug when processing this prompt with the 0 option selected: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): 0 When choosing 0: All, the plugin goes through the motions of asking to resolve snapshot dependencies, but after resolving them, fails saying there are still snapshot dependencies. This bug lies with the function resolveSnapshots relying on the function processSnapshot to remove resolved dependencies from the set. This works for all cases except 0, which creates a new dependency set -- 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
