[jira] [Commented] (MNG-7914) Provide a single entry point for configuration
[
https://issues.apache.org/jira/browse/MNG-7914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863092#comment-17863092
]
ASF GitHub Bot commented on MNG-7914:
-
gnodet opened a new pull request, #1595:
URL: https://github.com/apache/maven/pull/1595
(no comment)
> Provide a single entry point for configuration
> --
>
> Key: MNG-7914
> URL: https://issues.apache.org/jira/browse/MNG-7914
> Project: Maven
> Issue Type: New Feature
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> Looking at MNG-7772, this should not require any code change, but it's all
> about configuration.
> I propose to load / interpolate the following files:
> * {{${maven.home}/conf/maven.user.properties}}
> * {{${maven.home}/conf/maven.system.properties}}
> Those files would be used to load additional user properties and system
> properties for Maven. In addition to the simple interpolation mechanism, we
> should provide two enhancements using special keys {{{}$\{includes{ and
> {{{}$\{optionals{ which would be used to load additional referenced
> configuration files such as:
> {{ ${optionals} = ${user.home}/.m2/maven.user.properties,
> ${session.rootDirectory}/.mvn/maven.user.properties}}
> Being loaded early when Maven is loaded, those files could reference
> directories to load extensions from:
> {{{}maven.core.extensions.directories =
> ${session.rootDirectory}/.mvn/extensions.xml,{}}}{{{}${user.home}/.m2/extensions.xml,${maven.home}/extensions.xml{}}}
>
> In various places, the maven code could be simplified and offer more
> configuration points at the same time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8174) DefaultModelBuilder throws a NPE on self-referencing property
Henrik Rueping created MNG-8174:
---
Summary: DefaultModelBuilder throws a NPE on self-referencing
property
Key: MNG-8174
URL: https://issues.apache.org/jira/browse/MNG-8174
Project: Maven
Issue Type: Bug
Affects Versions: 3.9.8, 3.9.5
Reporter: Henrik Rueping
The method org.apache.maven.model.building.DefaultModelBuilder.build(...)
throws a Null-Pointer Exception when trying to resolve a pom with a
self-referencing property, e.g.
{code:xml}
${prop}
{code}
A (rather) minimal example can be found at
[https://github.com/HenrikRueping/pom-property-resolution-test]
The stacktrace is
{code:java}
java.lang.NullPointerException: Attribute value can not be null
at org.codehaus.plexus.util.xml.Xpp3Dom.setAttribute(Xpp3Dom.java:208)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit(StringVisitorModelInterpolator.java:725)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit(StringVisitorModelInterpolator.java:730)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit(StringVisitorModelInterpolator.java:730)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit(StringVisitorModelInterpolator.java:730)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit(StringVisitorModelInterpolator.java:730)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit(StringVisitorModelInterpolator.java:693)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit(StringVisitorModelInterpolator.java:674)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit(StringVisitorModelInterpolator.java:524)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit(StringVisitorModelInterpolator.java:571)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit(StringVisitorModelInterpolator.java:232)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator.interpolateModel(StringVisitorModelInterpolator.java:101)
at
org.apache.maven.model.building.DefaultModelBuilder.interpolateModel(DefaultModelBuilder.java:770)
at
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:385)
at
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:247)
{code}
It seems like the cause is that Xpp3Dom.setAttribute does not accept null
values,
but the interpolate Method
in org.apache.maven.model.interpolation.StringVisitorModelInterpolator returns
null on a self-referencing property.
My Expectation would be that in such a case either a ModelBuildingException is
thrown, or it behaves like in the usual case of an undefined property, e.g. the
string "${prop}" is in the parsed model.
Maybe it is a good idea to add for each test case with an undefined property an
analogous test case with a self-referencing property.
In Eclipse this Exception is still thrown when editing a pom with a
self-referencing property.
I would say this is a minor issue, currently I can simply catch the
NullPointerException hoping that there are no other causes for a
NullPointerException.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MINVOKER-339) Don't print or log the plugin's stack trace on verification fail
[
https://issues.apache.org/jira/browse/MINVOKER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863014#comment-17863014
]
Elliotte Rusty Harold commented on MINVOKER-339:
Let me dig up an example project, but command line arguments don't resolve
this. No matter what arguments are set, there is no reason to dump the stack
from the maven-invoker-plugin's own code. That's not what failed. Do we dump
the maven-comnpiler-plugin's stack because there was a syntax error? (I was
about to say of course not, but I really should check that we don't. I hope we
don't. That would be a similar bug if we do.)
> Don't print or log the plugin's stack trace on verification fail
>
>
> Key: MINVOKER-339
> URL: https://issues.apache.org/jira/browse/MINVOKER-339
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Typical output on a failing IT. The stack trace is unhelpful and pointless
> log junk. It does not point to the actual failing test, why and how it
> failed, or its output (which is in fact not included and should be, but
> that's a separate issue.) Instead all it shows is a stack trace of the code
> from Maven and the maven-invoker-plugin that ran the code. This is *not* the
> failing code. This is only the code that invoked the failing code, and this
> code executed successfully.
> This code did not fail and is not the cause of the bug, nor is it helpful in
> diagnosing the bug. The maven-invoker plugin executed successfully and
> correctly detected a failing integration test. Its stack trace simply
> obscures the real problem and gets in the way of the developer. Don't print
> it.
> {{*** end build.log for: verify-fail/pom.xml ***
> Error: -
> Error:
> [INFO] -
> [INFO] Build Summary:
> [INFO] Passed: 8, Failed: 1, Errors: 0, Skipped: 0
> [INFO] -
> Error: The following builds failed:
> Error: * verify-fail/pom.xml
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 53.844 s
> [INFO] Finished at: 2023-06-03T10:58:12Z
> [INFO]
>
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-invoker-plugin:3.3.0:verify (integration-test)
> on project maven-jarsigner-plugin: 1 build failed. See console output above
> for details. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-invoker-plugin:3.3.0:verify
> (integration-test) on project maven-jarsigner-plugin: 1 build failed. See
> console output above for details.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:375)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:351)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:171)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:163)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:298)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.
[jira] [Commented] (MNG-8173) -Dpackaging= is ignored when using mvn deploy:deploy-file
[
https://issues.apache.org/jira/browse/MNG-8173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863013#comment-17863013
]
Lars Schmertmann commented on MNG-8173:
---
In the first step I only tested the versions available in
https://gitlab.archlinux.org/archlinux/packaging/packages/maven/-/commits/main
Using 3.8.8 and 3.9.0 binaries from
https://archive.apache.org/dist/maven/maven-3/ has the follwing result:
* 3.8.8: Works
* 3.9.0: Broken
> -Dpackaging= is ignored when using mvn deploy:deploy-file
> -
>
> Key: MNG-8173
> URL: https://issues.apache.org/jira/browse/MNG-8173
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Deployment
>Affects Versions: 3.9.6, 3.9.7, 3.9.8
> Environment: Archlinux
>Reporter: Lars Schmertmann
>Priority: Major
>
> We have a project where we deploy the following files:
> {code}
> ausweisapp-2.2.0.aar
> ausweisapp-2.2.0.aar.asc
> ausweisapp-2.2.0.pom
> ausweisapp-2.2.0.pom.asc
> ausweisapp-2.2.0-sources.jar
> ausweisapp-2.2.0-sources.jar.asc
> {code}
> We are using the following commands:
> {code}
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.aar
> -DpomFile=ausweisapp-2.2.0.pom -Dsources=ausweisapp-2.2.0-sources.jar
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.aar.asc
> -Dpackaging=aar.asc -Dclassifier= -DpomFile=ausweisapp-2.2.0.pom
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.pom.asc
> -Dpackaging=pom.asc -Dclassifier= -DpomFile=ausweisapp-2.2.0.pom
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0-sources.jar.asc
> -Dpackaging=jar.asc -Dclassifier=sources -DpomFile=ausweisapp-2.2.0.pom
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> {code}
> With 3.8.7 everythings works fine. But at least with 3.9.6 - 3.9.8
> `-Dpackaging=` is ignored.
> This leads to the following renames during deployment and the signature check
> fails:
> {code}
> ausweisapp-2.2.0.aar.asc -> ausweisapp-2.2.0.asc
> ausweisapp-2.2.0.pom.asc -> ausweisapp-2.2.0.asc
> ausweisapp-2.2.0-sources.jar.asc -> ausweisapp-2.2.0-sources.asc
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8173) -Dpackaging= is ignored when using mvn deploy:deploy-file
[
https://issues.apache.org/jira/browse/MNG-8173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863004#comment-17863004
]
Slawomir Jaranowski commented on MNG-8173:
--
is it caused by: MDEPLOY-311 ?
> -Dpackaging= is ignored when using mvn deploy:deploy-file
> -
>
> Key: MNG-8173
> URL: https://issues.apache.org/jira/browse/MNG-8173
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Deployment
>Affects Versions: 3.9.6, 3.9.7, 3.9.8
> Environment: Archlinux
>Reporter: Lars Schmertmann
>Priority: Major
>
> We have a project where we deploy the following files:
> {code}
> ausweisapp-2.2.0.aar
> ausweisapp-2.2.0.aar.asc
> ausweisapp-2.2.0.pom
> ausweisapp-2.2.0.pom.asc
> ausweisapp-2.2.0-sources.jar
> ausweisapp-2.2.0-sources.jar.asc
> {code}
> We are using the following commands:
> {code}
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.aar
> -DpomFile=ausweisapp-2.2.0.pom -Dsources=ausweisapp-2.2.0-sources.jar
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.aar.asc
> -Dpackaging=aar.asc -Dclassifier= -DpomFile=ausweisapp-2.2.0.pom
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.pom.asc
> -Dpackaging=pom.asc -Dclassifier= -DpomFile=ausweisapp-2.2.0.pom
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0-sources.jar.asc
> -Dpackaging=jar.asc -Dclassifier=sources -DpomFile=ausweisapp-2.2.0.pom
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> {code}
> With 3.8.7 everythings works fine. But at least with 3.9.6 - 3.9.8
> `-Dpackaging=` is ignored.
> This leads to the following renames during deployment and the signature check
> fails:
> {code}
> ausweisapp-2.2.0.aar.asc -> ausweisapp-2.2.0.asc
> ausweisapp-2.2.0.pom.asc -> ausweisapp-2.2.0.asc
> ausweisapp-2.2.0-sources.jar.asc -> ausweisapp-2.2.0-sources.asc
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8173) -Dpackaging= is ignored when using mvn deploy:deploy-file
[
https://issues.apache.org/jira/browse/MNG-8173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863003#comment-17863003
]
Michael Osipov commented on MNG-8173:
-
Does 3.8.8 work as well?
> -Dpackaging= is ignored when using mvn deploy:deploy-file
> -
>
> Key: MNG-8173
> URL: https://issues.apache.org/jira/browse/MNG-8173
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Deployment
>Affects Versions: 3.9.6, 3.9.7, 3.9.8
> Environment: Archlinux
>Reporter: Lars Schmertmann
>Priority: Major
>
> We have a project where we deploy the following files:
> {code}
> ausweisapp-2.2.0.aar
> ausweisapp-2.2.0.aar.asc
> ausweisapp-2.2.0.pom
> ausweisapp-2.2.0.pom.asc
> ausweisapp-2.2.0-sources.jar
> ausweisapp-2.2.0-sources.jar.asc
> {code}
> We are using the following commands:
> {code}
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.aar
> -DpomFile=ausweisapp-2.2.0.pom -Dsources=ausweisapp-2.2.0-sources.jar
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.aar.asc
> -Dpackaging=aar.asc -Dclassifier= -DpomFile=ausweisapp-2.2.0.pom
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.pom.asc
> -Dpackaging=pom.asc -Dclassifier= -DpomFile=ausweisapp-2.2.0.pom
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0-sources.jar.asc
> -Dpackaging=jar.asc -Dclassifier=sources -DpomFile=ausweisapp-2.2.0.pom
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> {code}
> With 3.8.7 everythings works fine. But at least with 3.9.6 - 3.9.8
> `-Dpackaging=` is ignored.
> This leads to the following renames during deployment and the signature check
> fails:
> {code}
> ausweisapp-2.2.0.aar.asc -> ausweisapp-2.2.0.asc
> ausweisapp-2.2.0.pom.asc -> ausweisapp-2.2.0.asc
> ausweisapp-2.2.0-sources.jar.asc -> ausweisapp-2.2.0-sources.asc
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-343) Rewrite DefaultSiteTools project management
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862987#comment-17862987
]
Michael Osipov commented on DOXIASITETOOLS-343:
---
Do you think we can make it before this goes GA?
> Rewrite DefaultSiteTools project management
> ---
>
> Key: DOXIASITETOOLS-343
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-343
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Priority: Major
>
> The code loads MavenProject from local repositories and uses
> {{project.getBasedir() == null}} to check if the project was loaded from the
> local repository or if it is a real project.
> This is wrong imho (and was broken in 4.0.0-alpha-8 to beta-3). To load a
> model from the local repository, one should use {{ModelBuilder}} and only use
> {{ProjectBuilder}} to load projects which are _real_ projects.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8173) -Dpackaging= is ignored when using mvn deploy:deploy-file
[
https://issues.apache.org/jira/browse/MNG-8173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Schmertmann updated MNG-8173:
--
Summary: -Dpackaging= is ignored when using mvn deploy:deploy-file (was:
-Dpackaging= is ignores when using mvn deploy:deploy-file)
> -Dpackaging= is ignored when using mvn deploy:deploy-file
> -
>
> Key: MNG-8173
> URL: https://issues.apache.org/jira/browse/MNG-8173
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Deployment
>Affects Versions: 3.9.6, 3.9.7, 3.9.8
> Environment: Archlinux
>Reporter: Lars Schmertmann
>Priority: Major
>
> We have a project where we deploy the following files:
> {code}
> ausweisapp-2.2.0.aar
> ausweisapp-2.2.0.aar.asc
> ausweisapp-2.2.0.pom
> ausweisapp-2.2.0.pom.asc
> ausweisapp-2.2.0-sources.jar
> ausweisapp-2.2.0-sources.jar.asc
> {code}
> We are using the following commands:
> {code}
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.aar
> -DpomFile=ausweisapp-2.2.0.pom -Dsources=ausweisapp-2.2.0-sources.jar
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.aar.asc
> -Dpackaging=aar.asc -Dclassifier= -DpomFile=ausweisapp-2.2.0.pom
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.pom.asc
> -Dpackaging=pom.asc -Dclassifier= -DpomFile=ausweisapp-2.2.0.pom
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> /usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0-sources.jar.asc
> -Dpackaging=jar.asc -Dclassifier=sources -DpomFile=ausweisapp-2.2.0.pom
> -DrepositoryId=nexus
> -Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
> --settings settings.xml
> {code}
> With 3.8.7 everythings works fine. But at least with 3.9.6 - 3.9.8
> `-Dpackaging=` is ignored.
> This leads to the following renames during deployment and the signature check
> fails:
> {code}
> ausweisapp-2.2.0.aar.asc -> ausweisapp-2.2.0.asc
> ausweisapp-2.2.0.pom.asc -> ausweisapp-2.2.0.asc
> ausweisapp-2.2.0-sources.jar.asc -> ausweisapp-2.2.0-sources.asc
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8173) -Dpackaging= is ignores when using mvn deploy:deploy-file
Lars Schmertmann created MNG-8173:
-
Summary: -Dpackaging= is ignores when using mvn deploy:deploy-file
Key: MNG-8173
URL: https://issues.apache.org/jira/browse/MNG-8173
Project: Maven
Issue Type: Bug
Components: Command Line, Deployment
Affects Versions: 3.9.8, 3.9.7, 3.9.6
Environment: Archlinux
Reporter: Lars Schmertmann
We have a project where we deploy the following files:
{code}
ausweisapp-2.2.0.aar
ausweisapp-2.2.0.aar.asc
ausweisapp-2.2.0.pom
ausweisapp-2.2.0.pom.asc
ausweisapp-2.2.0-sources.jar
ausweisapp-2.2.0-sources.jar.asc
{code}
We are using the following commands:
{code}
/usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.aar
-DpomFile=ausweisapp-2.2.0.pom -Dsources=ausweisapp-2.2.0-sources.jar
-DrepositoryId=nexus
-Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
--settings settings.xml
/usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.aar.asc
-Dpackaging=aar.asc -Dclassifier= -DpomFile=ausweisapp-2.2.0.pom
-DrepositoryId=nexus
-Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
--settings settings.xml
/usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0.pom.asc
-Dpackaging=pom.asc -Dclassifier= -DpomFile=ausweisapp-2.2.0.pom
-DrepositoryId=nexus
-Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
--settings settings.xml
/usr/bin/mvn deploy:deploy-file -Dfile=ausweisapp-2.2.0-sources.jar.asc
-Dpackaging=jar.asc -Dclassifier=sources -DpomFile=ausweisapp-2.2.0.pom
-DrepositoryId=nexus
-Durl=https://s01.oss.sonatype.org/service/local/staging/deploy/maven2
--settings settings.xml
{code}
With 3.8.7 everythings works fine. But at least with 3.9.6 - 3.9.8
`-Dpackaging=` is ignored.
This leads to the following renames during deployment and the signature check
fails:
{code}
ausweisapp-2.2.0.aar.asc -> ausweisapp-2.2.0.asc
ausweisapp-2.2.0.pom.asc -> ausweisapp-2.2.0.asc
ausweisapp-2.2.0-sources.jar.asc -> ausweisapp-2.2.0-sources.asc
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8172) Fix site building
[ https://issues.apache.org/jira/browse/MNG-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862983#comment-17862983 ] ASF GitHub Bot commented on MNG-8172: - michael-o commented on PR #1594: URL: https://github.com/apache/maven/pull/1594#issuecomment-2208543807 > > Big question is now: Should the components in m-site-p rewritten to make things right? (for both Maven 3 and 4) > > Doxia 2.x can be used on Maven 3, right ? So if we fix it there, it may be sufficient, assuming we somehow force Maven 4 users to use m-site-p 4.x. Though I suppose once the work is done on Doxia 2.x, porting it to Doxia 1.x should not be too difficult... I wouldn't put any effort into Doxia 1.x. Doxia 2.x is fully compatible with Maven 3 and intended to be used with 3.6.3+. m-site-p will be available for both Maven 3 and 4 with Doxia 2.x. > Fix site building > - > > Key: MNG-8172 > URL: https://issues.apache.org/jira/browse/MNG-8172 > Project: Maven > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-4 > > > Restore behaviour with MavenProject.getBasedir() == null for projects loaded > from local repository. > The maven-site-plugin relies on this behaviour and site building is broken if > not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8172) Fix site building
[ https://issues.apache.org/jira/browse/MNG-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-8172: - Summary: Fix site building (was: Restore behaviour with MavenProject.getBasedir() == null for projects loaded from local repository) > Fix site building > - > > Key: MNG-8172 > URL: https://issues.apache.org/jira/browse/MNG-8172 > Project: Maven > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-4 > > > The maven-site-plugin relies on this behaviour and site building is broken if > not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8172) Restore behaviour with MavenProject.getBasedir() == null for projects loaded from local repository
[ https://issues.apache.org/jira/browse/MNG-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-8172: - Description: The maven-site-plugin relies on this behaviour and site building is broken if not. > Restore behaviour with MavenProject.getBasedir() == null for projects loaded > from local repository > -- > > Key: MNG-8172 > URL: https://issues.apache.org/jira/browse/MNG-8172 > Project: Maven > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-4 > > > The maven-site-plugin relies on this behaviour and site building is broken if > not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8172) Fix site building
[ https://issues.apache.org/jira/browse/MNG-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-8172: - Description: Restore behaviour with MavenProject.getBasedir() == null for projects loaded from local repository. The maven-site-plugin relies on this behaviour and site building is broken if not. was:The maven-site-plugin relies on this behaviour and site building is broken if not. > Fix site building > - > > Key: MNG-8172 > URL: https://issues.apache.org/jira/browse/MNG-8172 > Project: Maven > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-4 > > > Restore behaviour with MavenProject.getBasedir() == null for projects loaded > from local repository. > The maven-site-plugin relies on this behaviour and site building is broken if > not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8172) Restore behaviour with MavenProject.getBasedir() == null for projects loaded from local repository
Guillaume Nodet created MNG-8172: Summary: Restore behaviour with MavenProject.getBasedir() == null for projects loaded from local repository Key: MNG-8172 URL: https://issues.apache.org/jira/browse/MNG-8172 Project: Maven Issue Type: Bug Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 4.0.0-beta-4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIASITETOOLS-343) Rewrite DefaultSiteTools project management
Guillaume Nodet created DOXIASITETOOLS-343:
--
Summary: Rewrite DefaultSiteTools project management
Key: DOXIASITETOOLS-343
URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-343
Project: Maven Doxia Sitetools
Issue Type: Improvement
Reporter: Guillaume Nodet
The code loads MavenProject from local repositories and uses
{{project.getBasedir() == null}} to check if the project was loaded from the
local repository or if it is a real project.
This is wrong imho (and was broken in 4.0.0-alpha-8 to beta-3). To load a
model from the local repository, one should use {{ModelBuilder}} and only use
{{ProjectBuilder}} to load projects which are _real_ projects.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8171) Artifact with project.rootDirectory causes Maven to expect a root directory in local repository
Christian Bühler created MNG-8171:
-
Summary: Artifact with project.rootDirectory causes Maven to
expect a root directory in local repository
Key: MNG-8171
URL: https://issues.apache.org/jira/browse/MNG-8171
Project: Maven
Issue Type: Bug
Affects Versions: 4.0.0-beta-3
Environment: Windows 11, Java 22
Reporter: Christian Bühler
When including artifact A (that uses {{project.rootDirectory}} in its POM) in
artifact B using {{maven-dependency-plugin:copy}}, Maven tries to evaluate
artifact A's POM inside the local repository and expects to find a root
directory. This breaks the build.
Artifact B must be under a different parent/in a different source repository,
otherwise Maven resolves the artifact from {{target/project-local-repo}} and
can find a root directory. The workaround for this is creating {{.mvn}}
directory in the root of the local repository.
I think this is a bug, but not sure where the root cause is and couldn't find
an existing issue for this.
*Artifact A:*
{code:xml}
project.a
a
pom
{code}
*Artifact B:*
{code:xml}
project.b
b
pom
maven-dependency-plugin
copy
a
zip
{code}
*Stacktrace:*
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:3.7.1:copy (default) on
project x: Execution default of goal
org.apache.maven.plugins:maven-dependency-plugin:3.7.1:copy failed: Unable to
find the root directory. Create a .mvn directory in the root directory or add
the root="true" attribute on the root project's model to identify it. -> [Help
1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:3.7.1:copy (default) on
project x: Execution default of goal
org.apache.maven.plugins:maven-dependency-plugin:3.7.1:copy failed: Unable to
find the root directory. Create a .mvn directory in the root directory or add
the root="true" attribute on the root project's model to identify it.
at
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:329)
at
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:311)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:178)
at
org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:167)
at
org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:164)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:107)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:60)
at
org.apache.maven.lifecycle.internal.DefaultLifecycleStarter.execute(DefaultLifecycleStarter.java:123)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:225)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:149)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:958)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
at
jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.lang.reflect.Method.invoke(Method.java:580)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:255)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:201)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:361)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:314)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default
of goal org.apache.maven.plugins:maven-dependency-plugin:3.7.1:copy failed:
Unable to find the root directory. Create a .mvn directory in the root
directory or add the root="true" attribute on the root project's model to
identify it.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:150)
at
org.apache.maven.lifecycle
[jira] [Updated] (MNG-8130) Feature to replace plugin provided by lifecycle
[ https://issues.apache.org/jira/browse/MNG-8130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8130: - Fix Version/s: 4.0.0-beta-4 > Feature to replace plugin provided by lifecycle > --- > > Key: MNG-8130 > URL: https://issues.apache.org/jira/browse/MNG-8130 > Project: Maven > Issue Type: New Feature > Components: Plugins and Lifecycle >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-beta-4 > > > Lifecycle define plugins like G:A:V. We've seen several practices how to > "replace" (usually core) plugin with some non-core one. This most often > involves some hacks, like lifecycle participant, that "rewrites" model upon > it is loaded. This is hacky. > We need some clear way, to be able to replace plugins, like by providing some > "instead of G:A:V I want to use G':A':V'" and maven should just obey. No > tricks, no hacks, no fuss. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8170) Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
[
https://issues.apache.org/jira/browse/MNG-8170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862838#comment-17862838
]
Guillaume Nodet commented on MNG-8170:
--
[https://github.com/jline/jline3/pull/1031]
[https://github.com/fusesource/jansi/pull/292]
Note that it does not really seem to affect the execution, even though I don't
understand how it works on Windows+arm64.
> Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
>
>
> Key: MNG-8170
> URL: https://issues.apache.org/jira/browse/MNG-8170
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.8
>Reporter: Michael Osipov
>Priority: Major
>
> This doesn't look right:
> {noformat}
> $ tree
> .
> ├── README.txt
> └── Windows
> ├── arm64
> │ └── libjansi.so
> ├── x86
> │ └── jansi.dll
> └── x86_64
> └── jansi.dll
> 5 directories, 4 files
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/arm64/libjansi.so
> Windows/arm64/libjansi.so: PE32+ executable (DLL) (GUI) Aarch64, for MS
> Windows
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/x86_64/jansi.dll
> Windows/x86_64/jansi.dll: PE32+ executable (DLL) (console) x86-64, for MS
> Windows
> {noformat}
> 1. It should be console type
> 2. Name should be {{jansi.dll}}
> No?
> [~gnodet], [~cstamas].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8170) Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
[
https://issues.apache.org/jira/browse/MNG-8170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862738#comment-17862738
]
Michael Osipov commented on MNG-8170:
-
Yes, but I means this weird information {{(DLL) (GUI)}}. Doesn't compute for
me. Let's first add the entries to the Makefile.
> Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
>
>
> Key: MNG-8170
> URL: https://issues.apache.org/jira/browse/MNG-8170
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.8
>Reporter: Michael Osipov
>Priority: Major
>
> This doesn't look right:
> {noformat}
> $ tree
> .
> ├── README.txt
> └── Windows
> ├── arm64
> │ └── libjansi.so
> ├── x86
> │ └── jansi.dll
> └── x86_64
> └── jansi.dll
> 5 directories, 4 files
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/arm64/libjansi.so
> Windows/arm64/libjansi.so: PE32+ executable (DLL) (GUI) Aarch64, for MS
> Windows
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/x86_64/jansi.dll
> Windows/x86_64/jansi.dll: PE32+ executable (DLL) (console) x86-64, for MS
> Windows
> {noformat}
> 1. It should be console type
> 2. Name should be {{jansi.dll}}
> No?
> [~gnodet], [~cstamas].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8170) Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
[
https://issues.apache.org/jira/browse/MNG-8170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862736#comment-17862736
]
Guillaume Nodet commented on MNG-8170:
--
I think the files are simply extracted from the jansi jar, so the layout and
file names will be the same.
> Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
>
>
> Key: MNG-8170
> URL: https://issues.apache.org/jira/browse/MNG-8170
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.8
>Reporter: Michael Osipov
>Priority: Major
>
> This doesn't look right:
> {noformat}
> $ tree
> .
> ├── README.txt
> └── Windows
> ├── arm64
> │ └── libjansi.so
> ├── x86
> │ └── jansi.dll
> └── x86_64
> └── jansi.dll
> 5 directories, 4 files
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/arm64/libjansi.so
> Windows/arm64/libjansi.so: PE32+ executable (DLL) (GUI) Aarch64, for MS
> Windows
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/x86_64/jansi.dll
> Windows/x86_64/jansi.dll: PE32+ executable (DLL) (console) x86-64, for MS
> Windows
> {noformat}
> 1. It should be console type
> 2. Name should be {{jansi.dll}}
> No?
> [~gnodet], [~cstamas].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}
[
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862723#comment-17862723
]
ASF GitHub Bot commented on MRELEASE-1109:
--
mkolesnikov commented on code in PR #201:
URL: https://github.com/apache/maven-release/pull/201#discussion_r1664002536
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -96,7 +96,7 @@ public abstract class AbstractRewritePomsPhase extends
AbstractReleasePhase impl
* Regular expression pattern matching Maven expressions (i.e. references
to Maven properties).
* The first group selects the property name the expression refers to.
*/
-private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+)\\}");
+private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+?)\\}");
Review Comment:
As a workaround you could try to add configuration property
`-Dchangelist=` for the `maven-release-plugin`
> update-versions removes the CI-friendly ${revisions}
>
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.1.0
>
>
> Given: a project using CI-friendly versions as per
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
> ${revision}
> ...
>
> 1.0.0-SNAPSHOT
>
> {code}
> If I run {{mvn release:update-versions}} (with or without
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change
> the {{$revision}} property. Instead it blindly replaces
> {{${revision}}} with the hard-coded version set on the CLI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-8170) Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
[
https://issues.apache.org/jira/browse/MNG-8170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862707#comment-17862707
]
Michael Osipov edited comment on MNG-8170 at 7/3/24 10:00 AM:
--
Pretty much looks so, but would that explain the {{GUI}} value as well? I don't
know the implications of this. Windows is a mystery in this regard.
was (Author: michael-o):
Pretty much looks so, but would that explain the {{GUI}} value as well?
> Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
>
>
> Key: MNG-8170
> URL: https://issues.apache.org/jira/browse/MNG-8170
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.8
>Reporter: Michael Osipov
>Priority: Major
>
> This doesn't look right:
> {noformat}
> $ tree
> .
> ├── README.txt
> └── Windows
> ├── arm64
> │ └── libjansi.so
> ├── x86
> │ └── jansi.dll
> └── x86_64
> └── jansi.dll
> 5 directories, 4 files
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/arm64/libjansi.so
> Windows/arm64/libjansi.so: PE32+ executable (DLL) (GUI) Aarch64, for MS
> Windows
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/x86_64/jansi.dll
> Windows/x86_64/jansi.dll: PE32+ executable (DLL) (console) x86-64, for MS
> Windows
> {noformat}
> 1. It should be console type
> 2. Name should be {{jansi.dll}}
> No?
> [~gnodet], [~cstamas].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8170) Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
[
https://issues.apache.org/jira/browse/MNG-8170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862707#comment-17862707
]
Michael Osipov commented on MNG-8170:
-
Pretty much looks so, but would that explain the {{GUI}} value as well?
> Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
>
>
> Key: MNG-8170
> URL: https://issues.apache.org/jira/browse/MNG-8170
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.8
>Reporter: Michael Osipov
>Priority: Major
>
> This doesn't look right:
> {noformat}
> $ tree
> .
> ├── README.txt
> └── Windows
> ├── arm64
> │ └── libjansi.so
> ├── x86
> │ └── jansi.dll
> └── x86_64
> └── jansi.dll
> 5 directories, 4 files
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/arm64/libjansi.so
> Windows/arm64/libjansi.so: PE32+ executable (DLL) (GUI) Aarch64, for MS
> Windows
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/x86_64/jansi.dll
> Windows/x86_64/jansi.dll: PE32+ executable (DLL) (console) x86-64, for MS
> Windows
> {noformat}
> 1. It should be console type
> 2. Name should be {{jansi.dll}}
> No?
> [~gnodet], [~cstamas].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8170) Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
[
https://issues.apache.org/jira/browse/MNG-8170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862705#comment-17862705
]
Guillaume Nodet commented on MNG-8170:
--
I suppose there's a missing arm64 block for windows:
[https://github.com/fusesource/jansi/blob/master/Makefile.common#L158-L163]
Same here:
[https://github.com/jline/jline3/blob/master/native/Makefile.common#L149-L153]
> Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
>
>
> Key: MNG-8170
> URL: https://issues.apache.org/jira/browse/MNG-8170
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.8
>Reporter: Michael Osipov
>Priority: Major
>
> This doesn't look right:
> {noformat}
> $ tree
> .
> ├── README.txt
> └── Windows
> ├── arm64
> │ └── libjansi.so
> ├── x86
> │ └── jansi.dll
> └── x86_64
> └── jansi.dll
> 5 directories, 4 files
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/arm64/libjansi.so
> Windows/arm64/libjansi.so: PE32+ executable (DLL) (GUI) Aarch64, for MS
> Windows
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/x86_64/jansi.dll
> Windows/x86_64/jansi.dll: PE32+ executable (DLL) (console) x86-64, for MS
> Windows
> {noformat}
> 1. It should be console type
> 2. Name should be {{jansi.dll}}
> No?
> [~gnodet], [~cstamas].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[
https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862689#comment-17862689
]
Réda Housni Alaoui edited comment on MWRAPPER-133 at 7/3/24 9:45 AM:
-
For the record, the workaround described in
https://issues.apache.org/jira/browse/MWRAPPER-133?focusedCommentId=17845700=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17845700
generated a new issue with the latest Maven wrapper (3.3.2): {{--batch-mode}}
flag (added by default by pipeline maven integration in {{MAVEN_CONFIG}} ) ends
up in {{MAVEN_ARGS}}, which makes the build fail.
was (Author: ralaoui):
For the record, the workaround described in
https://issues.apache.org/jira/browse/MWRAPPER-133?focusedCommentId=17845700=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17845700
generated a new issue with the latest Maven wrapper: {{--batch-mode}} flag
(added by default by pipeline maven integration in {{MAVEN_CONFIG}} ) ends up
in {{MAVEN_ARGS}}, which makes the build fail.
> MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
> ---
>
> Key: MWRAPPER-133
> URL: https://issues.apache.org/jira/browse/MWRAPPER-133
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.0
>Reporter: Rocher Suchard
>Priority: Major
>
> Hello,
> Due to an update by Renovate in one of our project, I've seen some error
> related to internal dependencies not being picked up by Maven : while we were
> using a custom settings, it did not use it and was using Central instead of
> our Artifactory.
> Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG
> environnement variable here :
> https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
> The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and
> I've played around with the default value and type:
> {code:bash}
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
> # use scripts-only
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> # nothing
> $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
> # use bin
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin
> ...
> [INFO] Unpacked bin type wrapper distribution
> org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0
> [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6
> and download from https://repo.maven.apache.org/maven2
> ...
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %*
> {code}
> Is there a way to do the same for the script-only if this is to be the
> default ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8170) Maven 3.9.8 contains weird native librar for Jansi on Windows/arm64
Michael Osipov created MNG-8170:
---
Summary: Maven 3.9.8 contains weird native librar for Jansi on
Windows/arm64
Key: MNG-8170
URL: https://issues.apache.org/jira/browse/MNG-8170
Project: Maven
Issue Type: Bug
Affects Versions: 3.9.8
Reporter: Michael Osipov
This doesn't look right:
{noformat}
$ tree
.
├── README.txt
└── Windows
├── arm64
│ └── libjansi.so
├── x86
│ └── jansi.dll
└── x86_64
└── jansi.dll
5 directories, 4 files
osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
$ file Windows/arm64/libjansi.so
Windows/arm64/libjansi.so: PE32+ executable (DLL) (GUI) Aarch64, for MS Windows
osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
$ file Windows/x86_64/jansi.dll
Windows/x86_64/jansi.dll: PE32+ executable (DLL) (console) x86-64, for MS
Windows
{noformat}
1. It should be console type
2. Name should be {{jansi.dll}}
No?
[~gnodet], [~cstamas].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8170) Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
[
https://issues.apache.org/jira/browse/MNG-8170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-8170:
Summary: Maven 3.9.8 contains weird native library for Jansi on
Windows/arm64 (was: Maven 3.9.8 contains weird native librar for Jansi on
Windows/arm64)
> Maven 3.9.8 contains weird native library for Jansi on Windows/arm64
>
>
> Key: MNG-8170
> URL: https://issues.apache.org/jira/browse/MNG-8170
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.8
>Reporter: Michael Osipov
>Priority: Major
>
> This doesn't look right:
> {noformat}
> $ tree
> .
> ├── README.txt
> └── Windows
> ├── arm64
> │ └── libjansi.so
> ├── x86
> │ └── jansi.dll
> └── x86_64
> └── jansi.dll
> 5 directories, 4 files
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/arm64/libjansi.so
> Windows/arm64/libjansi.so: PE32+ executable (DLL) (GUI) Aarch64, for MS
> Windows
> osipovmi@deblndw011x:/tmp/apache-maven-3.9.8/lib/jansi-native
> $ file Windows/x86_64/jansi.dll
> Windows/x86_64/jansi.dll: PE32+ executable (DLL) (console) x86-64, for MS
> Windows
> {noformat}
> 1. It should be console type
> 2. Name should be {{jansi.dll}}
> No?
> [~gnodet], [~cstamas].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1152) Unable to find properties
[ https://issues.apache.org/jira/browse/MRELEASE-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862696#comment-17862696 ] Vahid commented on MRELEASE-1152: - OK, I'll do it and let you know > Unable to find properties > - > > Key: MRELEASE-1152 > URL: https://issues.apache.org/jira/browse/MRELEASE-1152 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare-with-pom >Affects Versions: 3.0.1, 3.1.0 >Reporter: Vahid >Priority: Major > > Hello, > I have a multi-module project that I want to use maven release plugin for it. > In some sub-modules there are some properties but they are somehow ignored. > I debugged the code and I found that in class > *org.apache.maven.shared.release.transform.jdom2.JDomProperties* line *49* > (inside constructor method) only Object is being created and no key/value is > passed. > So, *modelTarget.getProperties() == null* is false but > *modelTarget.getProperties().isEmpty()* is true. We can say that all > properties in the pom.xml file are ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRELEASE-1152) Unable to find properties
[ https://issues.apache.org/jira/browse/MRELEASE-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRELEASE-1152: - Summary: Unable to find properties (was: Unable to fine properties) > Unable to find properties > - > > Key: MRELEASE-1152 > URL: https://issues.apache.org/jira/browse/MRELEASE-1152 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare-with-pom >Affects Versions: 3.0.1, 3.1.0 >Reporter: Vahid >Priority: Major > > Hello, > I have a multi-module project that I want to use maven release plugin for it. > In some sub-modules there are some properties but they are somehow ignored. > I debugged the code and I found that in class > *org.apache.maven.shared.release.transform.jdom2.JDomProperties* line *49* > (inside constructor method) only Object is being created and no key/value is > passed. > So, *modelTarget.getProperties() == null* is false but > *modelTarget.getProperties().isEmpty()* is true. We can say that all > properties in the pom.xml file are ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1152) Unable to fine properties
[ https://issues.apache.org/jira/browse/MRELEASE-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862695#comment-17862695 ] Michael Osipov commented on MRELEASE-1152: -- You should create a sample project to depict the problem. I do not really understand it. > Unable to fine properties > - > > Key: MRELEASE-1152 > URL: https://issues.apache.org/jira/browse/MRELEASE-1152 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare-with-pom >Affects Versions: 3.0.1, 3.1.0 >Reporter: Vahid >Priority: Major > > Hello, > I have a multi-module project that I want to use maven release plugin for it. > In some sub-modules there are some properties but they are somehow ignored. > I debugged the code and I found that in class > *org.apache.maven.shared.release.transform.jdom2.JDomProperties* line *49* > (inside constructor method) only Object is being created and no key/value is > passed. > So, *modelTarget.getProperties() == null* is false but > *modelTarget.getProperties().isEmpty()* is true. We can say that all > properties in the pom.xml file are ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1151) Maven Release Plugin fails to adjust version (regression in 3.1.0)
[
https://issues.apache.org/jira/browse/MRELEASE-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862693#comment-17862693
]
Michael Osipov commented on MRELEASE-1151:
--
[~marcelstoer], thanks for chiming in! Let me know whether I need to fix
anything in Maven Release. [~basil], I'ld be happy to do a release for the
Jenkins folks, if necessary.
> Maven Release Plugin fails to adjust version (regression in 3.1.0)
> --
>
> Key: MRELEASE-1151
> URL: https://issues.apache.org/jira/browse/MRELEASE-1151
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.1.0
> Environment: Ubuntu 22.04.4 LTS x86_64
>Reporter: Basil Crow
>Priority: Blocker
>
> h3. Steps to reproduce
> # Run {{git clone [https://github.com/jenkinsci/text-finder-plugin.git]}}
> # Using Java 17 and Maven 3.9.8, run {{mvn release:prepare
> -DpushChanges=false}}
> h3. Expected results
> {panel:title=Note}
> These are the _actual_ results with Maven Release Plugin 3.0.1.
> {panel}
> The {{[maven-release-plugin] prepare release}} commit adjusts
> {{${scmTag}}} to e.g. {{text-finder-1.29}} *and*
> adjusts {{${revision}${changelist}}} to e.g.
> {{{}1.29{}}}.
> h3. Actual results
> Starting with Maven Release Plugin 3.1.0, the {{[maven-release-plugin]
> prepare release}} commit still adjusts {{${scmTag}}} to e.g.
> {{{}text-finder-1.29{}}}, but it *fails to adjust*
> {{${revision}${changelist}}} to e.g.
> {{1.29}} as expected. After this, the release subsequently
> fails.
> h3. Evaluation
> This regression is caused by the changes to {{AbstractRewritePomsPhase}} made
> in MRELEASE-1109. When these changes are reverted, the issue is resolved.
> h3. Note
> This caused the weekly Jenkins core release to fail on July 2, 2024. We have
> downgraded Maven Release Plugin to 3.0.1 in order to restore stability to our
> releases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8132) Dependency-management "client" exclusions overwrite BOM exclusions
[
https://issues.apache.org/jira/browse/MNG-8132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8132:
-
Fix Version/s: 4.0.0-beta-4
> Dependency-management "client" exclusions overwrite BOM exclusions
> --
>
> Key: MNG-8132
> URL: https://issues.apache.org/jira/browse/MNG-8132
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 4.0.0-alpha-13, 4.0.0-beta-3
> Environment: Any
>Reporter: Lenny Primak
>Priority: Major
> Fix For: 4.0.0-beta-4
>
>
> Continuation of https://issues.apache.org/jira/browse/MNG-8118
> When importing BOM and introducing exclusions, they overwrite exclusions
> already present in the BOM. They should not
> Slack conversation link:
> [https://the-asf.slack.com/archives/C7Q9JB404/p1714938396499939]
> Regressed by https://issues.apache.org/jira/browse/MNG-5600
> Reproducer project: [https://github.com/flowlogix/bom-exclusions-mvn4]
> Offending / reproducing key lines of pom. Shiro BOM excludes non-Jakarta
> classifier reference to Shrio-core amongst other things:
> {code:java}
>
>
>
> org.apache.shiro
> shiro-bom
> 2.0.0
> pom
> import
>
>
>
> org.slf4j
> *
>
>
>
>
> {code}
> Expected result (maven 3.9.7) only one shiro-core.jar dependency with
> _jakarta_ classifier is present:
> {code:java}
> lprimak@Lennys-MacBook-Pro bom-exclusions-mvn4 % mvn -V dependency:tree
> Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
> Maven home: /Users/lprimak/.sdkman/candidates/maven/3.9.7
> Java version: 22.0.1, vendor: Azul Systems, Inc., runtime:
> /Users/lprimak/.sdkman/candidates/java/22.0.1.fx-zulu/zulu-22.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.7.5", arch: "x86_64", family: "mac"
> [INFO] Scanning for projects...
> [INFO]
> [INFO] ---< com.flowlogix.repdoducers:bom-exclusions-mvn4 >---
> [INFO] Building bom-exclusions-mvn4 1.x-SNAPSHOT
> [INFO] from pom.xml
> [INFO] [ pom ]
> [INFO]
> [INFO] --- dependency:3.6.1:tree (default-cli) @ bom-exclusions-mvn4 ---
> [INFO] com.flowlogix.repdoducers:bom-exclusions-mvn4:pom:1.x-SNAPSHOT
> [INFO] +- org.apache.shiro:shiro-web:jar:jakarta:2.0.0:compile
> [INFO] | \- org.owasp.encoder:encoder:jar:1.2.3:compile
> [INFO] \- org.apache.shiro:shiro-core:jar:jakarta:2.0.0:compile
> . cut unnecessary lines
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.630 s
> [INFO] Finished at: 2024-05-28T22:44:57-04:00
> [INFO]
> --- {code}
>
> Current result (maven 4.0.0-alpha-3): both shiro-core with and without
> jakarta classifier exist:
> {code:java}
> lprimak@Lennys-MacBook-Pro bom-exclusions-mvn4 % mvn -V dependency:tree
> Apache Maven 4.0.0-beta-3 (e92f645c2749eb2a4f5a8843cf01e7441e4b559f)
> Maven home: /Users/lprimak/.sdkman/candidates/maven/4.0.0-beta-3
> Java version: 22.0.1, vendor: Azul Systems, Inc., runtime:
> /Users/lprimak/.sdkman/candidates/java/22.0.1.fx-zulu/zulu-22.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.7.5", arch: "x86_64", family: "mac"
> [INFO] Scanning for projects...
> [INFO]
> [INFO] <
> com.flowlogix.repdoducers:bom-exclusions-mvn4
> >
> [INFO] Building bom-exclusions-mvn4 1.x-SNAPSHOT
> [INFO] from pom.xml
> [INFO] -[ pom
> ]-
> [INFO]
> [INFO] --- dependency:3.6.1:tree (default-cli) @ bom-exclusions-mvn4 ---
> [INFO] com.flowlogix.repdoducers:bom-exclusions-mvn4:pom:1.x-SNAPSHOT
> [INFO] +- org.apache.shiro:shiro-web:jar:jakarta:2.0.0:compile
> *** below should not exist - non-jakarta classifier
> [INFO] | +- org.apache.shiro:shiro-c
[jira] [Assigned] (MNG-8132) Dependency-management "client" exclusions overwrite BOM exclusions
[
https://issues.apache.org/jira/browse/MNG-8132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-8132:
Assignee: Guillaume Nodet
> Dependency-management "client" exclusions overwrite BOM exclusions
> --
>
> Key: MNG-8132
> URL: https://issues.apache.org/jira/browse/MNG-8132
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 4.0.0-alpha-13, 4.0.0-beta-3
> Environment: Any
>Reporter: Lenny Primak
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-beta-4
>
>
> Continuation of https://issues.apache.org/jira/browse/MNG-8118
> When importing BOM and introducing exclusions, they overwrite exclusions
> already present in the BOM. They should not
> Slack conversation link:
> [https://the-asf.slack.com/archives/C7Q9JB404/p1714938396499939]
> Regressed by https://issues.apache.org/jira/browse/MNG-5600
> Reproducer project: [https://github.com/flowlogix/bom-exclusions-mvn4]
> Offending / reproducing key lines of pom. Shiro BOM excludes non-Jakarta
> classifier reference to Shrio-core amongst other things:
> {code:java}
>
>
>
> org.apache.shiro
> shiro-bom
> 2.0.0
> pom
> import
>
>
>
> org.slf4j
> *
>
>
>
>
> {code}
> Expected result (maven 3.9.7) only one shiro-core.jar dependency with
> _jakarta_ classifier is present:
> {code:java}
> lprimak@Lennys-MacBook-Pro bom-exclusions-mvn4 % mvn -V dependency:tree
> Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
> Maven home: /Users/lprimak/.sdkman/candidates/maven/3.9.7
> Java version: 22.0.1, vendor: Azul Systems, Inc., runtime:
> /Users/lprimak/.sdkman/candidates/java/22.0.1.fx-zulu/zulu-22.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.7.5", arch: "x86_64", family: "mac"
> [INFO] Scanning for projects...
> [INFO]
> [INFO] ---< com.flowlogix.repdoducers:bom-exclusions-mvn4 >---
> [INFO] Building bom-exclusions-mvn4 1.x-SNAPSHOT
> [INFO] from pom.xml
> [INFO] [ pom ]
> [INFO]
> [INFO] --- dependency:3.6.1:tree (default-cli) @ bom-exclusions-mvn4 ---
> [INFO] com.flowlogix.repdoducers:bom-exclusions-mvn4:pom:1.x-SNAPSHOT
> [INFO] +- org.apache.shiro:shiro-web:jar:jakarta:2.0.0:compile
> [INFO] | \- org.owasp.encoder:encoder:jar:1.2.3:compile
> [INFO] \- org.apache.shiro:shiro-core:jar:jakarta:2.0.0:compile
> . cut unnecessary lines
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.630 s
> [INFO] Finished at: 2024-05-28T22:44:57-04:00
> [INFO]
> --- {code}
>
> Current result (maven 4.0.0-alpha-3): both shiro-core with and without
> jakarta classifier exist:
> {code:java}
> lprimak@Lennys-MacBook-Pro bom-exclusions-mvn4 % mvn -V dependency:tree
> Apache Maven 4.0.0-beta-3 (e92f645c2749eb2a4f5a8843cf01e7441e4b559f)
> Maven home: /Users/lprimak/.sdkman/candidates/maven/4.0.0-beta-3
> Java version: 22.0.1, vendor: Azul Systems, Inc., runtime:
> /Users/lprimak/.sdkman/candidates/java/22.0.1.fx-zulu/zulu-22.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.7.5", arch: "x86_64", family: "mac"
> [INFO] Scanning for projects...
> [INFO]
> [INFO] <
> com.flowlogix.repdoducers:bom-exclusions-mvn4
> >
> [INFO] Building bom-exclusions-mvn4 1.x-SNAPSHOT
> [INFO] from pom.xml
> [INFO] -[ pom
> ]-
> [INFO]
> [INFO] --- dependency:3.6.1:tree (default-cli) @ bom-exclusions-mvn4 ---
> [INFO] com.flowlogix.repdoducers:bom-exclusions-mvn4:pom:1.x-SNAPSHOT
> [INFO] +- org.apache.shiro:shiro-web:jar:jakarta:2.0.0:compile
> *** below should not exist - non-jakarta cl
[jira] [Commented] (MNG-7266) Remove maven-compat module
[ https://issues.apache.org/jira/browse/MNG-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862691#comment-17862691 ] ASF GitHub Bot commented on MNG-7266: - gnodet commented on PR #1487: URL: https://github.com/apache/maven/pull/1487#issuecomment-2205390080 > > > > > > I did investigate again and now I understand what actually happens: When I run current reporting plugins wich do _not_ depend on Maven Compat I still get CNFE, e.g., RepositorySystem or others because in [967d8fc](https://github.com/apache/maven/commit/967d8fc19cbb8a78410ceed70bd91c2e628da813) a bunch of classes were moved to Compat and are now gone. What apparantly was fine with Maven 3.x is now not possible with Maven 4. If all changes in [967d8fc](https://github.com/apache/maven/commit/967d8fc19cbb8a78410ceed70bd91c2e628da813) are correct then those plugins aren't compatible with 4 and need a separate branch for 4. > > > > > > > > > > > > > > > Do you know which class is required and not found ? > > > > > > > > > > > > Oh, sorry `RepositorySystem`. For those plugins, a dependency on maven-compat needs to be added afaik. > > > > > > > > > This means that compat cannot be removed for those plugins? How to proceed in case? > > > > > > All of these plugins are one Maven 3.6.3 already. I prefer the Resolver approach. Second option. > > Agreed, I think m-site-p is ok, it's maven-project-info-reports-plugin which depends on maven-compat and needs to be updated. Actually, adding maven-compat does not work, and switching to `org.apache.maven.bridge.MavenRepositorySystem` does not work too. The reason is the classes are present in maven-core 3.x and maven-compat 4.x. A real switch to maven-resolver api will work better. > Remove maven-compat module > -- > > Key: MNG-7266 > URL: https://issues.apache.org/jira/browse/MNG-7266 > Project: Maven > Issue Type: Sub-task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.x-candidate > > > Maven-core does not depend on maven-compat anymore (runtime or compile time). > Do we want to carry it over up to 4.0.0 and delete it in 4.1.0, or do we > want to drop it before 4.0.0 ? > [~cstamas] [~olamy] [~romain.manni-bucau] [~sjaranowski] and others... ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[
https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862689#comment-17862689
]
Réda Housni Alaoui edited comment on MWRAPPER-133 at 7/3/24 8:07 AM:
-
For the record, the workaround described in
https://issues.apache.org/jira/browse/MWRAPPER-133?focusedCommentId=17845700=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17845700
generated a new issue with the latest Maven wrapper: {{--batch-mode}} flag
(added by default by pipeline maven integration in {{MAVEN_CONFIG}} ) ends up
in {{MAVEN_ARGS}}, which makes the build fail.
was (Author: ralaoui):
For the record, the workaround described in
https://issues.apache.org/jira/browse/MWRAPPER-133?focusedCommentId=17845700=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17845700
generated a new issue with the latest Maven wrapper: {{--batch-mode}} flag
ends up in {{MAVEN_ARGS}}, which makes the build fail.
> MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
> ---
>
> Key: MWRAPPER-133
> URL: https://issues.apache.org/jira/browse/MWRAPPER-133
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.0
>Reporter: Rocher Suchard
>Priority: Major
>
> Hello,
> Due to an update by Renovate in one of our project, I've seen some error
> related to internal dependencies not being picked up by Maven : while we were
> using a custom settings, it did not use it and was using Central instead of
> our Artifactory.
> Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG
> environnement variable here :
> https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
> The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and
> I've played around with the default value and type:
> {code:bash}
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
> # use scripts-only
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> # nothing
> $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
> # use bin
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin
> ...
> [INFO] Unpacked bin type wrapper distribution
> org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0
> [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6
> and download from https://repo.maven.apache.org/maven2
> ...
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %*
> {code}
> Is there a way to do the same for the script-only if this is to be the
> default ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[
https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862689#comment-17862689
]
Réda Housni Alaoui commented on MWRAPPER-133:
-
For the record, the workaround described in
https://issues.apache.org/jira/browse/MWRAPPER-133?focusedCommentId=17845700=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17845700
generated a new issue with the latest Maven wrapper: {{--batch-mode}} flag
ends up in {{MAVEN_ARGS}}, which makes the build fail.
> MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
> ---
>
> Key: MWRAPPER-133
> URL: https://issues.apache.org/jira/browse/MWRAPPER-133
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.0
>Reporter: Rocher Suchard
>Priority: Major
>
> Hello,
> Due to an update by Renovate in one of our project, I've seen some error
> related to internal dependencies not being picked up by Maven : while we were
> using a custom settings, it did not use it and was using Central instead of
> our Artifactory.
> Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG
> environnement variable here :
> https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
> The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and
> I've played around with the default value and type:
> {code:bash}
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
> # use scripts-only
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> # nothing
> $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
> # use bin
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin
> ...
> [INFO] Unpacked bin type wrapper distribution
> org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0
> [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6
> and download from https://repo.maven.apache.org/maven2
> ...
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %*
> {code}
> Is there a way to do the same for the script-only if this is to be the
> default ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7266) Remove maven-compat module
[ https://issues.apache.org/jira/browse/MNG-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862678#comment-17862678 ] ASF GitHub Bot commented on MNG-7266: - gnodet commented on PR #1487: URL: https://github.com/apache/maven/pull/1487#issuecomment-2205267196 > > > > > I did investigate again and now I understand what actually happens: When I run current reporting plugins wich do _not_ depend on Maven Compat I still get CNFE, e.g., RepositorySystem or others because in [967d8fc](https://github.com/apache/maven/commit/967d8fc19cbb8a78410ceed70bd91c2e628da813) a bunch of classes were moved to Compat and are now gone. What apparantly was fine with Maven 3.x is now not possible with Maven 4. If all changes in [967d8fc](https://github.com/apache/maven/commit/967d8fc19cbb8a78410ceed70bd91c2e628da813) are correct then those plugins aren't compatible with 4 and need a separate branch for 4. > > > > > > > > > > > > Do you know which class is required and not found ? > > > > > > > > > Oh, sorry `RepositorySystem`. For those plugins, a dependency on maven-compat needs to be added afaik. > > > > > > This means that compat cannot be removed for those plugins? How to proceed in case? > > All of these plugins are one Maven 3.6.3 already. I prefer the Resolver approach. Second option. Agreed, I think m-site-p is ok, it's maven-project-info-reports-plugin which depends on maven-compat and needs to be updated. > Remove maven-compat module > -- > > Key: MNG-7266 > URL: https://issues.apache.org/jira/browse/MNG-7266 > Project: Maven > Issue Type: Sub-task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.x-candidate > > > Maven-core does not depend on maven-compat anymore (runtime or compile time). > Do we want to carry it over up to 4.0.0 and delete it in 4.1.0, or do we > want to drop it before 4.0.0 ? > [~cstamas] [~olamy] [~romain.manni-bucau] [~sjaranowski] and others... ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7266) Remove maven-compat module
[ https://issues.apache.org/jira/browse/MNG-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862673#comment-17862673 ] ASF GitHub Bot commented on MNG-7266: - michael-o commented on PR #1487: URL: https://github.com/apache/maven/pull/1487#issuecomment-2205220610 > > > > I did investigate again and now I understand what actually happens: When I run current reporting plugins wich do _not_ depend on Maven Compat I still get CNFE, e.g., RepositorySystem or others because in [967d8fc](https://github.com/apache/maven/commit/967d8fc19cbb8a78410ceed70bd91c2e628da813) a bunch of classes were moved to Compat and are now gone. What apparantly was fine with Maven 3.x is now not possible with Maven 4. If all changes in [967d8fc](https://github.com/apache/maven/commit/967d8fc19cbb8a78410ceed70bd91c2e628da813) are correct then those plugins aren't compatible with 4 and need a separate branch for 4. > > > > > > > > > Do you know which class is required and not found ? > > > > > > Oh, sorry `RepositorySystem`. For those plugins, a dependency on maven-compat needs to be added afaik. > > This means that compat cannot be removed for those plugins? How to proceed in case? All of these plugins are one Maven 3.6.3 already. I prefer the Resolver approach. Second option. > Remove maven-compat module > -- > > Key: MNG-7266 > URL: https://issues.apache.org/jira/browse/MNG-7266 > Project: Maven > Issue Type: Sub-task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.x-candidate > > > Maven-core does not depend on maven-compat anymore (runtime or compile time). > Do we want to carry it over up to 4.0.0 and delete it in 4.1.0, or do we > want to drop it before 4.0.0 ? > [~cstamas] [~olamy] [~romain.manni-bucau] [~sjaranowski] and others... ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1151) Maven Release Plugin fails to adjust version (regression in 3.1.0)
[
https://issues.apache.org/jira/browse/MRELEASE-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862665#comment-17862665
]
Marcel Stör commented on MRELEASE-1151:
---
>From what I can tell looking at
>https://github.com/jenkinsci/jenkins/commit/dd7a6874e6704bb7163a98c728b3b11a78be53f6,
> the root cause appears to be {{-SNAPSHOT}}. This was
>previously not an issue because {{}} was completely
>rewritten.
{{release:prepare}} usually drops the {{-SNAPSHOT}}. Hence, the plugin should
also drop it for the {{${changelist}}}. This would result in a behavior equal
to running {{mvn -Dchangelist= release:prepare}} I suppose.
> Maven Release Plugin fails to adjust version (regression in 3.1.0)
> --
>
> Key: MRELEASE-1151
> URL: https://issues.apache.org/jira/browse/MRELEASE-1151
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.1.0
> Environment: Ubuntu 22.04.4 LTS x86_64
>Reporter: Basil Crow
>Priority: Blocker
>
> h3. Steps to reproduce
> # Run {{git clone [https://github.com/jenkinsci/text-finder-plugin.git]}}
> # Using Java 17 and Maven 3.9.8, run {{mvn release:prepare
> -DpushChanges=false}}
> h3. Expected results
> {panel:title=Note}
> These are the _actual_ results with Maven Release Plugin 3.0.1.
> {panel}
> The {{[maven-release-plugin] prepare release}} commit adjusts
> {{${scmTag}}} to e.g. {{text-finder-1.29}} *and*
> adjusts {{${revision}${changelist}}} to e.g.
> {{{}1.29{}}}.
> h3. Actual results
> Starting with Maven Release Plugin 3.1.0, the {{[maven-release-plugin]
> prepare release}} commit still adjusts {{${scmTag}}} to e.g.
> {{{}text-finder-1.29{}}}, but it *fails to adjust*
> {{${revision}${changelist}}} to e.g.
> {{1.29}} as expected. After this, the release subsequently
> fails.
> h3. Evaluation
> This regression is caused by the changes to {{AbstractRewritePomsPhase}} made
> in MRELEASE-1109. When these changes are reverted, the issue is resolved.
> h3. Note
> This caused the weekly Jenkins core release to fail on July 2, 2024. We have
> downgraded Maven Release Plugin to 3.0.1 in order to restore stability to our
> releases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7266) Remove maven-compat module
[ https://issues.apache.org/jira/browse/MNG-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862663#comment-17862663 ] ASF GitHub Bot commented on MNG-7266: - gnodet commented on PR #1487: URL: https://github.com/apache/maven/pull/1487#issuecomment-2205195453 > > > > I did investigate again and now I understand what actually happens: When I run current reporting plugins wich do _not_ depend on Maven Compat I still get CNFE, e.g., RepositorySystem or others because in [967d8fc](https://github.com/apache/maven/commit/967d8fc19cbb8a78410ceed70bd91c2e628da813) a bunch of classes were moved to Compat and are now gone. What apparantly was fine with Maven 3.x is now not possible with Maven 4. If all changes in [967d8fc](https://github.com/apache/maven/commit/967d8fc19cbb8a78410ceed70bd91c2e628da813) are correct then those plugins aren't compatible with 4 and need a separate branch for 4. > > > > > > > > > Do you know which class is required and not found ? > > > > > > Oh, sorry `RepositorySystem`. For those plugins, a dependency on maven-compat needs to be added afaik. > > This means that compat cannot be removed for those plugins? How to proceed in case? There are three ways: * add maven-compat dependency to the plugins * migrate the plugins to use resolver and require Maven 3.6.x * migrate the plugin to 4.x API and require Maven 4.x The first one, means that we can't just delete the code now, but we can stop providing it by default in the Maven distribution. > Remove maven-compat module > -- > > Key: MNG-7266 > URL: https://issues.apache.org/jira/browse/MNG-7266 > Project: Maven > Issue Type: Sub-task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.x-candidate > > > Maven-core does not depend on maven-compat anymore (runtime or compile time). > Do we want to carry it over up to 4.0.0 and delete it in 4.1.0, or do we > want to drop it before 4.0.0 ? > [~cstamas] [~olamy] [~romain.manni-bucau] [~sjaranowski] and others... ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRELEASE-1152) Unable to fine properties
Vahid created MRELEASE-1152: --- Summary: Unable to fine properties Key: MRELEASE-1152 URL: https://issues.apache.org/jira/browse/MRELEASE-1152 Project: Maven Release Plugin Issue Type: Bug Components: prepare-with-pom Affects Versions: 3.1.0, 3.0.1 Reporter: Vahid Hello, I have a multi-module project that I want to use maven release plugin for it. In some sub-modules there are some properties but they are somehow ignored. I debugged the code and I found that in class *org.apache.maven.shared.release.transform.jdom2.JDomProperties* line *49* (inside constructor method) only Object is being created and no key/value is passed. So, *modelTarget.getProperties() == null* is false but *modelTarget.getProperties().isEmpty()* is true. We can say that all properties in the pom.xml file are ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MRELEASE-1151) Maven Release Plugin fails to adjust version (regression in 3.1.0)
[ https://issues.apache.org/jira/browse/MRELEASE-1151 ]
Basil Crow deleted comment on MRELEASE-1151:
--
was (Author: basil):
See https://github.com/jenkinsci/jenkins/commits/master for the details — our
2.465 release failed, while 2.466 succeeded.
https://github.com/jenkinsci/jenkins/commit/dd7a6874e6704bb7163a98c728b3b11a78be53f6
failed to update the version, creating a {{jenkins-2.465}} tag whose version
was after interpolation (incorrectly) 2.465-SNAPSHOT. I believe this was then
rejected by Artifactory in the deployment phase, since snapshots aren't allowed
in our release repository. Note that this worked in 3.0.1. After that
https://github.com/jenkinsci/jenkins/commit/d0e050b90f6926f2e56d7e634deed2bc57d83d54
set the version after interpolation (incorrectly) to 2.465-SNAPSHOT-SNAPSHOT.
You can compare these two commits with the corresponding two commits for 2.466
or 2.464 to see how things are working with 3.0.1.
> Maven Release Plugin fails to adjust version (regression in 3.1.0)
> --
>
> Key: MRELEASE-1151
> URL: https://issues.apache.org/jira/browse/MRELEASE-1151
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.1.0
> Environment: Ubuntu 22.04.4 LTS x86_64
>Reporter: Basil Crow
>Priority: Blocker
>
> h3. Steps to reproduce
> # Run {{git clone [https://github.com/jenkinsci/text-finder-plugin.git]}}
> # Using Java 17 and Maven 3.9.8, run {{mvn release:prepare
> -DpushChanges=false}}
> h3. Expected results
> {panel:title=Note}
> These are the _actual_ results with Maven Release Plugin 3.0.1.
> {panel}
> The {{[maven-release-plugin] prepare release}} commit adjusts
> {{${scmTag}}} to e.g. {{text-finder-1.29}} *and*
> adjusts {{${revision}${changelist}}} to e.g.
> {{{}1.29{}}}.
> h3. Actual results
> Starting with Maven Release Plugin 3.1.0, the {{[maven-release-plugin]
> prepare release}} commit still adjusts {{${scmTag}}} to e.g.
> {{{}text-finder-1.29{}}}, but it *fails to adjust*
> {{${revision}${changelist}}} to e.g.
> {{1.29}} as expected. After this, the release subsequently
> fails.
> h3. Evaluation
> This regression is caused by the changes to {{AbstractRewritePomsPhase}} made
> in MRELEASE-1109. When these changes are reverted, the issue is resolved.
> h3. Note
> This caused the weekly Jenkins core release to fail on July 2, 2024. We have
> downgraded Maven Release Plugin to 3.0.1 in order to restore stability to our
> releases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1151) Maven Release Plugin fails to adjust version (regression in 3.1.0)
[
https://issues.apache.org/jira/browse/MRELEASE-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862658#comment-17862658
]
Basil Crow commented on MRELEASE-1151:
--
See https://github.com/jenkinsci/jenkins/commits/master for the details — our
2.465 release failed, while 2.466 succeeded.
https://github.com/jenkinsci/jenkins/commit/dd7a6874e6704bb7163a98c728b3b11a78be53f6
failed to update the version, creating a {{jenkins-2.465}} tag whose version
was after interpolation (incorrectly) 2.465-SNAPSHOT. I believe this was then
rejected by Artifactory in the deployment phase, since snapshots aren't allowed
in our release repository. Note that this worked in 3.0.1. After that
https://github.com/jenkinsci/jenkins/commit/d0e050b90f6926f2e56d7e634deed2bc57d83d54
set the version after interpolation (incorrectly) to 2.465-SNAPSHOT-SNAPSHOT.
You can compare these two commits with the corresponding two commits for 2.466
or 2.464 to see how things are working with 3.0.1.
> Maven Release Plugin fails to adjust version (regression in 3.1.0)
> --
>
> Key: MRELEASE-1151
> URL: https://issues.apache.org/jira/browse/MRELEASE-1151
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.1.0
> Environment: Ubuntu 22.04.4 LTS x86_64
>Reporter: Basil Crow
>Priority: Blocker
>
> h3. Steps to reproduce
> # Run {{git clone [https://github.com/jenkinsci/text-finder-plugin.git]}}
> # Using Java 17 and Maven 3.9.8, run {{mvn release:prepare
> -DpushChanges=false}}
> h3. Expected results
> {panel:title=Note}
> These are the _actual_ results with Maven Release Plugin 3.0.1.
> {panel}
> The {{[maven-release-plugin] prepare release}} commit adjusts
> {{${scmTag}}} to e.g. {{text-finder-1.29}} *and*
> adjusts {{${revision}${changelist}}} to e.g.
> {{{}1.29{}}}.
> h3. Actual results
> Starting with Maven Release Plugin 3.1.0, the {{[maven-release-plugin]
> prepare release}} commit still adjusts {{${scmTag}}} to e.g.
> {{{}text-finder-1.29{}}}, but it *fails to adjust*
> {{${revision}${changelist}}} to e.g.
> {{1.29}} as expected. After this, the release subsequently
> fails.
> h3. Evaluation
> This regression is caused by the changes to {{AbstractRewritePomsPhase}} made
> in MRELEASE-1109. When these changes are reverted, the issue is resolved.
> h3. Note
> This caused the weekly Jenkins core release to fail on July 2, 2024. We have
> downgraded Maven Release Plugin to 3.0.1 in order to restore stability to our
> releases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1151) Maven Release Plugin fails to adjust version (regression in 3.1.0)
[
https://issues.apache.org/jira/browse/MRELEASE-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862657#comment-17862657
]
Basil Crow commented on MRELEASE-1151:
--
See https://github.com/jenkinsci/jenkins/commits/master for the details — our
2.465 release failed, while 2.466 succeeded.
https://github.com/jenkinsci/jenkins/commit/dd7a6874e6704bb7163a98c728b3b11a78be53f6
failed to update the version, creating a {{jenkins-2.465}} tag whose version
was after interpolation (incorrectly) 2.465-SNAPSHOT. I believe this was then
rejected by Artifactory in the deployment phase, since snapshots aren't allowed
in our release repository. Note that this worked in 3.0.1. After that
https://github.com/jenkinsci/jenkins/commit/d0e050b90f6926f2e56d7e634deed2bc57d83d54
set the version after interpolation (incorrectly) to 2.465-SNAPSHOT-SNAPSHOT.
You can compare these two commits with the corresponding two commits for 2.466
or 2.464 to see how things are working with 3.0.1.
> Maven Release Plugin fails to adjust version (regression in 3.1.0)
> --
>
> Key: MRELEASE-1151
> URL: https://issues.apache.org/jira/browse/MRELEASE-1151
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.1.0
> Environment: Ubuntu 22.04.4 LTS x86_64
>Reporter: Basil Crow
>Priority: Blocker
>
> h3. Steps to reproduce
> # Run {{git clone [https://github.com/jenkinsci/text-finder-plugin.git]}}
> # Using Java 17 and Maven 3.9.8, run {{mvn release:prepare
> -DpushChanges=false}}
> h3. Expected results
> {panel:title=Note}
> These are the _actual_ results with Maven Release Plugin 3.0.1.
> {panel}
> The {{[maven-release-plugin] prepare release}} commit adjusts
> {{${scmTag}}} to e.g. {{text-finder-1.29}} *and*
> adjusts {{${revision}${changelist}}} to e.g.
> {{{}1.29{}}}.
> h3. Actual results
> Starting with Maven Release Plugin 3.1.0, the {{[maven-release-plugin]
> prepare release}} commit still adjusts {{${scmTag}}} to e.g.
> {{{}text-finder-1.29{}}}, but it *fails to adjust*
> {{${revision}${changelist}}} to e.g.
> {{1.29}} as expected. After this, the release subsequently
> fails.
> h3. Evaluation
> This regression is caused by the changes to {{AbstractRewritePomsPhase}} made
> in MRELEASE-1109. When these changes are reverted, the issue is resolved.
> h3. Note
> This caused the weekly Jenkins core release to fail on July 2, 2024. We have
> downgraded Maven Release Plugin to 3.0.1 in order to restore stability to our
> releases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1151) Maven Release Plugin fails to adjust version (regression in 3.1.0)
[
https://issues.apache.org/jira/browse/MRELEASE-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862656#comment-17862656
]
Marcel Stör commented on MRELEASE-1151:
---
I'm the author of MRELEASE-1109. What you state as expected i.e. rewriting
{quote}${revision}${changelist} to e.g.
1.29{quote}
was completely unexpected IMO. It shouldn't replace the placeholder but only
update its value.
{quote}After this, the release subsequently fails.{quote}
How so, what happens?
> Maven Release Plugin fails to adjust version (regression in 3.1.0)
> --
>
> Key: MRELEASE-1151
> URL: https://issues.apache.org/jira/browse/MRELEASE-1151
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.1.0
> Environment: Ubuntu 22.04.4 LTS x86_64
>Reporter: Basil Crow
>Priority: Blocker
>
> h3. Steps to reproduce
> # Run {{git clone [https://github.com/jenkinsci/text-finder-plugin.git]}}
> # Using Java 17 and Maven 3.9.8, run {{mvn release:prepare
> -DpushChanges=false}}
> h3. Expected results
> {panel:title=Note}
> These are the _actual_ results with Maven Release Plugin 3.0.1.
> {panel}
> The {{[maven-release-plugin] prepare release}} commit adjusts
> {{${scmTag}}} to e.g. {{text-finder-1.29}} *and*
> adjusts {{${revision}${changelist}}} to e.g.
> {{{}1.29{}}}.
> h3. Actual results
> Starting with Maven Release Plugin 3.1.0, the {{[maven-release-plugin]
> prepare release}} commit still adjusts {{${scmTag}}} to e.g.
> {{{}text-finder-1.29{}}}, but it *fails to adjust*
> {{${revision}${changelist}}} to e.g.
> {{1.29}} as expected. After this, the release subsequently
> fails.
> h3. Evaluation
> This regression is caused by the changes to {{AbstractRewritePomsPhase}} made
> in MRELEASE-1109. When these changes are reverted, the issue is resolved.
> h3. Note
> This caused the weekly Jenkins core release to fail on July 2, 2024. We have
> downgraded Maven Release Plugin to 3.0.1 in order to restore stability to our
> releases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}
[
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862610#comment-17862610
]
ASF GitHub Bot commented on MRELEASE-1109:
--
basil commented on code in PR #201:
URL: https://github.com/apache/maven-release/pull/201#discussion_r1663233072
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -96,7 +96,7 @@ public abstract class AbstractRewritePomsPhase extends
AbstractReleasePhase impl
* Regular expression pattern matching Maven expressions (i.e. references
to Maven properties).
* The first group selects the property name the expression refers to.
*/
-private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+)\\}");
+private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+?)\\}");
Review Comment:
Causes [MRELEASE-1151](https://issues.apache.org/jira/browse/MRELEASE-1151).
This caused the weekly Jenkins core release to fail on July 2, 2024. We have
downgraded Maven Release Plugin to 3.0.1 in order to restore stability to our
releases.
> update-versions removes the CI-friendly ${revisions}
>
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.1.0
>
>
> Given: a project using CI-friendly versions as per
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
> ${revision}
> ...
>
> 1.0.0-SNAPSHOT
>
> {code}
> If I run {{mvn release:update-versions}} (with or without
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change
> the {{$revision}} property. Instead it blindly replaces
> {{${revision}}} with the hard-coded version set on the CLI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}
[
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862609#comment-17862609
]
Basil Crow commented on MRELEASE-1109:
--
Causes MRELEASE-1151.
> update-versions removes the CI-friendly ${revisions}
>
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.1.0
>
>
> Given: a project using CI-friendly versions as per
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
> ${revision}
> ...
>
> 1.0.0-SNAPSHOT
>
> {code}
> If I run {{mvn release:update-versions}} (with or without
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change
> the {{$revision}} property. Instead it blindly replaces
> {{${revision}}} with the hard-coded version set on the CLI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRELEASE-1151) Maven Release Plugin fails to adjust version (regression in 3.1.0)
Basil Crow created MRELEASE-1151:
Summary: Maven Release Plugin fails to adjust version (regression
in 3.1.0)
Key: MRELEASE-1151
URL: https://issues.apache.org/jira/browse/MRELEASE-1151
Project: Maven Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 3.1.0
Environment: Ubuntu 22.04.4 LTS x86_64
Reporter: Basil Crow
h3. Steps to reproduce
# Run {{git clone [https://github.com/jenkinsci/text-finder-plugin.git]}}
# Using Java 17 and Maven 3.9.8, run {{mvn release:prepare
-DpushChanges=false}}
h3. Expected results
{panel:title=Note}
These are the _actual_ results with Maven Release Plugin 3.0.1.
{panel}
The {{[maven-release-plugin] prepare release}} commit adjusts
{{${scmTag}}} to e.g. {{text-finder-1.29}} *and* adjusts
{{${revision}${changelist}}} to e.g.
{{{}1.29{}}}.
h3. Actual results
Starting with Maven Release Plugin 3.1.0, the {{[maven-release-plugin] prepare
release}} commit still adjusts {{${scmTag}}} to e.g.
{{{}text-finder-1.29{}}}, but it *fails to adjust*
{{${revision}${changelist}}} to e.g.
{{1.29}} as expected. After this, the release subsequently
fails.
h3. Evaluation
This regression is caused by the changes to {{AbstractRewritePomsPhase}} made
in MRELEASE-1109. When these changes are reverted, the issue is resolved.
h3. Note
This caused the weekly Jenkins core release to fail on July 2, 2024. We have
downgraded Maven Release Plugin to 3.0.1 in order to restore stability to our
releases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8169) MINGW support requires --add-opens java.base/java.lang=ALL-UNNAMED
Rostislav Krasny created MNG-8169: - Summary: MINGW support requires --add-opens java.base/java.lang=ALL-UNNAMED Key: MNG-8169 URL: https://issues.apache.org/jira/browse/MNG-8169 Project: Maven Issue Type: Bug Components: Core Affects Versions: 3.9.8, 3.9.7 Reporter: Rostislav Krasny Running any Maven command on MINGW64 terminal of Git for Windows and probably in several other UNIX-mimicking environments prints out the "MINGW support requires --add-opens java.base/java.lang=ALL-UNNAMED" error message (can be printed several times during one Maven command) and can't get the right width of the terminal. This bug came from the Jansi dependency after it was upgraded from 2.4.0 to 2.4.1 version. For more information please see my bug report and my pull request in the Jansi project's GitHub: [https://github.com/fusesource/jansi/issues/290] [https://github.com/fusesource/jansi/pull/291] Since many developers use Maven on Windows together with Git for Windows and on its Git Bash environment based on MINGW this bug is important, in my opinion. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2105) Failsafe report size increased with version upgrade from 2.17 to 2.22.2
[ https://issues.apache.org/jira/browse/SUREFIRE-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-2105: - Issue Type: Bug (was: Improvement) > Failsafe report size increased with version upgrade from 2.17 to 2.22.2 > --- > > Key: SUREFIRE-2105 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2105 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.22.2, 3.0.0-M5, 3.0.0-M6 >Reporter: parita jivani >Priority: Major > > Java test project we were using surefire/failsafe version 2.17 and upgraded > it to 2.22.2. > After upgrade failsafe report size has increased from approx. 7-8KB to > 180-200KB. > Properties, "java.class.path" and "surefire.test.class.path" are having large > class path values. If we can get property configuration option like mask > bigger properties values of configuration to unable or disable according to > requirement would really help to resolve size issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2105) Failsafe report size increased with version upgrade from 2.17 to 2.22.2
[ https://issues.apache.org/jira/browse/SUREFIRE-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-2105: - Fix Version/s: 3.3.1 > Failsafe report size increased with version upgrade from 2.17 to 2.22.2 > --- > > Key: SUREFIRE-2105 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2105 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.22.2, 3.0.0-M5, 3.0.0-M6 >Reporter: parita jivani >Assignee: Michael Osipov >Priority: Major > Fix For: 3.3.1 > > > Java test project we were using surefire/failsafe version 2.17 and upgraded > it to 2.22.2. > After upgrade failsafe report size has increased from approx. 7-8KB to > 180-200KB. > Properties, "java.class.path" and "surefire.test.class.path" are having large > class path values. If we can get property configuration option like mask > bigger properties values of configuration to unable or disable according to > requirement would really help to resolve size issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SUREFIRE-2105) Failsafe report size increased with version upgrade from 2.17 to 2.22.2
[ https://issues.apache.org/jira/browse/SUREFIRE-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned SUREFIRE-2105: Assignee: Michael Osipov > Failsafe report size increased with version upgrade from 2.17 to 2.22.2 > --- > > Key: SUREFIRE-2105 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2105 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.22.2, 3.0.0-M5, 3.0.0-M6 >Reporter: parita jivani >Assignee: Michael Osipov >Priority: Major > > Java test project we were using surefire/failsafe version 2.17 and upgraded > it to 2.22.2. > After upgrade failsafe report size has increased from approx. 7-8KB to > 180-200KB. > Properties, "java.class.path" and "surefire.test.class.path" are having large > class path values. If we can get property configuration option like mask > bigger properties values of configuration to unable or disable according to > requirement would really help to resolve size issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-1360) Ability to disable properties for successfully passed tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-1360: - Summary: Ability to disable properties for successfully passed tests (was: Option to disable properties dumping in StatelessXmlReporter) > Ability to disable properties for successfully passed tests > --- > > Key: SUREFIRE-1360 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1360 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin, xml > generation >Reporter: Jaromir Hamala >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.3.1 > > > I'd like to have an option to disable dumping (all?) properties into XML > reports. > Reasoning: > The same properties are repeated in 10,000's of XML test reports. > In many cases this is unnecessary. It's painful when a test environment has > I/O throttling - think of AWS with I/O burst credits. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-1360) Option to disable properties dumping in StatelessXmlReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-1360: - Component/s: xml generation > Option to disable properties dumping in StatelessXmlReporter > > > Key: SUREFIRE-1360 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1360 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin, xml > generation >Reporter: Jaromir Hamala >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.3.1 > > > I'd like to have an option to disable dumping (all?) properties into XML > reports. > Reasoning: > The same properties are repeated in 10,000's of XML test reports. > In many cases this is unnecessary. It's painful when a test environment has > I/O throttling - think of AWS with I/O burst credits. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-1934) Ability to disable system-out/system-err for successfully passed tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-1934: - Component/s: Maven Failsafe Plugin > Ability to disable system-out/system-err for successfully passed tests > -- > > Key: SUREFIRE-1934 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1934 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin, xml > generation >Affects Versions: 3.0.0-M5 >Reporter: Andrey Turbanov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.3.1 > > > After SUREFIRE-1744 surefire-plugin always reports system-out/system-err even > for successfully passed test. A lot of old projects with big amount of tests > now have to deal with huge output. > I think there should be option to disable new behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-1360) Option to disable properties dumping in StatelessXmlReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-1360: - Fix Version/s: 3.3.1 > Option to disable properties dumping in StatelessXmlReporter > > > Key: SUREFIRE-1360 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1360 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Jaromir Hamala >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.3.1 > > > I'd like to have an option to disable dumping (all?) properties into XML > reports. > Reasoning: > The same properties are repeated in 10,000's of XML test reports. > In many cases this is unnecessary. It's painful when a test environment has > I/O throttling - think of AWS with I/O burst credits. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MINVOKER-339) Don't print or log the plugin's stack trace on verification fail
[
https://issues.apache.org/jira/browse/MINVOKER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862578#comment-17862578
]
Slawomir Jaranowski commented on MINVOKER-339:
--
Can you show en example project ...
I think that stack is printed with {{mvn -e }}
> Don't print or log the plugin's stack trace on verification fail
>
>
> Key: MINVOKER-339
> URL: https://issues.apache.org/jira/browse/MINVOKER-339
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Typical output on a failing IT. The stack trace is unhelpful and pointless
> log junk. It does not point to the actual failing test, why and how it
> failed, or its output (which is in fact not included and should be, but
> that's a separate issue.) Instead all it shows is a stack trace of the code
> from Maven and the maven-invoker-plugin that ran the code. This is *not* the
> failing code. This is only the code that invoked the failing code, and this
> code executed successfully.
> This code did not fail and is not the cause of the bug, nor is it helpful in
> diagnosing the bug. The maven-invoker plugin executed successfully and
> correctly detected a failing integration test. Its stack trace simply
> obscures the real problem and gets in the way of the developer. Don't print
> it.
> {{*** end build.log for: verify-fail/pom.xml ***
> Error: -
> Error:
> [INFO] -
> [INFO] Build Summary:
> [INFO] Passed: 8, Failed: 1, Errors: 0, Skipped: 0
> [INFO] -
> Error: The following builds failed:
> Error: * verify-fail/pom.xml
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 53.844 s
> [INFO] Finished at: 2023-06-03T10:58:12Z
> [INFO]
>
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-invoker-plugin:3.3.0:verify (integration-test)
> on project maven-jarsigner-plugin: 1 build failed. See console output above
> for details. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-invoker-plugin:3.3.0:verify
> (integration-test) on project maven-jarsigner-plugin: 1 build failed. See
> console output above for details.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:375)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:351)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:171)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:163)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:298)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at
[jira] [Commented] (MNG-7266) Remove maven-compat module
[ https://issues.apache.org/jira/browse/MNG-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862526#comment-17862526 ] ASF GitHub Bot commented on MNG-7266: - michael-o commented on PR #1487: URL: https://github.com/apache/maven/pull/1487#issuecomment-2203132098 > > > > > > These two: > > > > > > > > > > > > * maven-plugin-tools/maven-plugin-plugin > > > > > > * maven-project-info-reports-plugin > > > > > > > > > > > > > > > maven-plugin-tools/maven-plugin-plugin does NOT depend on maven-compat, does it? Also, it contains traces of archaic (Maven2 times) when pom was considered "metadata" and plugin had to maintain maven-metadata.xml as well (something not needed since Resolver 1.9.x, as all data deployed generally are "artifacts", no more "metadata" to be handled by client code needed). Unsure what to be done here, maybe just bite the bullet, and raise the m-p-p prerequisite to 3.9.x (this would raise _build time_ Maven requirement for all built plugins, but not runtime requirements) and drop all this cruft. > > > > > Am looking into the other one. > > > > > EDIT: the other one still uses MAT so convert it to resolver? ... and shared dep tree that is also to be dropped/deprecated. so a LOT of deprecated stuff... > > > > > > > > > > > > We could also switch them directly to the Maven 4 API... > > > > > > > > > I'd prefer to solve this for 3.x as well to make easier for us. > > > > > > We won't be able to get rid of maven-compat in Maven 3.x branch. > > Also fwiw, m-plugin-p does not depend on maven-compat or MAT anymore (and still supports Maven 3 plugins for now). But that is on m-plugin-tools on master, no? The 3.x branch will remain as-is in this regard? > Remove maven-compat module > -- > > Key: MNG-7266 > URL: https://issues.apache.org/jira/browse/MNG-7266 > Project: Maven > Issue Type: Sub-task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.x-candidate > > > Maven-core does not depend on maven-compat anymore (runtime or compile time). > Do we want to carry it over up to 4.0.0 and delete it in 4.1.0, or do we > want to drop it before 4.0.0 ? > [~cstamas] [~olamy] [~romain.manni-bucau] [~sjaranowski] and others... ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7266) Remove maven-compat module
[ https://issues.apache.org/jira/browse/MNG-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862529#comment-17862529 ] ASF GitHub Bot commented on MNG-7266: - gnodet commented on PR #1487: URL: https://github.com/apache/maven/pull/1487#issuecomment-2203324239 > > > > > > > These two: > > > > > > > > > > > > > > * maven-plugin-tools/maven-plugin-plugin > > > > > > > * maven-project-info-reports-plugin > > > > > > > > > > > > > > > > > > maven-plugin-tools/maven-plugin-plugin does NOT depend on maven-compat, does it? Also, it contains traces of archaic (Maven2 times) when pom was considered "metadata" and plugin had to maintain maven-metadata.xml as well (something not needed since Resolver 1.9.x, as all data deployed generally are "artifacts", no more "metadata" to be handled by client code needed). Unsure what to be done here, maybe just bite the bullet, and raise the m-p-p prerequisite to 3.9.x (this would raise _build time_ Maven requirement for all built plugins, but not runtime requirements) and drop all this cruft. > > > > > > Am looking into the other one. > > > > > > EDIT: the other one still uses MAT so convert it to resolver? ... and shared dep tree that is also to be dropped/deprecated. so a LOT of deprecated stuff... > > > > > > > > > > > > > > > We could also switch them directly to the Maven 4 API... > > > > > > > > > > > > I'd prefer to solve this for 3.x as well to make easier for us. > > > > > > > > > We won't be able to get rid of maven-compat in Maven 3.x branch. > > > > > > Also fwiw, m-plugin-p does not depend on maven-compat or MAT anymore (and still supports Maven 3 plugins for now). > > But that is on m-plugin-tools on master, no? The 3.x branch will remain as-is in this regard? No, 3.x is free of those too afaik ``` [INFO] -< org.apache.maven.plugins:maven-plugin-plugin >- [INFO] Building Maven Plugin Plugin 3.13.2-SNAPSHOT [INFO] from pom.xml [INFO] -[ maven-plugin ]- [INFO] [INFO] - > Remove maven-compat module > -- > > Key: MNG-7266 > URL: https://issues.apache.org/jira/browse/MNG-7266 > Project: Maven > Issue Type: Sub-task >Reporter: Guillaume Nodet > Priority: Major > Fix For: 4.0.x-candidate > > > Maven-core does not depend on maven-compat anymore (runtime or compile time). > Do we want to carry it over up to 4.0.0 and delete it in 4.1.0, or do we > want to drop it before 4.0.0 ? > [~cstamas] [~olamy] [~romain.manni-bucau] [~sjaranowski] and others... ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7266) Remove maven-compat module
[ https://issues.apache.org/jira/browse/MNG-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862525#comment-17862525 ] ASF GitHub Bot commented on MNG-7266: - michael-o commented on PR #1487: URL: https://github.com/apache/maven/pull/1487#issuecomment-2203130039 > > > > > These two: > > > > > > > > > > * maven-plugin-tools/maven-plugin-plugin > > > > > * maven-project-info-reports-plugin > > > > > > > > > > > > maven-plugin-tools/maven-plugin-plugin does NOT depend on maven-compat, does it? Also, it contains traces of archaic (Maven2 times) when pom was considered "metadata" and plugin had to maintain maven-metadata.xml as well (something not needed since Resolver 1.9.x, as all data deployed generally are "artifacts", no more "metadata" to be handled by client code needed). Unsure what to be done here, maybe just bite the bullet, and raise the m-p-p prerequisite to 3.9.x (this would raise _build time_ Maven requirement for all built plugins, but not runtime requirements) and drop all this cruft. > > > > Am looking into the other one. > > > > EDIT: the other one still uses MAT so convert it to resolver? ... and shared dep tree that is also to be dropped/deprecated. so a LOT of deprecated stuff... > > > > > > > > > We could also switch them directly to the Maven 4 API... > > > > > > I'd prefer to solve this for 3.x as well to make easier for us. > > We won't be able to get rid of maven-compat in Maven 3.x branch. Deleting no, but we cannot also replace the code to Resolver with 3.6.3 baseline? > Remove maven-compat module > -- > > Key: MNG-7266 > URL: https://issues.apache.org/jira/browse/MNG-7266 > Project: Maven > Issue Type: Sub-task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.x-candidate > > > Maven-core does not depend on maven-compat anymore (runtime or compile time). > Do we want to carry it over up to 4.0.0 and delete it in 4.1.0, or do we > want to drop it before 4.0.0 ? > [~cstamas] [~olamy] [~romain.manni-bucau] [~sjaranowski] and others... ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINVOKER-339) Don't print or log the plugin's stack trace on verification fail
[
https://issues.apache.org/jira/browse/MINVOKER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MINVOKER-339:
---
Summary: Don't print or log the plugin's stack trace on verification fail
(was: Don't print the plugin's stack trace on verification fail)
> Don't print or log the plugin's stack trace on verification fail
>
>
> Key: MINVOKER-339
> URL: https://issues.apache.org/jira/browse/MINVOKER-339
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Typical output on a failing IT. The stack trace is unhelpful and pointless
> log junk. It does not point to the actual failing test, why and how it
> failed, or its output (which is in fact not included and should be, but
> that's a separate issue.) Instead all it shows is a stack trace of the code
> from Maven and the maven-invoker-plugin that ran the code. This is *not* the
> failing code. This is only the code that invoked the failing code, and this
> code executed successfully.
> This code did not fail and is not the cause of the bug, nor is it helpful in
> diagnosing the bug. The maven-invoker plugin executed successfully and
> correctly detected a failing integration test. Its stack trace simply
> obscures the real problem and gets in the way of the developer. Don't print
> it.
> {{*** end build.log for: verify-fail/pom.xml ***
> Error: -
> Error:
> [INFO] -
> [INFO] Build Summary:
> [INFO] Passed: 8, Failed: 1, Errors: 0, Skipped: 0
> [INFO] -
> Error: The following builds failed:
> Error: * verify-fail/pom.xml
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 53.844 s
> [INFO] Finished at: 2023-06-03T10:58:12Z
> [INFO]
>
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-invoker-plugin:3.3.0:verify (integration-test)
> on project maven-jarsigner-plugin: 1 build failed. See console output above
> for details. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-invoker-plugin:3.3.0:verify
> (integration-test) on project maven-jarsigner-plugin: 1 build failed. See
> console output above for details.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:375)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:351)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:171)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:163)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:298)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at
[jira] [Commented] (MINVOKER-339) Don't print the plugin's stack trace on verification fail
[
https://issues.apache.org/jira/browse/MINVOKER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862417#comment-17862417
]
Elliotte Rusty Harold commented on MINVOKER-339:
I don't think so. Per docs< streamLogsOnFailures>
Set to true to output build.log to mojo log in case of failed jobs
This info shouldn't be in the build.log. There is no reason to log stack traces
for correctly executing code, anywhere.
> Don't print the plugin's stack trace on verification fail
> -
>
> Key: MINVOKER-339
> URL: https://issues.apache.org/jira/browse/MINVOKER-339
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Typical output on a failing IT. The stack trace is unhelpful and pointless
> log junk. It does not point to the actual failing test, why and how it
> failed, or its output (which is in fact not included and should be, but
> that's a separate issue.) Instead all it shows is a stack trace of the code
> from Maven and the maven-invoker-plugin that ran the code. This is *not* the
> failing code. This is only the code that invoked the failing code, and this
> code executed successfully.
> This code did not fail and is not the cause of the bug, nor is it helpful in
> diagnosing the bug. The maven-invoker plugin executed successfully and
> correctly detected a failing integration test. Its stack trace simply
> obscures the real problem and gets in the way of the developer. Don't print
> it.
> {{*** end build.log for: verify-fail/pom.xml ***
> Error: -
> Error:
> [INFO] -
> [INFO] Build Summary:
> [INFO] Passed: 8, Failed: 1, Errors: 0, Skipped: 0
> [INFO] -
> Error: The following builds failed:
> Error: * verify-fail/pom.xml
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 53.844 s
> [INFO] Finished at: 2023-06-03T10:58:12Z
> [INFO]
>
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-invoker-plugin:3.3.0:verify (integration-test)
> on project maven-jarsigner-plugin: 1 build failed. See console output above
> for details. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-invoker-plugin:3.3.0:verify
> (integration-test) on project maven-jarsigner-plugin: 1 build failed. See
> console output above for details.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:375)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:351)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:171)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:163)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:298)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
[jira] [Updated] (MCOMPILER-595) Make -parameters enabled by default
[ https://issues.apache.org/jira/browse/MCOMPILER-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MCOMPILER-595: -- Summary: Make -parameters enabled by default (was: Make -parameter enabled by default) > Make -parameters enabled by default > --- > > Key: MCOMPILER-595 > URL: https://issues.apache.org/jira/browse/MCOMPILER-595 > Project: Maven Compiler Plugin > Issue Type: Wish >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0 > > > More and more frameworks rely on reflective access to parameter names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCOMPILER-595) Make -parameter enabled by default
Tamas Cservenak created MCOMPILER-595: - Summary: Make -parameter enabled by default Key: MCOMPILER-595 URL: https://issues.apache.org/jira/browse/MCOMPILER-595 Project: Maven Compiler Plugin Issue Type: Wish Reporter: Tamas Cservenak Fix For: 4.0.0 More and more frameworks rely on reflective access to parameter names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2203) In pom.xml, the configurationParameters configuration junit.platform.launcher.interceptors.enabled does not work
[
https://issues.apache.org/jira/browse/SUREFIRE-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862394#comment-17862394
]
Hengyunabc Chen commented on SUREFIRE-2203:
---
[~marcphilipp] https://github.com/junit-team/junit5/issues/3877
> In pom.xml, the configurationParameters configuration
> junit.platform.launcher.interceptors.enabled does not work
>
>
> Key: SUREFIRE-2203
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2203
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Reporter: Hengyunabc Chen
>Priority: Trivial
> Fix For: waiting-for-feedback
>
>
> In pom.xml, the configuration
> {{junit.platform.launcher.interceptors.enabled}} does not work.
> The following configuration does not take effect:
> {code:java}
>
> maven-surefire-plugin
> 3.1.2
>
>
>
> junit.platform.launcher.interceptors.enabled=true
>
>
> {code}
>
> The following configuration can work:
> {code:java}
>
> maven-surefire-plugin
> 3.1.2
>
>
>
> true
>
> {code}
>
> Or configuring it in the {{junit-platform.properties}} file will also work.
> Reference documentation:
> *
> [https://junit.org/junit5/docs/snapshot/user-guide/#launcher-api-launcher-interceptors-custom]
> *
> [https://junit.org/junit5/docs/snapshot/user-guide/#running-tests-build-maven-config-params]
> *
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#configuration-parameters]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MSHADE-260) shading does not rewrite Lambda deserializers
[
https://issues.apache.org/jira/browse/MSHADE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862387#comment-17862387
]
Lorenzo Affetti edited comment on MSHADE-260 at 7/2/24 10:16 AM:
-
Hello people!
This bug seems quite a big deal and It happens to me also on version 3.2.4
(java11).
Is somebody working on this?
Is this fixed in later versions?
was (Author: JIRAUSER304233):
Hello people!
This bug seems quite a big deal and It happens to me also on version 3.2.4.
Is somebody working on this?
Is this fixed in later versions?
> shading does not rewrite Lambda deserializers
> -
>
> Key: MSHADE-260
> URL: https://issues.apache.org/jira/browse/MSHADE-260
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.1.0
> Environment: Java 8
>Reporter: James Moore
>Priority: Major
>
> In our spark applications, we've encountered issues around shading and
> lambdas. Where the javac inserted deserialization function ( included below )
> will not be updated to reflect the shaded libraries The relocation rule is
> the following
> {code:xml}
>
> com.google.protobuf
> com.google.protobuf.v3
>
> {code}
> But while the majority of the signatures are updated to
> com.google.protobuf.v3 in the class file, the following byte code shows the
> string where it is not.
> {code:java}
> (Ljava/lang/Class;Lorg/apache/hadoop/hbase/io/ImmutableBytesWritable;)Lcom/google/protobuf/Message
> {code}
> I believe this problem affects any shaded library which has a classed passed
> into a serialized lambda instance.
> {code:java}
> private static java.lang.Object
> $deserializeLambda$(java.lang.invoke.SerializedLambda);
> Code:
>0: aload_0
>1: invokevirtual #64 // Method
> java/lang/invoke/SerializedLambda.getImplMethodName:()Ljava/lang/String;
>4: astore_1
>5: iconst_m1
>6: istore_2
>7: aload_1
>8: invokevirtual #70 // Method
> java/lang/String.hashCode:()I
> 11: lookupswitch { // 1
> 1182156382: 28
>default: 39
> }
> 28: aload_1
> 29: ldc #71 // String
> lambda$convert$60ebd0cc$1
> 31: invokevirtual #75 // Method
> java/lang/String.equals:(Ljava/lang/Object;)Z
> 34: ifeq 39
> 37: iconst_0
> 38: istore_2
> 39: iload_2
> 40: lookupswitch { // 1
> 0: 60
>default: 143
> }
> 60: aload_0
> 61: invokevirtual #78 // Method
> java/lang/invoke/SerializedLambda.getImplMethodKind:()I
> 64: bipush6
> 66: if_icmpne 143
> 69: aload_0
> 70: invokevirtual #81 // Method
> java/lang/invoke/SerializedLambda.getFunctionalInterfaceClass:()Ljava/lang/String;
> 73: ldc #83 // String
> org/apache/spark/api/java/function/Function
> 75: invokevirtual #84 // Method
> java/lang/Object.equals:(Ljava/lang/Object;)Z
> 78: ifeq 143
> 81: aload_0
> 82: invokevirtual #87 // Method
> java/lang/invoke/SerializedLambda.getFunctionalInterfaceMethodName:()Ljava/lang/String;
> 85: ldc #88 // String call
> 87: invokevirtual #84 // Method
> java/lang/Object.equals:(Ljava/lang/Object;)Z
> 90: ifeq 143
> 93: aload_0
> 94: invokevirtual #91 // Method
> java/lang/invoke/SerializedLambda.getFunctionalInterfaceMethodSignature:()Ljava/lang/String;
> 97: ldc #92 // String
> (Ljava/lang/Object;)Ljava/lang/Object;
> 99: invokevirtual #84 // Method
> java/lang/Object.equals:(Ljava/lang/Object;)Z
> 102: ifeq 143
> 105: aload_0
> 106: invokevirtual #95 // Method
> java/lang/invoke/SerializedLambda.getImplClass:()Ljava/lang/String;
> 109: ldc #96 // String StockHubSpotClass
> 111: invokevirtual #84 // Method
> java/lang/Object.equals:(Ljava/lang/Object;)Z
> 114: ifeq 143
> 117: aload_0
> 118: invokevirtual #99 // Method
> java/lang/invoke/SerializedLambda.getImplMethodSignature:()Ljava/lang/String;
> 121: ldc
[jira] [Commented] (MSHADE-260) shading does not rewrite Lambda deserializers
[
https://issues.apache.org/jira/browse/MSHADE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862387#comment-17862387
]
Lorenzo Affetti commented on MSHADE-260:
Hello people!
This bug seems quite a big deal and It happens to me also on version 3.2.4.
Is somebody working on this?
Is this fixed in later versions?
> shading does not rewrite Lambda deserializers
> -
>
> Key: MSHADE-260
> URL: https://issues.apache.org/jira/browse/MSHADE-260
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.1.0
> Environment: Java 8
>Reporter: James Moore
>Priority: Major
>
> In our spark applications, we've encountered issues around shading and
> lambdas. Where the javac inserted deserialization function ( included below )
> will not be updated to reflect the shaded libraries The relocation rule is
> the following
> {code:xml}
>
> com.google.protobuf
> com.google.protobuf.v3
>
> {code}
> But while the majority of the signatures are updated to
> com.google.protobuf.v3 in the class file, the following byte code shows the
> string where it is not.
> {code:java}
> (Ljava/lang/Class;Lorg/apache/hadoop/hbase/io/ImmutableBytesWritable;)Lcom/google/protobuf/Message
> {code}
> I believe this problem affects any shaded library which has a classed passed
> into a serialized lambda instance.
> {code:java}
> private static java.lang.Object
> $deserializeLambda$(java.lang.invoke.SerializedLambda);
> Code:
>0: aload_0
>1: invokevirtual #64 // Method
> java/lang/invoke/SerializedLambda.getImplMethodName:()Ljava/lang/String;
>4: astore_1
>5: iconst_m1
>6: istore_2
>7: aload_1
>8: invokevirtual #70 // Method
> java/lang/String.hashCode:()I
> 11: lookupswitch { // 1
> 1182156382: 28
>default: 39
> }
> 28: aload_1
> 29: ldc #71 // String
> lambda$convert$60ebd0cc$1
> 31: invokevirtual #75 // Method
> java/lang/String.equals:(Ljava/lang/Object;)Z
> 34: ifeq 39
> 37: iconst_0
> 38: istore_2
> 39: iload_2
> 40: lookupswitch { // 1
> 0: 60
>default: 143
> }
> 60: aload_0
> 61: invokevirtual #78 // Method
> java/lang/invoke/SerializedLambda.getImplMethodKind:()I
> 64: bipush6
> 66: if_icmpne 143
> 69: aload_0
> 70: invokevirtual #81 // Method
> java/lang/invoke/SerializedLambda.getFunctionalInterfaceClass:()Ljava/lang/String;
> 73: ldc #83 // String
> org/apache/spark/api/java/function/Function
> 75: invokevirtual #84 // Method
> java/lang/Object.equals:(Ljava/lang/Object;)Z
> 78: ifeq 143
> 81: aload_0
> 82: invokevirtual #87 // Method
> java/lang/invoke/SerializedLambda.getFunctionalInterfaceMethodName:()Ljava/lang/String;
> 85: ldc #88 // String call
> 87: invokevirtual #84 // Method
> java/lang/Object.equals:(Ljava/lang/Object;)Z
> 90: ifeq 143
> 93: aload_0
> 94: invokevirtual #91 // Method
> java/lang/invoke/SerializedLambda.getFunctionalInterfaceMethodSignature:()Ljava/lang/String;
> 97: ldc #92 // String
> (Ljava/lang/Object;)Ljava/lang/Object;
> 99: invokevirtual #84 // Method
> java/lang/Object.equals:(Ljava/lang/Object;)Z
> 102: ifeq 143
> 105: aload_0
> 106: invokevirtual #95 // Method
> java/lang/invoke/SerializedLambda.getImplClass:()Ljava/lang/String;
> 109: ldc #96 // String StockHubSpotClass
> 111: invokevirtual #84 // Method
> java/lang/Object.equals:(Ljava/lang/Object;)Z
> 114: ifeq 143
> 117: aload_0
> 118: invokevirtual #99 // Method
> java/lang/invoke/SerializedLambda.getImplMethodSignature:()Ljava/lang/String;
> 121: ldc #101// String
> (Ljava/lang/Class;Lorg/apache/hadoop/hbase/io/ImmutableBytesWritable;)Lcom/google/protobuf/Message;
> 123: invokevirtual #84 // Method
> java/lang/Object.equals:(Ljava/lang/O
[jira] [Updated] (SUREFIRE-2250) Surefire Test Report Schema properties element is not consistent with the code
[
https://issues.apache.org/jira/browse/SUREFIRE-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SUREFIRE-2250:
-
Summary: Surefire Test Report Schema properties element is not consistent
with the code (was: Surefire Test Report Schema element properties is not
consistent with the code)
> Surefire Test Report Schema properties element is not consistent with the code
> --
>
> Key: SUREFIRE-2250
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2250
> Project: Maven Surefire
> Issue Type: Bug
> Components: xml generation
>Affects Versions: 3.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.3.1
>
>
> surefire-test-report.xsd defines:
> {code:xml}
>
> {code}
> but the Java code says:
> {code}
> private static void showProperties(XMLWriter xmlWriter, Map String> systemProperties) throws IOException {
> xmlWriter.startElement("properties");
> for (final Entry entry : systemProperties.entrySet())
> {
> final String key = entry.getKey();
> String value = entry.getValue();
> if (value == null) {
> value = "null";
> }
> xmlWriter.startElement("property");
> xmlWriter.addAttribute("name", key);
> xmlWriter.addAttribute("value", extraEscapeAttribute(value));
> xmlWriter.endElement();
> }
> xmlWriter.endElement();
> }
> {code}
> and is called only once in
> {{org.apache.maven.plugin.surefire.report.StatelessXmlReporter.testSetCompleted(WrappedReportEntry,
> TestSetStats)}}. This makes the schema definition wrong. Let's fix this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8098) Move m-plugin-plugin and m-plugin-testing into maven-core
[ https://issues.apache.org/jira/browse/MNG-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-8098. Fix Version/s: (was: 4.0.x-candidate) Resolution: Won't Fix > Move m-plugin-plugin and m-plugin-testing into maven-core > - > > Key: MNG-8098 > URL: https://issues.apache.org/jira/browse/MNG-8098 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Priority: Major > > With the Maven 4 API still being in flux, I think we should move the > maven-plugin-plugin support for 4.x plugins along with the test > infrastructure for those plugins in maven core, so that they would have the > same lifecycle than the API. > Especially now than Maven 4 targets JDK 17, supporting both Maven 3 and 4 in > the same plugin is a bit more difficult... and that would definitely clean > those two projects... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-572) Resolver-Supplier unusable in OSGi runtimes
[
https://issues.apache.org/jira/browse/MRESOLVER-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-572:
--
Affects Version/s: 2.0.0-alpha-11
(was: 2.0.0-beta-1)
> Resolver-Supplier unusable in OSGi runtimes
> ---
>
> Key: MRESOLVER-572
> URL: https://issues.apache.org/jira/browse/MRESOLVER-572
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 2.0.0-alpha-11, 1.9.20
>Reporter: Hannes Wellmann
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.0.0, 1.9.21, 2.0.0-beta-1
>
>
> The {{maven-resolver-supplier}} artifact cannot be used as bundle in an OSGi
> runtime because it uses and therefore imports internal packages from
> {{{}maven-resolver-impl{}}}. But those internal packages are not exported by
> {{maven-resolver-impl}} and therefore {{maven-resolver-supplier}} fails to
> resolve.
> In order to fix that I see two possible solutions:
> # Export (almost) all {{internal.impl}} packages from
> {{{}maven-resolver-impl{}}}.
> This would be the simpler solution (probably a one/two-liner in the
> bnd-maven-plugin config) but it means that at runtime those internal packages
> would be accessible.
> For Eclipse (PDE) there is the convention to mark 'internal' packages with
> the directive {{{};x-internal:=true{}}}, that this emits a warning at callers
> in the IDE but does not prohibit access. At runtime there is no in-between,
> either a package is exported or not.
> According to the doc at
> [package-level-contracts|https://maven.apache.org/resolver/api-compatibility.html#package-level-contracts]
> all packages in maven-resolver-impl are considered 'non-API' anyways
> regardless of if the only contain {{impl}} or {{{}internal.impl{}}}.
> Furthermore one is not prohibited to use elements from internal packages, but
> only cannot expect any compatibility between versions. So just exporting it,
> with a warning at callers (if x-internal is considered), sounds like a not
> too bad solution. And it would be similar to non OSGi situations where one
> can access everything available.
> # Split the supplier into two, an abstract _BasicSupplier_ that contains all
> code that touches the internal.impl elements and the already existing
> supplier that extends the _BasicSupplier_ and adds everything that's not
> available in resolver-impl, like elements from higher-level resolver modules
> or maven-core/model.
> For maven-resolver 1.9.20 I have checked it already and it would be possible.
> The BasicSupplier would only have to reside in an exported package.
> I haven't checked resolver 2.0 yet, but such BasicSupplier could also help to
> reduce the duplication's between the suppler for Maven 3 and 4.
> A BasicSupplier could also help third-party suppliers to reduce the
> depencency footprint without re-implementing everything if they have
> alternate means to the maven-core/model elements.
> What's the solution you prefer?
> Maybe approach two would only be suitable for resolver 2.0.x in order to also
> reduce code and for 1.9x. only approach one would be sufficient? Approach one
> would probably also be suitable for 2.0.x since it gives consumers the
> possible to access internals if they really want to.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-417) Create HTTP test suite a la "TCK"
[ https://issues.apache.org/jira/browse/MRESOLVER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-417: -- Fix Version/s: 2.0.1 > Create HTTP test suite a la "TCK" > - > > Key: MRESOLVER-417 > URL: https://issues.apache.org/jira/browse/MRESOLVER-417 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > > Now that we have 3 (4 w/ Wagon) HTTP capable resolver transports, we need > some common reusable across HTTP Transports test suite, probably w/ "tunable" > features. > Requirements aside of "most basic functionality": > * MRESOLVER-396 Back off > * MRESOLVER-393 Retain last modified (on files) > * MRESOLVER-382 Setting outgoing interface > * MRESOLVER-361 Unreliable TCP and retries > * MRESOLVER-347 and MRESOLVER-348 Pool controls, reuse connection, max TTL > * MRESOLVER-339 and MRESOLVER-315 Preemptive auth > * MRESOLVER-341 Preemptive PUT auth > * MRESOLVER-328 SSL insecure mode > * MRESOLVER-326 Retries on certain errors > The test should use _standard Resolver configuration with different > transports_ as described on page > https://maven.apache.org/resolver/configuration.html > Hence, testing of Wagon is out of scope, as it uses totally different, > ancient Plexus-XML based configuration, does not obey standard resolver > configuration properties. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-499) IPC Named Locks
[ https://issues.apache.org/jira/browse/MRESOLVER-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-499: -- Fix Version/s: 2.0.1 (was: 2.0.0) > IPC Named Locks > --- > > Key: MRESOLVER-499 > URL: https://issues.apache.org/jira/browse/MRESOLVER-499 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > > Create IPC named locks implementation. Depends on MRESOLVER-421. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-456) Fix javadoc warnings
[ https://issues.apache.org/jira/browse/MRESOLVER-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-456: -- Fix Version/s: 2.0.1 > Fix javadoc warnings > > > Key: MRESOLVER-456 > URL: https://issues.apache.org/jira/browse/MRESOLVER-456 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Labels: up-for-grabs > Fix For: 2.0.1 > > > We have some warnings, those need to be fixed. > Given build-time Java is 21, maybe we just want to migrate all to new Javadoc > style? (as many of warnings are missing returns, that basically redundantly > doubles the doco) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-417) Create HTTP test suite a la "TCK"
[ https://issues.apache.org/jira/browse/MRESOLVER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-417: -- Fix Version/s: (was: 2.0.0) > Create HTTP test suite a la "TCK" > - > > Key: MRESOLVER-417 > URL: https://issues.apache.org/jira/browse/MRESOLVER-417 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > Now that we have 3 (4 w/ Wagon) HTTP capable resolver transports, we need > some common reusable across HTTP Transports test suite, probably w/ "tunable" > features. > Requirements aside of "most basic functionality": > * MRESOLVER-396 Back off > * MRESOLVER-393 Retain last modified (on files) > * MRESOLVER-382 Setting outgoing interface > * MRESOLVER-361 Unreliable TCP and retries > * MRESOLVER-347 and MRESOLVER-348 Pool controls, reuse connection, max TTL > * MRESOLVER-339 and MRESOLVER-315 Preemptive auth > * MRESOLVER-341 Preemptive PUT auth > * MRESOLVER-328 SSL insecure mode > * MRESOLVER-326 Retries on certain errors > The test should use _standard Resolver configuration with different > transports_ as described on page > https://maven.apache.org/resolver/configuration.html > Hence, testing of Wagon is out of scope, as it uses totally different, > ancient Plexus-XML based configuration, does not obey standard resolver > configuration properties. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-456) Fix javadoc warnings
[ https://issues.apache.org/jira/browse/MRESOLVER-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-456: -- Fix Version/s: (was: 2.0.0) > Fix javadoc warnings > > > Key: MRESOLVER-456 > URL: https://issues.apache.org/jira/browse/MRESOLVER-456 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Labels: up-for-grabs > > We have some warnings, those need to be fixed. > Given build-time Java is 21, maybe we just want to migrate all to new Javadoc > style? (as many of warnings are missing returns, that basically redundantly > doubles the doco) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7938) Upgrade plexus classworlds to 2.8.0
[ https://issues.apache.org/jira/browse/MNG-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7938. Assignee: Guillaume Nodet (was: Karl Heinz Marbaise) Resolution: Fixed > Upgrade plexus classworlds to 2.8.0 > --- > > Key: MNG-7938 > URL: https://issues.apache.org/jira/browse/MNG-7938 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-8 >Reporter: Karl Heinz Marbaise >Assignee: Guillaume Nodet >Priority: Minor > Fix For: 4.0.0, 4.0.0-beta-3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7938) Upgrade plexus classworlds to 2.8.0
[ https://issues.apache.org/jira/browse/MNG-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17861360#comment-17861360 ] Guillaume Nodet commented on MNG-7938: -- Fixed in [https://github.com/apache/maven/commit/31f667e32d51343f1cc1de40ac490ef37e4a7554] > Upgrade plexus classworlds to 2.8.0 > --- > > Key: MNG-7938 > URL: https://issues.apache.org/jira/browse/MNG-7938 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-8 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 4.0.0, 4.0.0-beta-3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7938) Upgrade plexus classworlds to 2.8.0
[ https://issues.apache.org/jira/browse/MNG-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7938: - Fix Version/s: 4.0.0-beta-3 (was: 4.0.x-candidate) > Upgrade plexus classworlds to 2.8.0 > --- > > Key: MNG-7938 > URL: https://issues.apache.org/jira/browse/MNG-7938 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-8 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 4.0.0, 4.0.0-beta-3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1934) Ability to disable system-out/system-err for successfully passed tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17861342#comment-17861342 ] Stamatis Zampetakis commented on SUREFIRE-1934: --- Can't wait to try this out! Thanks [~michael-o] for pushing this past the finish line. > Ability to disable system-out/system-err for successfully passed tests > -- > > Key: SUREFIRE-1934 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1934 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin, xml generation >Affects Versions: 3.0.0-M5 >Reporter: Andrey Turbanov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.3.1 > > > After SUREFIRE-1744 surefire-plugin always reports system-out/system-err even > for successfully passed test. A lot of old projects with big amount of tests > now have to deal with huge output. > I think there should be option to disable new behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-524) "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix() is null" with Nexus Staging plugin
[
https://issues.apache.org/jira/browse/MPLUGIN-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17861271#comment-17861271
]
David Matějček commented on MPLUGIN-524:
Just fyi, the plugin seems compatible with Maven 3.8.6. We need to fix it for
Jakarta EE projects.
> "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix() is null"
> with Nexus Staging plugin
>
>
> Key: MPLUGIN-524
> URL: https://issues.apache.org/jira/browse/MPLUGIN-524
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Metadata Model
>Affects Versions: 3.13.0
>Reporter: Tristan Tarrant
>Priority: Major
>
> While attempting to release a plugin with nexus-staging-maven-plugin, I get
> the following exception:
> {noformat}
> [ERROR] Failed to execute goal
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy
> (injected-nexus-deploy) on project proto-schema-compatibility-maven-plugin:
> Failed to update metadata org.infinispan.maven-plugins/maven-metadata.xml:
> Cannot invoke "String.equals(Object)" because the return value of
> "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy
> (injected-nexus-deploy) on project proto-schema-compatibility-maven-plugin:
> Failed to update metadata org.infinispan.maven-plugins/maven-metadata.xml:
> Cannot invoke "String.equals(Object)" because the return value of
> "org.apache.maven.artifact.repository.metadata.Plugin.getP refix()" is null
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:580)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to update
> metadata org.infinispan.maven-plugins/maven-metadata.xml: Cannot invoke
> "String.equals(Object)" because the return value of
> "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null
> at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
> (DeployMojo.java:216)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:328)
> at org.apache.mave
[jira] [Created] (MENFORCER-507) Add xsltLocation parameter to ExternalRules
Peter Palaga created MENFORCER-507:
--
Summary: Add xsltLocation parameter to ExternalRules
Key: MENFORCER-507
URL: https://issues.apache.org/jira/browse/MENFORCER-507
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: externalRules
Reporter: Peter Palaga
Add a new optional parameter called xsltLocation to
org.apache.maven.enforcer.rules.ExternalRules.
The new parameter points at a location of an XSLT file used to transform the
rule document available via location before it is applied.
This is useful, when users want to consume rules defined in an external
project, but they need to remove or adapt some of those for the local
circumstances.
Example
If location points at the following rule set:
{code:xml}
com.google.code.findbugs:jsr305
com.google.guava:listenablefuture
{code}
And if xsltLocation points at the following transformation
{code:xml}
http://www.w3.org/1999/XSL/Transform;>
{code}
Then the effective rule set will look like to following:
{code:xml}
com.google.guava:listenablefuture
{code}
A PR follows
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1360) Option to disable properties dumping in StatelessXmlReporter
[ https://issues.apache.org/jira/browse/SUREFIRE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17861259#comment-17861259 ] Michael Osipov commented on SUREFIRE-1360: -- I am included to implement it like SUREFIRE-1934. Make properties optional if all tests have passed. > Option to disable properties dumping in StatelessXmlReporter > > > Key: SUREFIRE-1360 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1360 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Jaromir Hamala >Assignee: Michael Osipov >Priority: Minor > > I'd like to have an option to disable dumping (all?) properties into XML > reports. > Reasoning: > The same properties are repeated in 10,000's of XML test reports. > In many cases this is unnecessary. It's painful when a test environment has > I/O throttling - think of AWS with I/O burst credits. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SUREFIRE-1934) Ability to disable system-out/system-err for successfully passed tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed SUREFIRE-1934. Resolution: Fixed Fixed with [c670335783cfcb43cfba7042b90748708eb299ce|https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=c670335783cfcb43cfba7042b90748708eb299ce]. > Ability to disable system-out/system-err for successfully passed tests > -- > > Key: SUREFIRE-1934 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1934 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin, xml generation >Affects Versions: 3.0.0-M5 >Reporter: Andrey Turbanov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.3.1 > > > After SUREFIRE-1744 surefire-plugin always reports system-out/system-err even > for successfully passed test. A lot of old projects with big amount of tests > now have to deal with huge output. > I think there should be option to disable new behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-524) "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix() is null" with Nexus Staging plugin
[
https://issues.apache.org/jira/browse/MPLUGIN-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17861248#comment-17861248
]
Tamas Cservenak commented on MPLUGIN-524:
-
Eclipse uses Nx2 just like ASF. We do not use this plugin.
> "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix() is null"
> with Nexus Staging plugin
>
>
> Key: MPLUGIN-524
> URL: https://issues.apache.org/jira/browse/MPLUGIN-524
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Metadata Model
>Affects Versions: 3.13.0
>Reporter: Tristan Tarrant
>Priority: Major
>
> While attempting to release a plugin with nexus-staging-maven-plugin, I get
> the following exception:
> {noformat}
> [ERROR] Failed to execute goal
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy
> (injected-nexus-deploy) on project proto-schema-compatibility-maven-plugin:
> Failed to update metadata org.infinispan.maven-plugins/maven-metadata.xml:
> Cannot invoke "String.equals(Object)" because the return value of
> "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy
> (injected-nexus-deploy) on project proto-schema-compatibility-maven-plugin:
> Failed to update metadata org.infinispan.maven-plugins/maven-metadata.xml:
> Cannot invoke "String.equals(Object)" because the return value of
> "org.apache.maven.artifact.repository.metadata.Plugin.getP refix()" is null
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:580)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to update
> metadata org.infinispan.maven-plugins/maven-metadata.xml: Cannot invoke
> "String.equals(Object)" because the return value of
> "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null
> at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
> (DeployMojo.java:216)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:328)
> at org.apache.maven.lifecycle.internal.Mojo
[jira] [Commented] (MPLUGIN-524) "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix() is null" with Nexus Staging plugin
[
https://issues.apache.org/jira/browse/MPLUGIN-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17861247#comment-17861247
]
Arjan Tijms commented on MPLUGIN-524:
-
> We consider the plugin as useless these days
Just wondering, is nexus-staging-maven-plugin useless? How else are we supposed
to release to Sonatype? All our jobs for Eclipse EE4J and Jakarta EE use the
nexus-staging-maven-plugin.
> "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix() is null"
> with Nexus Staging plugin
>
>
> Key: MPLUGIN-524
> URL: https://issues.apache.org/jira/browse/MPLUGIN-524
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Metadata Model
>Affects Versions: 3.13.0
>Reporter: Tristan Tarrant
>Priority: Major
>
> While attempting to release a plugin with nexus-staging-maven-plugin, I get
> the following exception:
> {noformat}
> [ERROR] Failed to execute goal
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy
> (injected-nexus-deploy) on project proto-schema-compatibility-maven-plugin:
> Failed to update metadata org.infinispan.maven-plugins/maven-metadata.xml:
> Cannot invoke "String.equals(Object)" because the return value of
> "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy
> (injected-nexus-deploy) on project proto-schema-compatibility-maven-plugin:
> Failed to update metadata org.infinispan.maven-plugins/maven-metadata.xml:
> Cannot invoke "String.equals(Object)" because the return value of
> "org.apache.maven.artifact.repository.metadata.Plugin.getP refix()" is null
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:580)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to update
> metadata org.infinispan.maven-plugins/maven-metadata.xml: Cannot invoke
> "String.equals(Object)" because the return value of
> "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null
> at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
> (DeployMojo.java:216)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
>
[jira] [Closed] (MPLUGIN-508) Upgrade to Maven 4.x
[ https://issues.apache.org/jira/browse/MPLUGIN-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MPLUGIN-508. --- Resolution: Fixed > Upgrade to Maven 4.x > > > Key: MPLUGIN-508 > URL: https://issues.apache.org/jira/browse/MPLUGIN-508 > Project: Maven Plugin Tools > Issue Type: New Feature >Affects Versions: 3.12.0 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-508) Upgrade to Maven 4.x
[ https://issues.apache.org/jira/browse/MPLUGIN-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MPLUGIN-508: Fix Version/s: 4.0.0-beta-1 > Upgrade to Maven 4.x > > > Key: MPLUGIN-508 > URL: https://issues.apache.org/jira/browse/MPLUGIN-508 > Project: Maven Plugin Tools > Issue Type: New Feature >Affects Versions: 3.12.0 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-527) Remove javadoc annotation support
[ https://issues.apache.org/jira/browse/MPLUGIN-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MPLUGIN-527: Fix Version/s: 4.0.0-beta-1 > Remove javadoc annotation support > - > > Key: MPLUGIN-527 > URL: https://issues.apache.org/jira/browse/MPLUGIN-527 > Project: Maven Plugin Tools > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-523) Split Maven3 and Maven4 support
[ https://issues.apache.org/jira/browse/MPLUGIN-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MPLUGIN-523: Fix Version/s: 4.0.0-beta-1 > Split Maven3 and Maven4 support > --- > > Key: MPLUGIN-523 > URL: https://issues.apache.org/jira/browse/MPLUGIN-523 > Project: Maven Plugin Tools > Issue Type: Task > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 3.14.0, 4.0.0-beta-1 > > > We should split m-p-p (two branches), one for Maven3 (maven-3.x) and one for > Maven4 (master), as plugin can be only this or that, no need to support both > at same time. This will result in simpl(er) code base, defaults, config. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPLUGIN-523) Split Maven3 and Maven4 support
[ https://issues.apache.org/jira/browse/MPLUGIN-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MPLUGIN-523. --- Resolution: Fixed > Split Maven3 and Maven4 support > --- > > Key: MPLUGIN-523 > URL: https://issues.apache.org/jira/browse/MPLUGIN-523 > Project: Maven Plugin Tools > Issue Type: Task > Components: Plugin Plugin >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 3.14.0, 4.0.0-beta-1 > > > We should split m-p-p (two branches), one for Maven3 (maven-3.x) and one for > Maven4 (master), as plugin can be only this or that, no need to support both > at same time. This will result in simpl(er) code base, defaults, config. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-525) Remove ant and beanshell support
[ https://issues.apache.org/jira/browse/MPLUGIN-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MPLUGIN-525: Fix Version/s: 4.0.0-beta-1 > Remove ant and beanshell support > > > Key: MPLUGIN-525 > URL: https://issues.apache.org/jira/browse/MPLUGIN-525 > Project: Maven Plugin Tools > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MPLUGIN-523) Split Maven3 and Maven4 support
[ https://issues.apache.org/jira/browse/MPLUGIN-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned MPLUGIN-523: --- Assignee: Guillaume Nodet > Split Maven3 and Maven4 support > --- > > Key: MPLUGIN-523 > URL: https://issues.apache.org/jira/browse/MPLUGIN-523 > Project: Maven Plugin Tools > Issue Type: Task > Components: Plugin Plugin >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 3.14.0, 4.0.0-beta-1 > > > We should split m-p-p (two branches), one for Maven3 (maven-3.x) and one for > Maven4 (master), as plugin can be only this or that, no need to support both > at same time. This will result in simpl(er) code base, defaults, config. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1200) Switch to maven 4 and the new immutable api
[ https://issues.apache.org/jira/browse/MSHARED-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MSHARED-1200. Resolution: Fixed Fixed with [https://github.com/apache/maven-filtering/commit/52bc7a72964bbb15e2cb310f7adb7e037979ebec] > Switch to maven 4 and the new immutable api > --- > > Key: MSHARED-1200 > URL: https://issues.apache.org/jira/browse/MSHARED-1200 > Project: Maven Shared Components > Issue Type: Task > Components: maven-filtering >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: maven-filtering-4.0.0, maven-filtering-4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1200) Switch to maven 4 and the new immutable api
[ https://issues.apache.org/jira/browse/MSHARED-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MSHARED-1200: - Fix Version/s: maven-filtering-4.0.0 maven-filtering-4.0.0-beta-1 > Switch to maven 4 and the new immutable api > --- > > Key: MSHARED-1200 > URL: https://issues.apache.org/jira/browse/MSHARED-1200 > Project: Maven Shared Components > Issue Type: Task > Components: maven-filtering >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: maven-filtering-4.0.0, maven-filtering-4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-577) Bump maven version to 3.9.8
[ https://issues.apache.org/jira/browse/MRESOLVER-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-577: -- Description: Maven is used by supplier and demos. > Bump maven version to 3.9.8 > --- > > Key: MRESOLVER-577 > URL: https://issues.apache.org/jira/browse/MRESOLVER-577 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 1.9.21, 2.0.0-beta-1 > > > Maven is used by supplier and demos. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-577) Bump maven version to 3.9.8
[ https://issues.apache.org/jira/browse/MRESOLVER-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-577. - Resolution: Fixed > Bump maven version to 3.9.8 > --- > > Key: MRESOLVER-577 > URL: https://issues.apache.org/jira/browse/MRESOLVER-577 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 1.9.21, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-577) Bump maven version to 3.9.8
[ https://issues.apache.org/jira/browse/MRESOLVER-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17861161#comment-17861161 ] Tamas Cservenak commented on MRESOLVER-577: --- master: [https://github.com/apache/maven-resolver/commit/eb170c3a17919449fc1dc182b30daacc11dffefa] 1.9.x: https://github.com/apache/maven-resolver/commit/c7639bc0a663b3209d4d9bd068aaf74ceee1bfd4 > Bump maven version to 3.9.8 > --- > > Key: MRESOLVER-577 > URL: https://issues.apache.org/jira/browse/MRESOLVER-577 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 1.9.21, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-577) Bump maven version to 3.9.8
[ https://issues.apache.org/jira/browse/MRESOLVER-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-577: - Assignee: Tamas Cservenak > Bump maven version to 3.9.8 > --- > > Key: MRESOLVER-577 > URL: https://issues.apache.org/jira/browse/MRESOLVER-577 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 1.9.21, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-577) Bump maven version to 3.9.8
Tamas Cservenak created MRESOLVER-577: - Summary: Bump maven version to 3.9.8 Key: MRESOLVER-577 URL: https://issues.apache.org/jira/browse/MRESOLVER-577 Project: Maven Resolver Issue Type: Dependency upgrade Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0, 1.9.21, 2.0.0-beta-1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-576) Allow co-release of Resolver 1.x and 2.x
[
https://issues.apache.org/jira/browse/MRESOLVER-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MRESOLVER-576.
-
Resolution: Fixed
> Allow co-release of Resolver 1.x and 2.x
>
>
> Key: MRESOLVER-576
> URL: https://issues.apache.org/jira/browse/MRESOLVER-576
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.21, 2.0.0-beta-1
>
>
> Currently Resolver 1.x and 2.x cannot be released simultaneously, as they
> would both deploy site to {{resolver-archives/resolver-LATEST}}
> Make sure Resolver 1.x uses {{resolver-archives/resolver-LATEST-1.x}} instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
