[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120903#comment-16120903 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user jon-bell commented on the issue: https://github.com/apache/maven-surefire/pull/161 @Tibor17 Let me know if there is anything else I can do on this. Thanks Jonathan > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MINSTALL-134) Remove checksum generation
[ https://issues.apache.org/jira/browse/MINSTALL-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120843#comment-16120843 ] Matt Nelson commented on MINSTALL-134: -- This issue contradicts MINSTALL-82 where it says that sha256 support could be added in 3.0.0 where as this issue wants to remove checksum generation. > Remove checksum generation > -- > > Key: MINSTALL-134 > URL: https://issues.apache.org/jira/browse/MINSTALL-134 > Project: Maven Install Plugin > Issue Type: Improvement >Affects Versions: 2.5.2 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 3.0.0 > > > Checksum doesn't make sense for install to local repository. It should be > part of the deployments of artifacts. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1403) [Jigsaw] [Java 9] add "--add-modules ALL-SYSTEM" to forked CLI argument
[
https://issues.apache.org/jira/browse/SUREFIRE-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120425#comment-16120425
]
Tibor Digana commented on SUREFIRE-1403:
I have made a new update.
> [Jigsaw] [Java 9] add "--add-modules ALL-SYSTEM" to forked CLI argument
> ---
>
> Key: SUREFIRE-1403
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1403
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
>
> Calling *findClass( cls, "java.se.ee")* in *IsolatedClassLoader* does not
> help and does not do anything because the module is ignored in Java 9.
> In-plugin provider does not have any problem to load classes from entire JDK.
> Forked JVM would work only after added
> {{--add-modules ALL-SYSTEM}}
> The fix would be to add "--add-modules ALL-SYSTEM" if {{--add-modules}} is
> not specified by user at Java 9+.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MSHARED-653) Upgrade to plexus-archiver 3.5
[ https://issues.apache.org/jira/browse/MSHARED-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120416#comment-16120416 ] Hudson commented on MSHARED-653: FAILURE: Integrated in Jenkins build maven-shared #3750 (See [https://builds.apache.org/job/maven-shared/3750/]) [MSHARED-653] Upgrade to plexus-archiver 3.5 o We need to upgrade JDK requirement to JDK 7 o Bumped the version to 3.2.0-SNAPSHOT (khmarbaise: [http://svn.apache.org/viewvc/?view=rev=1804594]) * (edit) maven-archiver/pom.xml > Upgrade to plexus-archiver 3.5 > -- > > Key: MSHARED-653 > URL: https://issues.apache.org/jira/browse/MSHARED-653 > Project: Maven Shared Components > Issue Type: Improvement >Affects Versions: maven-archiver-3.2.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-archiver-3.2.0 > > > Upgrading to plexus-archiver 3.5 will require upgrade to JDK 7 minimum here. > See the > [changelog|https://github.com/codehaus-plexus/plexus-archiver/milestone/10?closed=1] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MSHARED-653) Upgrade to plexus-archiver 3.5
[ https://issues.apache.org/jira/browse/MSHARED-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-653. --- Resolution: Fixed Done in [r1804594|https://svn.apache.org/r1804594] > Upgrade to plexus-archiver 3.5 > -- > > Key: MSHARED-653 > URL: https://issues.apache.org/jira/browse/MSHARED-653 > Project: Maven Shared Components > Issue Type: Improvement >Affects Versions: maven-archiver-3.2.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-archiver-3.2.0 > > > Upgrading to plexus-archiver 3.5 will require upgrade to JDK 7 minimum here. > See the > [changelog|https://github.com/codehaus-plexus/plexus-archiver/milestone/10?closed=1] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MCOMPILER-302) Project doesn't compile with jdk7 (does with jdk8)
[
https://issues.apache.org/jira/browse/MCOMPILER-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120400#comment-16120400
]
Karl Heinz Marbaise edited comment on MCOMPILER-302 at 8/9/17 6:23 PM:
---
After taken a deeper look into that...I think I can explain the problem..
The issue is based on the generation of two command line option sets in the
case for JDK 7 which looks in debug output like this:
{code}
[DEBUG]
/Users/kama/.m2/repository/commons-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.jar
[DEBUG] /Users/kama/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar
[DEBUG] Source roots:
[DEBUG] /Users/kama/ws-git-maven-bugs/failingCompile/src/main/java
[DEBUG]
/Users/kama/ws-git-maven-bugs/failingCompile/target/generated-sources/annotations
[DEBUG] Command line options:
[DEBUG] -d /Users/kama/ws-git-maven-bugs/failingCompile/target/classes
-classpath .
[DEBUG] -d /Users/kama/ws-git-maven-bugs/failingCompile/target/classes
-classpath .
[DEBUG] incrementalBuildHelper#beforeRebuildExecution
[INFO] Compiling 1 source file to
/Users/kama/ws-git-maven-bugs/failingCompile/target/classes
[DEBUG] incrementalBuildHelper#afterRebuildExecution
[INFO]
[INFO] --- maven-resources-pl
{code}
which in the end causes an error of javac on command line:
{code}
javac: no source files
Usage: javac
use -help for a list of possible options
{code}
The first thing is that shouldn't happen and of course the failure output of
javac should somehow catched up and produce a useful error message for the
user...and not being silently ignored...
Using JDK 8 there is exactly a single line of command line options being
generated...
But the most important question is: Why does it produce two command line
options sets in JDK 7 whereas in JDK 8 it does not...
was (Author: khmarbaise):
After taken a deeper look into that...I think I can explain the problem..
The issue is based on the generation of two command line option sets in the
case for JDK 7 which looks in debug output like this:
{code}
[DEBUG]
/Users/kama/.m2/repository/commons-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.jar
[DEBUG] /Users/kama/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar
[DEBUG] Source roots:
[DEBUG] /Users/kama/ws-git-maven-bugs/failingCompile/src/main/java
[DEBUG]
/Users/kama/ws-git-maven-bugs/failingCompile/target/generated-sources/annotations
[DEBUG] Command line options:
[DEBUG] -d /Users/kama/ws-git-maven-bugs/failingCompile/target/classes
-classpath .
[DEBUG] -d /Users/kama/ws-git-maven-bugs/failingCompile/target/classes
-classpath .
[DEBUG] incrementalBuildHelper#beforeRebuildExecution
[INFO] Compiling 1 source file to
/Users/kama/ws-git-maven-bugs/failingCompile/target/classes
[DEBUG] incrementalBuildHelper#afterRebuildExecution
[INFO]
[INFO] --- maven-resources-pl
{code}
which in the end causes an error of javac on command line:
{code}
javac: no source files
Usage: javac
use -help for a list of possible options
{code}
The first thing is that shouldn't happen and of course the failure output of
javac should somehow catched up and produce a useful error message for the
user...and being silently ignored...
Using JDK 8 there is exactly a single line of command line options being
generated...
But the most important question is: Why does it produce two command line
options sets in JDK 7 whereas in JDK 8 it does not...
> Project doesn't compile with jdk7 (does with jdk8)
> --
>
> Key: MCOMPILER-302
> URL: https://issues.apache.org/jira/browse/MCOMPILER-302
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.2
> Environment: Windows 7
>Reporter: Sander Theetaert
> Labels: maven
> Attachments: failingCompile.zip
>
>
> When building attached project there are no .class files generated in the
> target/classes
> folder,
> this is a trimmed down example project but we do face this issue and can't
> use jdk8 for other reasons.
> At least a workaround would be nice...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-302) Project doesn't compile with jdk7 (does with jdk8)
[
https://issues.apache.org/jira/browse/MCOMPILER-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120400#comment-16120400
]
Karl Heinz Marbaise commented on MCOMPILER-302:
---
After taken a deeper look into that...I think I can explain the problem..
The issue is based on the generation of two command line option sets in the
case for JDK 7 which looks in debug output like this:
{code}
[DEBUG]
/Users/kama/.m2/repository/commons-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.jar
[DEBUG] /Users/kama/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar
[DEBUG] Source roots:
[DEBUG] /Users/kama/ws-git-maven-bugs/failingCompile/src/main/java
[DEBUG]
/Users/kama/ws-git-maven-bugs/failingCompile/target/generated-sources/annotations
[DEBUG] Command line options:
[DEBUG] -d /Users/kama/ws-git-maven-bugs/failingCompile/target/classes
-classpath .
[DEBUG] -d /Users/kama/ws-git-maven-bugs/failingCompile/target/classes
-classpath .
[DEBUG] incrementalBuildHelper#beforeRebuildExecution
[INFO] Compiling 1 source file to
/Users/kama/ws-git-maven-bugs/failingCompile/target/classes
[DEBUG] incrementalBuildHelper#afterRebuildExecution
[INFO]
[INFO] --- maven-resources-pl
{code}
which in the end causes an error of javac on command line:
{code}
javac: no source files
Usage: javac
use -help for a list of possible options
{code}
The first thing is that shouldn't happen and of course the failure output of
javac should somehow catched up and produce a useful error message for the
user...and being silently ignored...
Using JDK 8 there is exactly a single line of command line options being
generated...
But the most important question is: Why does it produce two command line
options sets in JDK 7 whereas in JDK 8 it does not...
> Project doesn't compile with jdk7 (does with jdk8)
> --
>
> Key: MCOMPILER-302
> URL: https://issues.apache.org/jira/browse/MCOMPILER-302
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.2
> Environment: Windows 7
>Reporter: Sander Theetaert
> Labels: maven
> Attachments: failingCompile.zip
>
>
> When building attached project there are no .class files generated in the
> target/classes
> folder,
> this is a trimmed down example project but we do face this issue and can't
> use jdk8 for other reasons.
> At least a workaround would be nice...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DOXIATOOLS-57) Figure not displayed in doxia-editor if relative path used
[
https://issues.apache.org/jira/browse/DOXIATOOLS-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120396#comment-16120396
]
Alix Lourme commented on DOXIATOOLS-57:
---
I can work on a patch, but after looking the code, no way to find where _File_
(or _String_) is managed for Figure display (SWT newbie touch) => if someone
has just a Class+line link, it will be appreciate ...
> Figure not displayed in doxia-editor if relative path used
> --
>
> Key: DOXIATOOLS-57
> URL: https://issues.apache.org/jira/browse/DOXIATOOLS-57
> Project: Maven Doxia Tools
> Issue Type: Bug
> Components: Doxia Eclipse Editor
>Affects Versions: doxia-eclipse-editor-1.0
>Reporter: Alix Lourme
>
> When a relative path is used for a
> [Figure|https://maven.apache.org/doxia/references/apt-format.html#Figure],
> the view tab doesn't display it.
> +Scenario+: In a project consider:
> # A _test.jpg_ picture
> # A _test.apt_ file with:
> {code}
> Test
> This is a test of figure:
>
> [test.jpg] test
> {code}
> The result of display is a black cross.
> If the path is absolute, the picture is displayed.
> In addition of managing the relative path, it could be nice to manage the
> classic Maven site directories (apt &
> [resources|https://maven.apache.org/guides/mini/guide-site.html#Adding_Extra_Resources]).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DOXIATOOLS-46) Workspace indisposed after file rename
[ https://issues.apache.org/jira/browse/DOXIATOOLS-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alix Lourme updated DOXIATOOLS-46: -- Flags: Patch > Workspace indisposed after file rename > -- > > Key: DOXIATOOLS-46 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-46 > Project: Maven Doxia Tools > Issue Type: Bug > Components: Doxia Eclipse Editor > Environment: Eclipse Kepler 4.3.2 > Doxia Editors Feature 1.0.0.201301041016 >Reporter: Alix Lourme >Priority: Blocker > Attachments: DOXIATOOLS-46-doxia-ide.patch, loop.log > > > +Synthesis+ : When a file opened by plugin is renamed, plugin is indisposed > and crash the workspace (because try to reopen it after Eclipse kill/restart). > +Use Case+ : > # Create a workspace and a project _Test_ > # Create file _index.apt_ with a title (the file is opened by plugin) > # Rename file (F2 key) : _index2.apt_ > # Error appears : _Resource '/Test/index.apt' does not exist._ > # +Informations+ : > * File is renamed (on filesystem) > * Sheet title of plugin is *index2.apt* but on mouse over shows *index.apt* > * The sheet is not closable > * Eclipse must be killed > * Error _Unhandled event loop exception_ appears in log > +Root cause hypothesis+ : Infinite loop in > _org.apache.maven.doxia.ide.eclipse.common.ui.editors.AbstractMultiPageEditorPart.isSaveAsAllowed(AbstractMultiPageEditorPart.java:231)_ > (cf. [^loop.log]) > +Workaround+ : Recreate the file ... because plugin try to open renamed file > during start => same error below. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MCOMPILER-302) Project doesn't compile with jdk7 (does with jdk8)
[
https://issues.apache.org/jira/browse/MCOMPILER-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120279#comment-16120279
]
Robert Scholte commented on MCOMPILER-302:
--
I can reproduce the issue with Java 7 and Java 8, though have no explanation
for it yet. But when I remove the {{org.eclipse.birt.runtime}} dependency it
compiles fine.
With Java 9-ea it compiles as expected.
It might be related to the huge number of dependencies (do you really need them
all?), although that should not be an issue.
> Project doesn't compile with jdk7 (does with jdk8)
> --
>
> Key: MCOMPILER-302
> URL: https://issues.apache.org/jira/browse/MCOMPILER-302
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.2
> Environment: Windows 7
>Reporter: Sander Theetaert
> Labels: maven
> Attachments: failingCompile.zip
>
>
> When building attached project there are no .class files generated in the
> target/classes
> folder,
> this is a trimmed down example project but we do face this issue and can't
> use jdk8 for other reasons.
> At least a workaround would be nice...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6220) Add CLI options to control color output
[
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120222#comment-16120222
]
ASF GitHub Bot commented on MNG-6220:
-
Github user rfscholte commented on the issue:
https://github.com/apache/maven/pull/114
Here's my proposal:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=fd57754218e749305be1dd745fda9407960cf985
> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
> Issue Type: New Feature
>Reporter: Manuel Ryan
> Fix For: 3.5.1-candidate
>
>
> Currently, the only way to enable/disable color output is to use the
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment
> with the ansicolor plugin), there is no CLI option combination to support the
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MASSEMBLY-866) poor performance of jar-with-dependencies when run in same run as docbook
[
https://issues.apache.org/jira/browse/MASSEMBLY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120192#comment-16120192
]
John Vines commented on MASSEMBLY-866:
--
Maven - seen on both 3.3.9 and 3.5.0
JDK - Openjdk 1.7.0.141, oracle 1.7.0_75, oracle 1.7.0_67
Yes, we are doing a maven job in jenkins
Running test with 2.6 now ( will also run test with those overrides, wasn't
sure if I could override plugins like that)
228M
Which flags would you like?
> poor performance of jar-with-dependencies when run in same run as docbook
> -
>
> Key: MASSEMBLY-866
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-866
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: John Vines
> Labels: performance
>
> I apologize for the lack of information, but we have a large build
> environment which I cannot share, but I'll try to explain things as best I
> can.
> In our full build path, we have 2 components that I've found have side
> effects. One is a doc build which uses the docbkx-maven-plugin
> (https://github.com/mimil/docbkx-tools) to generate documentation (and
> usually takes a while, ~27 minutes) and another which builds a
> jar-with-depends for our UI. Prior to upgrade the assembly plugin to 3.0.0
> from 2.3 or 2.5 (I cannot recall) everything ran fine. After upgrading we
> found our jenkins builds taking about 40 more minutes, most of this change
> was in maven-assembly-plugin for that UI jar-with-dependencies
> {code}assembly-plugin:3.0.0:single (make-assembly) @ sqrrl-web-dist-ui ---
> 16:17:37 [INFO] Reading assembly descriptor: src/main/assembly/dist-ui.xml
> 16:17:40 [INFO] Building jar:
> /var/lib/jenkins/workspace/sqrrl-master-build/web/dist-ui/target/sqrrl-web-dist-ui-2.8.0-SNAPSHOT-jar-with-dependencies.jar
> 17:01:54 [INFO] {code}
> Eventually I isolated to a case where just that doc and that jar-with-deps
> being built would cause the jar-with-deps to take ~40 minutes, but if I built
> it by itself (all other maven options being equal) it would take about 1.5
> minutes.
> I'm honestly not too familiar with the inner workings of this plugin, nor the
> maven docbook plugin, but my hunch was that the docbook plugin was
> 'corrupting' or otherwise altering the main maven jvm in such a way to cause
> this. It does use some really old plexus plugins, among others, afterall.
> However, I stumbled across MASSEMBLY-424 and tested forking
> maven-assembly-plugin:3.0.0 and updating plexus-archiver to 3.5, plexus-io to
> 3.0.0 and plexus-utils to 3.1.0 and ran my 2 module build with the custom
> plugin and it ran just as quick as being run standalone (1.5minutes). (To
> build it with those plugins I had to disable checkstyle and enforcer though
> since at least one of those plugins versions was java7)
> One last datapoint is that in our jar-with-deps we are including
> bouncycastle's bcpix and bcprov and explicitly excluding them from the
> jar-with-depends also made that 2 module build faster (but not as fast), so
> I'm not 100% sure it's the docbook plugin was the catalyst there.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MRELEASE-827) Passing "-pl" via arguments is not accepted
[
https://issues.apache.org/jira/browse/MRELEASE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118391#comment-16118391
]
Dennis Kieselhorst edited comment on MRELEASE-827 at 8/9/17 3:07 PM:
-
forked-path works fine with pl argument.
was (Author: deki):
Just stumbled about this issue. What is your workaround for it? Define profiles
and skip maven-deploy-plugin?
> Passing "-pl" via arguments is not accepted
> ---
>
> Key: MRELEASE-827
> URL: https://issues.apache.org/jira/browse/MRELEASE-827
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.4
>Reporter: Konrad Windszus
>
> If I try to pass on a "-pl" to the forked Maven via arguments, I get the
> following exception:
> Failed to re-parse additional arguments for Maven
> {noformat}
> Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
> project testproject: Failed to re-parse additional arguments for Maven
> invocation.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:100)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:66)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to re-parse
> additional arguments for Maven invocation.
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:281)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:232)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Failed
> to re-parse additional arguments for Maven invocation.
> at
> org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:89)
> at
> org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:44)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:234)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:169)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:146)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:107)
> at
>
[jira] [Commented] (MNG-6220) Add CLI options to control color output
[
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119983#comment-16119983
]
ASF GitHub Bot commented on MNG-6220:
-
Github user michael-o commented on the issue:
https://github.com/apache/maven/pull/114
I don't might to pick this up, but it won't happen before Sep for personal
priorities.
> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
> Issue Type: New Feature
>Reporter: Manuel Ryan
> Fix For: 3.5.1-candidate
>
>
> Currently, the only way to enable/disable color output is to use the
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment
> with the ansicolor plugin), there is no CLI option combination to support the
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6220) Add CLI options to control color output
[
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119937#comment-16119937
]
ASF GitHub Bot commented on MNG-6220:
-
Github user mryan43 commented on the issue:
https://github.com/apache/maven/pull/114
I feel stuck until someone with more experience of the maven code base
update the version of maven-shared-utils to 3.2.1-SNAPSHOT on the default
branch, anyone up to the task ?
> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
> Issue Type: New Feature
>Reporter: Manuel Ryan
> Fix For: 3.5.1-candidate
>
>
> Currently, the only way to enable/disable color output is to use the
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment
> with the ansicolor plugin), there is no CLI option combination to support the
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MCOMPILER-302) Project doesn't compile with jdk7 (does with jdk8)
Sander Theetaert created MCOMPILER-302: -- Summary: Project doesn't compile with jdk7 (does with jdk8) Key: MCOMPILER-302 URL: https://issues.apache.org/jira/browse/MCOMPILER-302 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 3.6.2 Environment: Windows 7 Reporter: Sander Theetaert Attachments: failingCompile.zip When building attached project there are no .class files generated in the target/classes folder, this is a trimmed down example project but we do face this issue and can't use jdk8 for other reasons. At least a workaround would be nice... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MCOMPILER-302) Project doesn't compile with jdk7 (does with jdk8)
[ https://issues.apache.org/jira/browse/MCOMPILER-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119921#comment-16119921 ] Sander Theetaert commented on MCOMPILER-302: maven 3.3.9 suffers from this issue > Project doesn't compile with jdk7 (does with jdk8) > -- > > Key: MCOMPILER-302 > URL: https://issues.apache.org/jira/browse/MCOMPILER-302 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.6.2 > Environment: Windows 7 >Reporter: Sander Theetaert > Labels: maven > Attachments: failingCompile.zip > > > When building attached project there are no .class files generated in the > target/classes > folder, > this is a trimmed down example project but we do face this issue and can't > use jdk8 for other reasons. > At least a workaround would be nice... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6220) Add CLI options to control color output
[
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119875#comment-16119875
]
Yves Schumann commented on MNG-6220:
Fixing this issue with the next Maven version would be really great. I'm having
developers asking for colored output on the Jenkins builds nearly every day...
> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
> Issue Type: New Feature
>Reporter: Manuel Ryan
> Fix For: 3.5.1-candidate
>
>
> Currently, the only way to enable/disable color output is to use the
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment
> with the ansicolor plugin), there is no CLI option combination to support the
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (WAGON-488) Upgrade WebDAV Wagon to a more recent HttpClient version (4.5.3)
[ https://issues.apache.org/jira/browse/WAGON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) updated WAGON-488: - Summary: Upgrade WebDAV Wagon to a more recent HttpClient version (4.5.3) (was: Upgrade WebDAV Wagon to a more recent HttpClient version) > Upgrade WebDAV Wagon to a more recent HttpClient version (4.5.3) > > > Key: WAGON-488 > URL: https://issues.apache.org/jira/browse/WAGON-488 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-webdav >Affects Versions: 2.12 >Reporter: Olivier Lamy (*$^¨%`£) >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (WAGON-489) Java 7 required
[ https://issues.apache.org/jira/browse/WAGON-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) updated WAGON-489: - Issue Type: Improvement (was: Bug) > Java 7 required > --- > > Key: WAGON-489 > URL: https://issues.apache.org/jira/browse/WAGON-489 > Project: Maven Wagon > Issue Type: Improvement >Reporter: Olivier Lamy (*$^¨%`£) >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: 3.0.0 > > > for the record and make [~michael-o] happy :P -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1383) dependenciesToScan Does Not Leverage Classpath Elements
[ https://issues.apache.org/jira/browse/SUREFIRE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119679#comment-16119679 ] ASF GitHub Bot commented on SUREFIRE-1383: -- Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/157 @owenfarrell I have not had yet. I am reviewing other in parallel. I will have a look in few days. > dependenciesToScan Does Not Leverage Classpath Elements > > > Key: SUREFIRE-1383 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1383 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 >Reporter: Owen Farrell > Fix For: Backlog > > Attachments: scanned-dependencies-sample.zip > > > The configuration attribute relies solely on installed > artifacts. This is an issue when the targeted dependencies were built as part > of the current session. The net result is that stale artifacts are used (i.e. > if the dependency has changed since it was last installed) or the tests are > not executed at all (if the dependency has not been previously installed. > Attached is a sample project that illustrates this issue: > Given I have a multi-module project >And the first module built includes test classes as part of the project > artifact >And subsequent modules scan the first for unit tests to execute > When I execute the _*test*_ goal (prior to any install) > Then the build should succeed >And tests should be executed with each module -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MNG-6271) pom with parent and variable in repository url fails
Peter Lord created MNG-6271:
---
Summary: pom with parent and variable in repository url fails
Key: MNG-6271
URL: https://issues.apache.org/jira/browse/MNG-6271
Project: Maven
Issue Type: Bug
Reporter: Peter Lord
With the following pom.xml :
{code}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
com.company
project
1.0.0
hello world
/Users/plord/repo
com.company
parent
10.2.0-SNAPSHOT
repo
file://${x}/sdk/maven/repo
{code}
maven fails to resolve the variable before attempting to download the parent.
Output includes :
{code}
$ mvn install
[INFO] Scanning for projects...
Downloading:
file://${x}/sdk/maven/repo/com/company/parent/10.2.0-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
com.company:parent:10.2.0-SNAPSHOT/maven-metadata.xml from/to repo
(file://${x}/sdk/maven/repo): Repository path /sdk/maven/repo does not exist,
and cannot be created.
Downloading:
file://${x}/sdk/maven/repo/com/company/parent/10.2.0-SNAPSHOT/parent-10.2.0-SNAPSHOT.pom
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for com.company:project:1.0.0: Could not
transfer artifact com.company:parent:pom:10.2.0-SNAPSHOT from/to repo
(file://${x}/sdk/maven/repo): Repository path /sdk/maven/repo does not exist,
and cannot be created. and 'parent.relativePath' points at wrong local POM @
line 16, column 13
@
{code}
The same is true if the variable is from the environment or system property.
Maven should resolve variables before attempting to download parent pom.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
