[jira] [Commented] (MINVOKER-219) Change default value for cloneProjectsTo and cloneClean
[
https://issues.apache.org/jira/browse/MINVOKER-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115272#comment-16115272
]
Phillip Webb commented on MINVOKER-219:
---
This change has unfortunately broken the ability to bypass cloning. See
[MINVOKER-224|https://issues.apache.org/jira/browse/MINVOKER-224] for details.
> Change default value for cloneProjectsTo and cloneClean
> ---
>
> Key: MINVOKER-219
> URL: https://issues.apache.org/jira/browse/MINVOKER-219
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.0
>
>
> Up until now {{cloneProjectsTo}} is never set, which means that by default
> the source-directory gets polluted with the IT test execution.
> You often see this parameter is set to {{target/its}}, so let's use that as
> the new default.
> To ensure the IT output-folder is in the correct state, it is also better the
> set {{cloneClean}} to {{true}} by default. This is more efficient compared to
> {{mvn clean}} because only a subset of the folders are cleaned.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MINVOKER-224) Unable to set cloneProjectsTo to null
Phillip Webb created MINVOKER-224:
-
Summary: Unable to set cloneProjectsTo to null
Key: MINVOKER-224
URL: https://issues.apache.org/jira/browse/MINVOKER-224
Project: Maven Invoker Plugin
Issue Type: Bug
Reporter: Phillip Webb
[MINVOKER-219|https://issues.apache.org/jira/browse/MINVOKER-219] changed the
default value of {{cloneProjectsTo}} to {{target/its}}. This change
unfortunately now makes it impossible to have a {{null}} value, meaning that
in-place invocation is no longer supported. From the Javadoc:
{quote}Directory to which projects should be cloned prior to execution. If set
to null, each integration test will be run in the directory in which the
corresponding IT POM was found. In this case, you most likely want to configure
your SCM to ignore target and build.log in the test's base directory.{quote}
Is it possible to revert this change, or to provide a alternative property to
allow cloning to be skipped?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[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=16115255#comment-16115255 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user jon-bell commented on the issue: https://github.com/apache/maven-surefire/pull/161 @Tibor17 It seems like it had worked for me because I had previously executed a `mvn install` - I see on a clean maven repo the problem. It looks like the `SurefireLauncher` does not unpack/install the parent pom into the `it-repo`, and hence, the forked maven process can't find the parent pom (once it's installed). I am hesitant to poke at this further, because I suspect a fix might involve some changes to `SurefireLauncher` to coerce it to install the parent pom into the `it-repo` as well. This seems to not be a problem for any test packages, but is for a provider (which gets the forked Maven classloader instead of the test classloader). Given that the only other provider in the repo for integration tests *does not* reference the parent pom, I assume that this is a problem that someone came upon before and sidestepped. I've removed the parent reference that you had suggested above. But, we are properly picking up `surefire.version` from the maven system property. On a clean maven repo the `mvn clean install -P run-its` completed with this version (now again squashed). I agree that referencing the parent pom is a cleaner solution, but I'm not sure if you/we want to go down the road of patching the integration test harness to support that (for what amounted to a ~3 line patch). > 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] (MSHADE-242) Plugin does not work with Java 9
[
https://issues.apache.org/jira/browse/MSHADE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114843#comment-16114843
]
Robert Scholte commented on MSHADE-242:
---
So we're one step closer. First jdependency needs to do some stuff before we
can upgrade.
> Plugin does not work with Java 9
>
>
> Key: MSHADE-242
> URL: https://issues.apache.org/jira/browse/MSHADE-242
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
> Environment: ╰─✘ java -version
> openjdk version "9-internal"
> OpenJDK Runtime Environment (build 9-internal+0-2016-11-17-101644.norman.jdk9)
> OpenJDK 64-Bit Server VM (build 9-internal+0-2016-11-17-101644.norman.jdk9,
> mixed mode)
>Reporter: Norman Maurer
>
> When trying to use the shade plugin with java9 I get:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (default) on project
> netty-common: Error creating shaded jar: null: IllegalArgumentException ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (default) on
> project netty-common: Error creating shaded jar: null
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> 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:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:537)
> 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: Error creating
> shaded jar: null
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:540)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 20 more
> Caused by: java.lang.IllegalArgumentException
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.vafer.jdependency.Clazzpath.addClazzpathUnit(Clazzpath.java:201)
> at org.vafer.jdependency.Clazzpath.addClazzpathUnit(Clazzpath.java:132)
> at
> org.apache.maven.plugins.shade.filter.MinijarFilter.(MinijarFilter.java:94)
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.getFilters(ShadeMojo.java:814)
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:446)
> ... 22 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MSHADE-242) Plugin does not work with Java 9
[
https://issues.apache.org/jira/browse/MSHADE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114784#comment-16114784
]
Vincent Privat commented on MSHADE-242:
---
and now available on Maven Central:
http://repo1.maven.org/maven2/org/ow2/asm/asm/6.0_BETA/
> Plugin does not work with Java 9
>
>
> Key: MSHADE-242
> URL: https://issues.apache.org/jira/browse/MSHADE-242
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
> Environment: ╰─✘ java -version
> openjdk version "9-internal"
> OpenJDK Runtime Environment (build 9-internal+0-2016-11-17-101644.norman.jdk9)
> OpenJDK 64-Bit Server VM (build 9-internal+0-2016-11-17-101644.norman.jdk9,
> mixed mode)
>Reporter: Norman Maurer
>
> When trying to use the shade plugin with java9 I get:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (default) on project
> netty-common: Error creating shaded jar: null: IllegalArgumentException ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (default) on
> project netty-common: Error creating shaded jar: null
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> 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:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:537)
> 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: Error creating
> shaded jar: null
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:540)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 20 more
> Caused by: java.lang.IllegalArgumentException
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.vafer.jdependency.Clazzpath.addClazzpathUnit(Clazzpath.java:201)
> at org.vafer.jdependency.Clazzpath.addClazzpathUnit(Clazzpath.java:132)
> at
> org.apache.maven.plugins.shade.filter.MinijarFilter.(MinijarFilter.java:94)
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.getFilters(ShadeMojo.java:814)
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:446)
> ... 22 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MDEP-579) Regression: get goal does not pass server credentials to BasicRepositoryConnector
Richard W. Eggert II created MDEP-579:
-
Summary: Regression: get goal does not pass server credentials to
BasicRepositoryConnector
Key: MDEP-579
URL: https://issues.apache.org/jira/browse/MDEP-579
Project: Maven Dependency Plugin
Issue Type: Bug
Components: get
Affects Versions: 3.0.1, 3.0.0
Reporter: Richard W. Eggert II
Priority: Critical
The {{get}} goal does not pass the server credentials from {{settings.xml}} to
the {{BasicRepositoryConnector}} in version 3.0.1 (and, presumably 3.0.0),
resulting in {{NotAuthorized}} errors when resolving artifacts against
repositories that require authentication. It works correctly in version 2.9.
Background: I discovered this in the course of debugging a Jenkins job in which
I'm using the {{get}} and {{copy}} goals from the command line (with no POM) to
download artifacts to deploy. After spending several hours thinking that
Jenkins was not properly configuring {{settings.xml}}, I noticed from the Maven
debug output that the credentials were being passed when resolving the
maven-dependency-plugin and its dependencies, but not being passed when
resolving the artifact I requested. On a hunch I downgraded from
maven-dependency-plugin version 3.0.1 to 2.9, and suddenly everything magically
worked.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MDEP-578) Add message in case module name cannot be extracted from jar.
[ https://issues.apache.org/jira/browse/MDEP-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEP-578. --- Resolution: Fixed Fixed in [r1804137|http://svn.apache.org/viewvc?rev=1804137=rev] > Add message in case module name cannot be extracted from jar. > - > > Key: MDEP-578 > URL: https://issues.apache.org/jira/browse/MDEP-578 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: resolve >Affects Versions: 3.0.1 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 3.0.2 > > > The following jars are just some examples where Java 9 cannot give an > automatic module name: > || jar || root cause || > | geronimo-servlet_2.4_spec-1.1.1.jar | geronimo.servlet.2.4.spec: Invalid > module name: '2' is not a Java identifier | > | jdom-1.0.jar | JDOMAbout$Author.class found in top-level directory (unnamed > package not allowed in module) | > | geronimo-jta_1.1_spec-1.1.jar | geronimo.jta.1.1.spec: Invalid module name: > '1' is not a Java identifier | > Who would have expected that reason for jdom? A message would help a lot > (even though in the end it means you can still not refer to it) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MDEP-578) Add message in case module name cannot be extracted from jar.
Robert Scholte created MDEP-578: --- Summary: Add message in case module name cannot be extracted from jar. Key: MDEP-578 URL: https://issues.apache.org/jira/browse/MDEP-578 Project: Maven Dependency Plugin Issue Type: Improvement Components: resolve Affects Versions: 3.0.1 Reporter: Robert Scholte Assignee: Robert Scholte Fix For: 3.0.2 The following jars are just some examples where Java 9 cannot give an automatic module name: || jar || root cause || | geronimo-servlet_2.4_spec-1.1.1.jar | geronimo.servlet.2.4.spec: Invalid module name: '2' is not a Java identifier | | jdom-1.0.jar | JDOMAbout$Author.class found in top-level directory (unnamed package not allowed in module) | | geronimo-jta_1.1_spec-1.1.jar | geronimo.jta.1.1.spec: Invalid module name: '1' is not a Java identifier | Who would have expected that reason for jdom? A message would help a lot (even though in the end it means you can still not refer to it) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MRELEASE-911) release plugin forming incorrect git clone command
[
https://issues.apache.org/jira/browse/MRELEASE-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114323#comment-16114323
]
Med Reda commented on MRELEASE-911:
---
yes but dosn't work for me so i use release:prepare release:perform and i use
a script to create Release branche from a created tag.
thanks
> release plugin forming incorrect git clone command
> --
>
> Key: MRELEASE-911
> URL: https://issues.apache.org/jira/browse/MRELEASE-911
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.5.2
>Reporter: sandyzden
>
> git-exe plugin completely ignores the branch parameter and fails in cloning
> the repository during {{release:perform}}
> e.g. git clone --branch this causes it to determine
> the as the branch parameter and failing.
> Below is the error message
> {noformat}
> [ERROR] The git-clone command failed.
> [ERROR] fatal: repository '/target/checkout' does not exist
> {noformat}
> A bit fiddling on the source code i found out
> {code}
> if ( version != null && ( version instanceof ScmBranch ) )
> {
> cl.createArg().setValue( "--branch" );
> cl.createArg().setValue( version.getName() );
> }
> {code}
> it needed version number, but i was not able to figure how it passed from
> Main Mojo to this class
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6148) Can't package and assemble with JDK9/Jigsaw
[ https://issues.apache.org/jira/browse/MNG-6148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114128#comment-16114128 ] Robert Scholte commented on MNG-6148: - I seems like the version used for maven-jar-plugin (2.4) is not suffering. In the meantime the value of java.version has changed (from 9-ea to 9), so maybe that explains it. So it is not required, but probably wise to upgrade. > Can't package and assemble with JDK9/Jigsaw > --- > > Key: MNG-6148 > URL: https://issues.apache.org/jira/browse/MNG-6148 > Project: Maven > Issue Type: Bug >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.5.1-candidate > > > Rootcause is project verona: Here are the related plugins with their fixed > versions: > * maven-assembly-plugin:3.0.0 > * maven-jar-plugin:3.0.0 > * maven-javadoc-plugin:2.10.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
