[jira] [Comment Edited] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[
https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149892#comment-17149892
]
Alexander Kriegisch edited comment on SUREFIRE-1788 at 7/2/20, 5:50 AM:
>From May until around middle of June I checked Maven Central almost every day,
>then I stopped looking, so I did not notice the release on June 17th. I have
>just upgraded and am experiencing what I described in my previous message and
>nobody was interested in: My builds freeze.
*Update:*
* One module freezes, but only with {{}}.
Without that option, the module runs the integration tests but also fails with
M5, with M4 it works.
* Another module always fails on M5, with or without that option. On M4 it
also works.
There could be some connection to me using Java agents for byte code
instrumentation in my integration tests in the second module, but in the first
module I don't use any agents. As soon as I switch back to M4, my tests all run
fine again. There seems to be something wrong in Surefire. I cannot use the new
release like this.
**Update 2:* The second module freezes if the Java agent prints anything to
stdOut when the {{forkNode implementation}} option is active. It did not hang
before because I had deactivated the output.
was (Author: kriegaex):
>From May until around middle of June I checked Maven Central almost every day,
>then I stopped looking, so I did not notice the release on June 17th. I have
>just upgraded and am experiencing what I described in my previous message and
>nobody was interested in: My builds freeze.
*Update:*
* One module freezes, but only with {{}}.
Without that option, the module runs the integration tests but also fails with
M5, with M4 it works.
* Another module always fails on M5, with or without that option. On M4 it
also works.
There could be some connection to me using Java agents for byte code
instrumentation in my integration tests in the second module, but in the first
module I don't use any agents. As soon as I switch back to M4, my tests all run
fine again. There seems to be something wrong in Surefire. I cannot use the new
release like this.
> Unhandled native logs in SurefireForkChannel
>
>
> Key: SUREFIRE-1788
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1788
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
>
> This is related only to the internal change of the version 3.0.0-M5 itself.
> The
> [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153]
> should be printed to INFO on the console.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[
https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149892#comment-17149892
]
Alexander Kriegisch edited comment on SUREFIRE-1788 at 7/2/20, 5:50 AM:
>From May until around middle of June I checked Maven Central almost every day,
>then I stopped looking, so I did not notice the release on June 17th. I have
>just upgraded and am experiencing what I described in my previous message and
>nobody was interested in: My builds freeze.
*Update:*
* One module freezes, but only with {{}}.
Without that option, the module runs the integration tests but also fails with
M5, with M4 it works.
* Another module always fails on M5, with or without that option. On M4 it
also works.
There could be some connection to me using Java agents for byte code
instrumentation in my integration tests in the second module, but in the first
module I don't use any agents. As soon as I switch back to M4, my tests all run
fine again. There seems to be something wrong in Surefire. I cannot use the new
release like this.
*Update 2:* The second module freezes if the Java agent prints anything to
stdOut when the {{forkNode implementation}} option is active. It did not hang
before because I had deactivated the output. This used to work in one of my
first tests, just scroll up for my feedback. Then at some point a later commit
must have messed up the working feature.
was (Author: kriegaex):
>From May until around middle of June I checked Maven Central almost every day,
>then I stopped looking, so I did not notice the release on June 17th. I have
>just upgraded and am experiencing what I described in my previous message and
>nobody was interested in: My builds freeze.
*Update:*
* One module freezes, but only with {{}}.
Without that option, the module runs the integration tests but also fails with
M5, with M4 it works.
* Another module always fails on M5, with or without that option. On M4 it
also works.
There could be some connection to me using Java agents for byte code
instrumentation in my integration tests in the second module, but in the first
module I don't use any agents. As soon as I switch back to M4, my tests all run
fine again. There seems to be something wrong in Surefire. I cannot use the new
release like this.
**Update 2:* The second module freezes if the Java agent prints anything to
stdOut when the {{forkNode implementation}} option is active. It did not hang
before because I had deactivated the output.
> Unhandled native logs in SurefireForkChannel
>
>
> Key: SUREFIRE-1788
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1788
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
>
> This is related only to the internal change of the version 3.0.0-M5 itself.
> The
> [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153]
> should be printed to INFO on the console.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[
https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149892#comment-17149892
]
Alexander Kriegisch edited comment on SUREFIRE-1788 at 7/2/20, 5:46 AM:
>From May until around middle of June I checked Maven Central almost every day,
>then I stopped looking, so I did not notice the release on June 17th. I have
>just upgraded and am experiencing what I described in my previous message and
>nobody was interested in: My builds freeze.
*Update:*
* One module freezes, but only with {{}}.
Without that option, the module runs the integration tests but also fails with
M5, with M4 it works.
* Another module always fails on M5, with or without that option. On M4 it
also works.
There could be some connection to me using Java agents for byte code
instrumentation in my integration tests in the second module, but in the first
module I don't use any agents. As soon as I switch back to M4, my tests all run
fine again. There seems to be something wrong in Surefire. I cannot use the new
release like this.
was (Author: kriegaex):
>From May until around middle of June I checked Maven Central almost every day,
>then I stopped looking, so I did not notice the release on June 17th. I have
>just upgraded and am experiencing what I described in my previous message and
>nobody was interested in: My builds freeze.
*Update:*
* One module freezes, but only with {{}}.
Without that option, the module runs the integration tests but also fails with
M5, with M4 it works.
* Another module always fails on M5, with or without that option. On M4 is
also works.
There could be some connection to me using Java agents for byte code
instrumentation in my integration tests in the second module, but in the first
module I don't use any agents. As soon as I switch back to M4, my tests all run
fine again. There seems to be something wrong in Surefire. I cannot use the new
release like this.
> Unhandled native logs in SurefireForkChannel
>
>
> Key: SUREFIRE-1788
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1788
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
>
> This is related only to the internal change of the version 3.0.0-M5 itself.
> The
> [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153]
> should be printed to INFO on the console.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[
https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149892#comment-17149892
]
Alexander Kriegisch edited comment on SUREFIRE-1788 at 7/2/20, 5:44 AM:
>From May until around middle of June I checked Maven Central almost every day,
>then I stopped looking, so I did not notice the release on June 17th. I have
>just upgraded and am experiencing what I described in my previous message and
>nobody was interested in: My builds freeze.
*Update:*
* One module freezes, but only with {{}}.
Without that option, the module runs the integration tests but also fails with
M5, with M4 it works.
* Another module always fails on M5, with or without that option. On M4 is
also works.
There could be some connection to me using Java agents for byte code
instrumentation in my integration tests in the second module, but in the first
module I don't use any agents. As soon as I switch back to M4, my tests all run
fine again. There seems to be something wrong in Surefire. I cannot use the new
release like this.
was (Author: kriegaex):
>From May until around middle of June I checke Maven Central almost every day,
>then I stopped looking, so I did not notice the release on June 17th. I have
>just upgraded and am experiencing what I described in my previous message and
>nobody was interested in: My builds freeze.
> Unhandled native logs in SurefireForkChannel
>
>
> Key: SUREFIRE-1788
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1788
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
>
> This is related only to the internal change of the version 3.0.0-M5 itself.
> The
> [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153]
> should be printed to INFO on the console.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149915#comment-17149915
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556 #44
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/44/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6938) MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index out of range: -1
[ https://issues.apache.org/jira/browse/MNG-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149912#comment-17149912 ] Hudson commented on MNG-6938: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556 #44 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/44/ > MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index > out of range: -1 > -- > > Key: MNG-6938 > URL: https://issues.apache.org/jira/browse/MNG-6938 > Project: Maven > Issue Type: Bug > Components: Integration Tests >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Critical > > This is caused when the IT is not related to a JIRA issue or an indexed test. > A regression caused by 2c060ccf4912313eef65a5f6de0684efd7185979. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149911#comment-17149911 ] Hudson commented on MNG-5937: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556 #44 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/44/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149916#comment-17149916
]
Hudson commented on MNG-6656:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556 #44
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/44/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6939) ITs fail when MAVENCODEBASE is relative
[
https://issues.apache.org/jira/browse/MNG-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149913#comment-17149913
]
Hudson commented on MNG-6939:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556 #44
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/44/
> ITs fail when MAVENCODEBASE is relative
> ---
>
> Key: MNG-6939
> URL: https://issues.apache.org/jira/browse/MNG-6939
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Reproducer:
> {noformat}
> osipovmi@deblndw011x:~/var/Projekte/maven-integration-testing
> $ export MAVENCODEBASE=../maven
> $ ./run-its.sh
> ...
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [ 5.221
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 57.130 s
> [INFO] Finished at: 2020-06-10T11:09:06+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (unpack-mav
>
> en-distro) on project core-it-suite: An Ant
> BuildException has occured: src '/var/osipovmi/Projek
>
>
> te/maven-integration-testing/maven/apache-maven/target/apache-maven-bin.zip'
> doesn't exist.
> [ERROR] around Ant part ... src="../maven/apache-maven/target/apache-maven-bin.zip" dest="/
>
>
> var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/apache-maven">...
> @ 5:158 in
>
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following a
> rticles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :core-it-suite
> {noformat}
> It is apparently not obvious that the env var is is normalized, nested or
> cannot be relative.
> [~rfscholte], [~olamy], can you both have a look? We either should fail
> properly or support it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6562) WARN if plugins injected by default lifecycle bindings don't have their version locked in pom.xml or parent
[
https://issues.apache.org/jira/browse/MNG-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149914#comment-17149914
]
Hudson commented on MNG-6562:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556 #44
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/44/
> WARN if plugins injected by default lifecycle bindings don't have their
> version locked in pom.xml or parent
> ---
>
> Key: MNG-6562
> URL: https://issues.apache.org/jira/browse/MNG-6562
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, when building from a basic pom.xml:
> {code:xml}
> 4.0.0
> com.mycompany.app
> my-app
> 1.0-SNAPSHOT
> {code}
> many plugins are used, but their version is not locked by the user: the
> default plugins versions depend on Maven version used, which is not stable
> over different Maven versions.
> Adding a warning for this stability issue will help users know that they need
> to lock down plugins versions in their pom (or parent), something like:
> {noformat}[WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> [WARNING] Version not locked for default bindings plugins
> [maven-install-plugin, maven-resources-plugin, maven-surefire-plugin,
> maven-compiler-plugin, maven-jar-plugin, maven-deploy-plugin,
> maven-site-plugin], you should define versions in pluginManagement section of
> your pom.xml or parent
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6562) WARN if plugins injected by default lifecycle bindings don't have their version locked in pom.xml or parent
[
https://issues.apache.org/jira/browse/MNG-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149904#comment-17149904
]
Hudson commented on MNG-6562:
-
Build unstable in Jenkins: Maven TLP » maven » MODELTESTS_IMPROVEMENT #26
See
https://builds.apache.org/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/26/
> WARN if plugins injected by default lifecycle bindings don't have their
> version locked in pom.xml or parent
> ---
>
> Key: MNG-6562
> URL: https://issues.apache.org/jira/browse/MNG-6562
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, when building from a basic pom.xml:
> {code:xml}
> 4.0.0
> com.mycompany.app
> my-app
> 1.0-SNAPSHOT
> {code}
> many plugins are used, but their version is not locked by the user: the
> default plugins versions depend on Maven version used, which is not stable
> over different Maven versions.
> Adding a warning for this stability issue will help users know that they need
> to lock down plugins versions in their pom (or parent), something like:
> {noformat}[WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> [WARNING] Version not locked for default bindings plugins
> [maven-install-plugin, maven-resources-plugin, maven-surefire-plugin,
> maven-compiler-plugin, maven-jar-plugin, maven-deploy-plugin,
> maven-site-plugin], you should define versions in pluginManagement section of
> your pom.xml or parent
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149906#comment-17149906
]
Hudson commented on MNG-6656:
-
Build unstable in Jenkins: Maven TLP » maven » MODELTESTS_IMPROVEMENT #26
See
https://builds.apache.org/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/26/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6938) MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index out of range: -1
[ https://issues.apache.org/jira/browse/MNG-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149902#comment-17149902 ] Hudson commented on MNG-6938: - Build unstable in Jenkins: Maven TLP » maven » MODELTESTS_IMPROVEMENT #26 See https://builds.apache.org/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/26/ > MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index > out of range: -1 > -- > > Key: MNG-6938 > URL: https://issues.apache.org/jira/browse/MNG-6938 > Project: Maven > Issue Type: Bug > Components: Integration Tests >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Critical > > This is caused when the IT is not related to a JIRA issue or an indexed test. > A regression caused by 2c060ccf4912313eef65a5f6de0684efd7185979. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6939) ITs fail when MAVENCODEBASE is relative
[
https://issues.apache.org/jira/browse/MNG-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149903#comment-17149903
]
Hudson commented on MNG-6939:
-
Build unstable in Jenkins: Maven TLP » maven » MODELTESTS_IMPROVEMENT #26
See
https://builds.apache.org/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/26/
> ITs fail when MAVENCODEBASE is relative
> ---
>
> Key: MNG-6939
> URL: https://issues.apache.org/jira/browse/MNG-6939
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Reproducer:
> {noformat}
> osipovmi@deblndw011x:~/var/Projekte/maven-integration-testing
> $ export MAVENCODEBASE=../maven
> $ ./run-its.sh
> ...
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [ 5.221
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 57.130 s
> [INFO] Finished at: 2020-06-10T11:09:06+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (unpack-mav
>
> en-distro) on project core-it-suite: An Ant
> BuildException has occured: src '/var/osipovmi/Projek
>
>
> te/maven-integration-testing/maven/apache-maven/target/apache-maven-bin.zip'
> doesn't exist.
> [ERROR] around Ant part ... src="../maven/apache-maven/target/apache-maven-bin.zip" dest="/
>
>
> var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/apache-maven">...
> @ 5:158 in
>
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following a
> rticles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :core-it-suite
> {noformat}
> It is apparently not obvious that the env var is is normalized, nested or
> cannot be relative.
> [~rfscholte], [~olamy], can you both have a look? We either should fail
> properly or support it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149899#comment-17149899 ] Hudson commented on MNG-6919: - Build unstable in Jenkins: Maven TLP » maven » MODELTESTS_IMPROVEMENT #26 See https://builds.apache.org/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/26/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149905#comment-17149905
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven TLP » maven » MODELTESTS_IMPROVEMENT #26
See
https://builds.apache.org/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/26/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149900#comment-17149900
]
Hudson commented on MNG-5868:
-
Build unstable in Jenkins: Maven TLP » maven » MODELTESTS_IMPROVEMENT #26
See
https://builds.apache.org/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/26/
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149901#comment-17149901 ] Hudson commented on MNG-5937: - Build unstable in Jenkins: Maven TLP » maven » MODELTESTS_IMPROVEMENT #26 See https://builds.apache.org/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/26/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[ https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149892#comment-17149892 ] Alexander Kriegisch commented on SUREFIRE-1788: --- >From May until around middle of June I checke Maven Central almost every day, >then I stopped looking, so I did not notice the release on June 17th. I have >just upgraded and am experiencing what I described in my previous message and >nobody was interested in: My builds freeze. > Unhandled native logs in SurefireForkChannel > > > Key: SUREFIRE-1788 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1788 > Project: Maven Surefire > Issue Type: Task > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M5 > > > This is related only to the internal change of the version 3.0.0-M5 itself. > The > [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153] > should be printed to INFO on the console. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149891#comment-17149891
]
Hudson commented on MNG-6656:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6548 #22
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6548/22/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6939) ITs fail when MAVENCODEBASE is relative
[
https://issues.apache.org/jira/browse/MNG-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149888#comment-17149888
]
Hudson commented on MNG-6939:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6548 #22
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6548/22/
> ITs fail when MAVENCODEBASE is relative
> ---
>
> Key: MNG-6939
> URL: https://issues.apache.org/jira/browse/MNG-6939
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Reproducer:
> {noformat}
> osipovmi@deblndw011x:~/var/Projekte/maven-integration-testing
> $ export MAVENCODEBASE=../maven
> $ ./run-its.sh
> ...
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [ 5.221
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 57.130 s
> [INFO] Finished at: 2020-06-10T11:09:06+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (unpack-mav
>
> en-distro) on project core-it-suite: An Ant
> BuildException has occured: src '/var/osipovmi/Projek
>
>
> te/maven-integration-testing/maven/apache-maven/target/apache-maven-bin.zip'
> doesn't exist.
> [ERROR] around Ant part ... src="../maven/apache-maven/target/apache-maven-bin.zip" dest="/
>
>
> var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/apache-maven">...
> @ 5:158 in
>
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following a
> rticles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :core-it-suite
> {noformat}
> It is apparently not obvious that the env var is is normalized, nested or
> cannot be relative.
> [~rfscholte], [~olamy], can you both have a look? We either should fail
> properly or support it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149884#comment-17149884 ] Hudson commented on MNG-6919: - Build unstable in Jenkins: Maven TLP » maven » MNG-6548 #22 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6548/22/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149890#comment-17149890
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6548 #22
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6548/22/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149885#comment-17149885
]
Hudson commented on MNG-5868:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6548 #22
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6548/22/
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6938) MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index out of range: -1
[ https://issues.apache.org/jira/browse/MNG-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149887#comment-17149887 ] Hudson commented on MNG-6938: - Build unstable in Jenkins: Maven TLP » maven » MNG-6548 #22 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6548/22/ > MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index > out of range: -1 > -- > > Key: MNG-6938 > URL: https://issues.apache.org/jira/browse/MNG-6938 > Project: Maven > Issue Type: Bug > Components: Integration Tests >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Critical > > This is caused when the IT is not related to a JIRA issue or an indexed test. > A regression caused by 2c060ccf4912313eef65a5f6de0684efd7185979. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149886#comment-17149886 ] Hudson commented on MNG-5937: - Build unstable in Jenkins: Maven TLP » maven » MNG-6548 #22 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6548/22/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6562) WARN if plugins injected by default lifecycle bindings don't have their version locked in pom.xml or parent
[
https://issues.apache.org/jira/browse/MNG-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149889#comment-17149889
]
Hudson commented on MNG-6562:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6548 #22
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6548/22/
> WARN if plugins injected by default lifecycle bindings don't have their
> version locked in pom.xml or parent
> ---
>
> Key: MNG-6562
> URL: https://issues.apache.org/jira/browse/MNG-6562
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, when building from a basic pom.xml:
> {code:xml}
> 4.0.0
> com.mycompany.app
> my-app
> 1.0-SNAPSHOT
> {code}
> many plugins are used, but their version is not locked by the user: the
> default plugins versions depend on Maven version used, which is not stable
> over different Maven versions.
> Adding a warning for this stability issue will help users know that they need
> to lock down plugins versions in their pom (or parent), something like:
> {noformat}[WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> [WARNING] Version not locked for default bindings plugins
> [maven-install-plugin, maven-resources-plugin, maven-surefire-plugin,
> maven-compiler-plugin, maven-jar-plugin, maven-deploy-plugin,
> maven-site-plugin], you should define versions in pluginManagement section of
> your pom.xml or parent
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6562) WARN if plugins injected by default lifecycle bindings don't have their version locked in pom.xml or parent
[
https://issues.apache.org/jira/browse/MNG-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149880#comment-17149880
]
Hudson commented on MNG-6562:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6550 #41
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/41/
> WARN if plugins injected by default lifecycle bindings don't have their
> version locked in pom.xml or parent
> ---
>
> Key: MNG-6562
> URL: https://issues.apache.org/jira/browse/MNG-6562
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, when building from a basic pom.xml:
> {code:xml}
> 4.0.0
> com.mycompany.app
> my-app
> 1.0-SNAPSHOT
> {code}
> many plugins are used, but their version is not locked by the user: the
> default plugins versions depend on Maven version used, which is not stable
> over different Maven versions.
> Adding a warning for this stability issue will help users know that they need
> to lock down plugins versions in their pom (or parent), something like:
> {noformat}[WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> [WARNING] Version not locked for default bindings plugins
> [maven-install-plugin, maven-resources-plugin, maven-surefire-plugin,
> maven-compiler-plugin, maven-jar-plugin, maven-deploy-plugin,
> maven-site-plugin], you should define versions in pluginManagement section of
> your pom.xml or parent
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6938) MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index out of range: -1
[ https://issues.apache.org/jira/browse/MNG-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149878#comment-17149878 ] Hudson commented on MNG-6938: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6550 #41 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/41/ > MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index > out of range: -1 > -- > > Key: MNG-6938 > URL: https://issues.apache.org/jira/browse/MNG-6938 > Project: Maven > Issue Type: Bug > Components: Integration Tests >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Critical > > This is caused when the IT is not related to a JIRA issue or an indexed test. > A regression caused by 2c060ccf4912313eef65a5f6de0684efd7185979. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6939) ITs fail when MAVENCODEBASE is relative
[
https://issues.apache.org/jira/browse/MNG-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149879#comment-17149879
]
Hudson commented on MNG-6939:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6550 #41
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/41/
> ITs fail when MAVENCODEBASE is relative
> ---
>
> Key: MNG-6939
> URL: https://issues.apache.org/jira/browse/MNG-6939
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Reproducer:
> {noformat}
> osipovmi@deblndw011x:~/var/Projekte/maven-integration-testing
> $ export MAVENCODEBASE=../maven
> $ ./run-its.sh
> ...
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [ 5.221
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 57.130 s
> [INFO] Finished at: 2020-06-10T11:09:06+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (unpack-mav
>
> en-distro) on project core-it-suite: An Ant
> BuildException has occured: src '/var/osipovmi/Projek
>
>
> te/maven-integration-testing/maven/apache-maven/target/apache-maven-bin.zip'
> doesn't exist.
> [ERROR] around Ant part ... src="../maven/apache-maven/target/apache-maven-bin.zip" dest="/
>
>
> var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/apache-maven">...
> @ 5:158 in
>
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following a
> rticles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :core-it-suite
> {noformat}
> It is apparently not obvious that the env var is is normalized, nested or
> cannot be relative.
> [~rfscholte], [~olamy], can you both have a look? We either should fail
> properly or support it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149877#comment-17149877 ] Hudson commented on MNG-5937: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6550 #41 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/41/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149875#comment-17149875 ] Hudson commented on MNG-6919: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6550 #41 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/41/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149876#comment-17149876
]
Hudson commented on MNG-5868:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6550 #41
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/41/
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149881#comment-17149881
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6550 #41
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/41/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149882#comment-17149882
]
Hudson commented on MNG-6656:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6550 #41
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/41/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6938) MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index out of range: -1
[ https://issues.apache.org/jira/browse/MNG-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149866#comment-17149866 ] Hudson commented on MNG-6938: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6551 #44 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/44/ > MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index > out of range: -1 > -- > > Key: MNG-6938 > URL: https://issues.apache.org/jira/browse/MNG-6938 > Project: Maven > Issue Type: Bug > Components: Integration Tests >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Critical > > This is caused when the IT is not related to a JIRA issue or an indexed test. > A regression caused by 2c060ccf4912313eef65a5f6de0684efd7185979. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6939) ITs fail when MAVENCODEBASE is relative
[
https://issues.apache.org/jira/browse/MNG-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149867#comment-17149867
]
Hudson commented on MNG-6939:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6551 #44
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/44/
> ITs fail when MAVENCODEBASE is relative
> ---
>
> Key: MNG-6939
> URL: https://issues.apache.org/jira/browse/MNG-6939
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Reproducer:
> {noformat}
> osipovmi@deblndw011x:~/var/Projekte/maven-integration-testing
> $ export MAVENCODEBASE=../maven
> $ ./run-its.sh
> ...
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [ 5.221
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 57.130 s
> [INFO] Finished at: 2020-06-10T11:09:06+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (unpack-mav
>
> en-distro) on project core-it-suite: An Ant
> BuildException has occured: src '/var/osipovmi/Projek
>
>
> te/maven-integration-testing/maven/apache-maven/target/apache-maven-bin.zip'
> doesn't exist.
> [ERROR] around Ant part ... src="../maven/apache-maven/target/apache-maven-bin.zip" dest="/
>
>
> var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/apache-maven">...
> @ 5:158 in
>
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following a
> rticles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :core-it-suite
> {noformat}
> It is apparently not obvious that the env var is is normalized, nested or
> cannot be relative.
> [~rfscholte], [~olamy], can you both have a look? We either should fail
> properly or support it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149865#comment-17149865 ] Hudson commented on MNG-5937: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6551 #44 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/44/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149864#comment-17149864
]
Hudson commented on MNG-5868:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6551 #44
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/44/
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6562) WARN if plugins injected by default lifecycle bindings don't have their version locked in pom.xml or parent
[
https://issues.apache.org/jira/browse/MNG-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149868#comment-17149868
]
Hudson commented on MNG-6562:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6551 #44
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/44/
> WARN if plugins injected by default lifecycle bindings don't have their
> version locked in pom.xml or parent
> ---
>
> Key: MNG-6562
> URL: https://issues.apache.org/jira/browse/MNG-6562
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, when building from a basic pom.xml:
> {code:xml}
> 4.0.0
> com.mycompany.app
> my-app
> 1.0-SNAPSHOT
> {code}
> many plugins are used, but their version is not locked by the user: the
> default plugins versions depend on Maven version used, which is not stable
> over different Maven versions.
> Adding a warning for this stability issue will help users know that they need
> to lock down plugins versions in their pom (or parent), something like:
> {noformat}[WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> [WARNING] Version not locked for default bindings plugins
> [maven-install-plugin, maven-resources-plugin, maven-surefire-plugin,
> maven-compiler-plugin, maven-jar-plugin, maven-deploy-plugin,
> maven-site-plugin], you should define versions in pluginManagement section of
> your pom.xml or parent
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149863#comment-17149863 ] Hudson commented on MNG-6919: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6551 #44 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/44/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149869#comment-17149869
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6551 #44
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/44/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149870#comment-17149870
]
Hudson commented on MNG-6656:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6551 #44
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/44/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149858#comment-17149858
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6555 #45
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/45/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149853#comment-17149853
]
Hudson commented on MNG-5868:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6555 #45
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/45/
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149859#comment-17149859
]
Hudson commented on MNG-6656:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6555 #45
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/45/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149854#comment-17149854 ] Hudson commented on MNG-5937: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6555 #45 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/45/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149852#comment-17149852 ] Hudson commented on MNG-6919: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6555 #45 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/45/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6939) ITs fail when MAVENCODEBASE is relative
[
https://issues.apache.org/jira/browse/MNG-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149856#comment-17149856
]
Hudson commented on MNG-6939:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6555 #45
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/45/
> ITs fail when MAVENCODEBASE is relative
> ---
>
> Key: MNG-6939
> URL: https://issues.apache.org/jira/browse/MNG-6939
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Reproducer:
> {noformat}
> osipovmi@deblndw011x:~/var/Projekte/maven-integration-testing
> $ export MAVENCODEBASE=../maven
> $ ./run-its.sh
> ...
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [ 5.221
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 57.130 s
> [INFO] Finished at: 2020-06-10T11:09:06+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (unpack-mav
>
> en-distro) on project core-it-suite: An Ant
> BuildException has occured: src '/var/osipovmi/Projek
>
>
> te/maven-integration-testing/maven/apache-maven/target/apache-maven-bin.zip'
> doesn't exist.
> [ERROR] around Ant part ... src="../maven/apache-maven/target/apache-maven-bin.zip" dest="/
>
>
> var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/apache-maven">...
> @ 5:158 in
>
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following a
> rticles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :core-it-suite
> {noformat}
> It is apparently not obvious that the env var is is normalized, nested or
> cannot be relative.
> [~rfscholte], [~olamy], can you both have a look? We either should fail
> properly or support it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6938) MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index out of range: -1
[ https://issues.apache.org/jira/browse/MNG-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149855#comment-17149855 ] Hudson commented on MNG-6938: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6555 #45 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/45/ > MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index > out of range: -1 > -- > > Key: MNG-6938 > URL: https://issues.apache.org/jira/browse/MNG-6938 > Project: Maven > Issue Type: Bug > Components: Integration Tests >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Critical > > This is caused when the IT is not related to a JIRA issue or an indexed test. > A regression caused by 2c060ccf4912313eef65a5f6de0684efd7185979. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6562) WARN if plugins injected by default lifecycle bindings don't have their version locked in pom.xml or parent
[
https://issues.apache.org/jira/browse/MNG-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149857#comment-17149857
]
Hudson commented on MNG-6562:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6555 #45
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/45/
> WARN if plugins injected by default lifecycle bindings don't have their
> version locked in pom.xml or parent
> ---
>
> Key: MNG-6562
> URL: https://issues.apache.org/jira/browse/MNG-6562
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, when building from a basic pom.xml:
> {code:xml}
> 4.0.0
> com.mycompany.app
> my-app
> 1.0-SNAPSHOT
> {code}
> many plugins are used, but their version is not locked by the user: the
> default plugins versions depend on Maven version used, which is not stable
> over different Maven versions.
> Adding a warning for this stability issue will help users know that they need
> to lock down plugins versions in their pom (or parent), something like:
> {noformat}[WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> [WARNING] Version not locked for default bindings plugins
> [maven-install-plugin, maven-resources-plugin, maven-surefire-plugin,
> maven-compiler-plugin, maven-jar-plugin, maven-deploy-plugin,
> maven-site-plugin], you should define versions in pluginManagement section of
> your pom.xml or parent
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6562) WARN if plugins injected by default lifecycle bindings don't have their version locked in pom.xml or parent
[
https://issues.apache.org/jira/browse/MNG-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149849#comment-17149849
]
Hudson commented on MNG-6562:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6554 #37
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/37/
> WARN if plugins injected by default lifecycle bindings don't have their
> version locked in pom.xml or parent
> ---
>
> Key: MNG-6562
> URL: https://issues.apache.org/jira/browse/MNG-6562
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, when building from a basic pom.xml:
> {code:xml}
> 4.0.0
> com.mycompany.app
> my-app
> 1.0-SNAPSHOT
> {code}
> many plugins are used, but their version is not locked by the user: the
> default plugins versions depend on Maven version used, which is not stable
> over different Maven versions.
> Adding a warning for this stability issue will help users know that they need
> to lock down plugins versions in their pom (or parent), something like:
> {noformat}[WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> [WARNING] Version not locked for default bindings plugins
> [maven-install-plugin, maven-resources-plugin, maven-surefire-plugin,
> maven-compiler-plugin, maven-jar-plugin, maven-deploy-plugin,
> maven-site-plugin], you should define versions in pluginManagement section of
> your pom.xml or parent
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6938) MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index out of range: -1
[ https://issues.apache.org/jira/browse/MNG-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149847#comment-17149847 ] Hudson commented on MNG-6938: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6554 #37 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/37/ > MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index > out of range: -1 > -- > > Key: MNG-6938 > URL: https://issues.apache.org/jira/browse/MNG-6938 > Project: Maven > Issue Type: Bug > Components: Integration Tests >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Critical > > This is caused when the IT is not related to a JIRA issue or an indexed test. > A regression caused by 2c060ccf4912313eef65a5f6de0684efd7185979. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149844#comment-17149844 ] Hudson commented on MNG-6919: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6554 #37 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/37/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149850#comment-17149850
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6554 #37
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/37/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6939) ITs fail when MAVENCODEBASE is relative
[
https://issues.apache.org/jira/browse/MNG-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149848#comment-17149848
]
Hudson commented on MNG-6939:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6554 #37
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/37/
> ITs fail when MAVENCODEBASE is relative
> ---
>
> Key: MNG-6939
> URL: https://issues.apache.org/jira/browse/MNG-6939
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Reproducer:
> {noformat}
> osipovmi@deblndw011x:~/var/Projekte/maven-integration-testing
> $ export MAVENCODEBASE=../maven
> $ ./run-its.sh
> ...
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [ 5.221
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 57.130 s
> [INFO] Finished at: 2020-06-10T11:09:06+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (unpack-mav
>
> en-distro) on project core-it-suite: An Ant
> BuildException has occured: src '/var/osipovmi/Projek
>
>
> te/maven-integration-testing/maven/apache-maven/target/apache-maven-bin.zip'
> doesn't exist.
> [ERROR] around Ant part ... src="../maven/apache-maven/target/apache-maven-bin.zip" dest="/
>
>
> var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/apache-maven">...
> @ 5:158 in
>
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following a
> rticles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :core-it-suite
> {noformat}
> It is apparently not obvious that the env var is is normalized, nested or
> cannot be relative.
> [~rfscholte], [~olamy], can you both have a look? We either should fail
> properly or support it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149845#comment-17149845
]
Hudson commented on MNG-5868:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6554 #37
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/37/
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149846#comment-17149846 ] Hudson commented on MNG-5937: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6554 #37 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/37/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149851#comment-17149851
]
Hudson commented on MNG-6656:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6554 #37
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/37/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6562) WARN if plugins injected by default lifecycle bindings don't have their version locked in pom.xml or parent
[
https://issues.apache.org/jira/browse/MNG-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149837#comment-17149837
]
Hudson commented on MNG-6562:
-
Build unstable in Jenkins: Maven TLP » maven » MRESOLVER-94 #3
See https://builds.apache.org/job/maven-box/job/maven/job/MRESOLVER-94/3/
> WARN if plugins injected by default lifecycle bindings don't have their
> version locked in pom.xml or parent
> ---
>
> Key: MNG-6562
> URL: https://issues.apache.org/jira/browse/MNG-6562
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, when building from a basic pom.xml:
> {code:xml}
> 4.0.0
> com.mycompany.app
> my-app
> 1.0-SNAPSHOT
> {code}
> many plugins are used, but their version is not locked by the user: the
> default plugins versions depend on Maven version used, which is not stable
> over different Maven versions.
> Adding a warning for this stability issue will help users know that they need
> to lock down plugins versions in their pom (or parent), something like:
> {noformat}[WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> [WARNING] Version not locked for default bindings plugins
> [maven-install-plugin, maven-resources-plugin, maven-surefire-plugin,
> maven-compiler-plugin, maven-jar-plugin, maven-deploy-plugin,
> maven-site-plugin], you should define versions in pluginManagement section of
> your pom.xml or parent
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149838#comment-17149838
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven TLP » maven » MRESOLVER-94 #3
See https://builds.apache.org/job/maven-box/job/maven/job/MRESOLVER-94/3/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149839#comment-17149839
]
Hudson commented on MNG-6656:
-
Build unstable in Jenkins: Maven TLP » maven » MRESOLVER-94 #3
See https://builds.apache.org/job/maven-box/job/maven/job/MRESOLVER-94/3/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6939) ITs fail when MAVENCODEBASE is relative
[
https://issues.apache.org/jira/browse/MNG-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149836#comment-17149836
]
Hudson commented on MNG-6939:
-
Build unstable in Jenkins: Maven TLP » maven » MRESOLVER-94 #3
See https://builds.apache.org/job/maven-box/job/maven/job/MRESOLVER-94/3/
> ITs fail when MAVENCODEBASE is relative
> ---
>
> Key: MNG-6939
> URL: https://issues.apache.org/jira/browse/MNG-6939
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Reproducer:
> {noformat}
> osipovmi@deblndw011x:~/var/Projekte/maven-integration-testing
> $ export MAVENCODEBASE=../maven
> $ ./run-its.sh
> ...
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [ 5.221
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 57.130 s
> [INFO] Finished at: 2020-06-10T11:09:06+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (unpack-mav
>
> en-distro) on project core-it-suite: An Ant
> BuildException has occured: src '/var/osipovmi/Projek
>
>
> te/maven-integration-testing/maven/apache-maven/target/apache-maven-bin.zip'
> doesn't exist.
> [ERROR] around Ant part ... src="../maven/apache-maven/target/apache-maven-bin.zip" dest="/
>
>
> var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/apache-maven">...
> @ 5:158 in
>
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following a
> rticles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :core-it-suite
> {noformat}
> It is apparently not obvious that the env var is is normalized, nested or
> cannot be relative.
> [~rfscholte], [~olamy], can you both have a look? We either should fail
> properly or support it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149831#comment-17149831
]
Hudson commented on MNG-6656:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #38
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/38/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6939) ITs fail when MAVENCODEBASE is relative
[
https://issues.apache.org/jira/browse/MNG-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149828#comment-17149828
]
Hudson commented on MNG-6939:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #38
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/38/
> ITs fail when MAVENCODEBASE is relative
> ---
>
> Key: MNG-6939
> URL: https://issues.apache.org/jira/browse/MNG-6939
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Reproducer:
> {noformat}
> osipovmi@deblndw011x:~/var/Projekte/maven-integration-testing
> $ export MAVENCODEBASE=../maven
> $ ./run-its.sh
> ...
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [ 5.221
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 57.130 s
> [INFO] Finished at: 2020-06-10T11:09:06+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (unpack-mav
>
> en-distro) on project core-it-suite: An Ant
> BuildException has occured: src '/var/osipovmi/Projek
>
>
> te/maven-integration-testing/maven/apache-maven/target/apache-maven-bin.zip'
> doesn't exist.
> [ERROR] around Ant part ... src="../maven/apache-maven/target/apache-maven-bin.zip" dest="/
>
>
> var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/apache-maven">...
> @ 5:158 in
>
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following a
> rticles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :core-it-suite
> {noformat}
> It is apparently not obvious that the env var is is normalized, nested or
> cannot be relative.
> [~rfscholte], [~olamy], can you both have a look? We either should fail
> properly or support it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149833#comment-17149833
]
Hudson commented on MNG-5868:
-
Build unstable in Jenkins: Maven TLP » maven » MRESOLVER-94 #3
See https://builds.apache.org/job/maven-box/job/maven/job/MRESOLVER-94/3/
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6938) MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index out of range: -1
[ https://issues.apache.org/jira/browse/MNG-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149835#comment-17149835 ] Hudson commented on MNG-6938: - Build unstable in Jenkins: Maven TLP » maven » MRESOLVER-94 #3 See https://builds.apache.org/job/maven-box/job/maven/job/MRESOLVER-94/3/ > MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index > out of range: -1 > -- > > Key: MNG-6938 > URL: https://issues.apache.org/jira/browse/MNG-6938 > Project: Maven > Issue Type: Bug > Components: Integration Tests >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Critical > > This is caused when the IT is not related to a JIRA issue or an indexed test. > A regression caused by 2c060ccf4912313eef65a5f6de0684efd7185979. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149830#comment-17149830
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #38
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/38/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149834#comment-17149834 ] Hudson commented on MNG-5937: - Build unstable in Jenkins: Maven TLP » maven » MRESOLVER-94 #3 See https://builds.apache.org/job/maven-box/job/maven/job/MRESOLVER-94/3/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149832#comment-17149832 ] Hudson commented on MNG-6919: - Build unstable in Jenkins: Maven TLP » maven » MRESOLVER-94 #3 See https://builds.apache.org/job/maven-box/job/maven/job/MRESOLVER-94/3/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149826#comment-17149826 ] Hudson commented on MNG-5937: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #38 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/38/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149821#comment-17149821
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6512-build-11 #15
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6512-build-11/15/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149824#comment-17149824 ] Hudson commented on MNG-6919: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #38 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/38/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149825#comment-17149825
]
Hudson commented on MNG-5868:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #38
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/38/
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6562) WARN if plugins injected by default lifecycle bindings don't have their version locked in pom.xml or parent
[
https://issues.apache.org/jira/browse/MNG-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149820#comment-17149820
]
Hudson commented on MNG-6562:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6512-build-11 #15
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6512-build-11/15/
> WARN if plugins injected by default lifecycle bindings don't have their
> version locked in pom.xml or parent
> ---
>
> Key: MNG-6562
> URL: https://issues.apache.org/jira/browse/MNG-6562
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, when building from a basic pom.xml:
> {code:xml}
> 4.0.0
> com.mycompany.app
> my-app
> 1.0-SNAPSHOT
> {code}
> many plugins are used, but their version is not locked by the user: the
> default plugins versions depend on Maven version used, which is not stable
> over different Maven versions.
> Adding a warning for this stability issue will help users know that they need
> to lock down plugins versions in their pom (or parent), something like:
> {noformat}[WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> [WARNING] Version not locked for default bindings plugins
> [maven-install-plugin, maven-resources-plugin, maven-surefire-plugin,
> maven-compiler-plugin, maven-jar-plugin, maven-deploy-plugin,
> maven-site-plugin], you should define versions in pluginManagement section of
> your pom.xml or parent
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6562) WARN if plugins injected by default lifecycle bindings don't have their version locked in pom.xml or parent
[
https://issues.apache.org/jira/browse/MNG-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149829#comment-17149829
]
Hudson commented on MNG-6562:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #38
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/38/
> WARN if plugins injected by default lifecycle bindings don't have their
> version locked in pom.xml or parent
> ---
>
> Key: MNG-6562
> URL: https://issues.apache.org/jira/browse/MNG-6562
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, when building from a basic pom.xml:
> {code:xml}
> 4.0.0
> com.mycompany.app
> my-app
> 1.0-SNAPSHOT
> {code}
> many plugins are used, but their version is not locked by the user: the
> default plugins versions depend on Maven version used, which is not stable
> over different Maven versions.
> Adding a warning for this stability issue will help users know that they need
> to lock down plugins versions in their pom (or parent), something like:
> {noformat}[WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> [WARNING] Version not locked for default bindings plugins
> [maven-install-plugin, maven-resources-plugin, maven-surefire-plugin,
> maven-compiler-plugin, maven-jar-plugin, maven-deploy-plugin,
> maven-site-plugin], you should define versions in pluginManagement section of
> your pom.xml or parent
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6938) MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index out of range: -1
[ https://issues.apache.org/jira/browse/MNG-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149827#comment-17149827 ] Hudson commented on MNG-6938: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #38 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/38/ > MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index > out of range: -1 > -- > > Key: MNG-6938 > URL: https://issues.apache.org/jira/browse/MNG-6938 > Project: Maven > Issue Type: Bug > Components: Integration Tests >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Critical > > This is caused when the IT is not related to a JIRA issue or an indexed test. > A regression caused by 2c060ccf4912313eef65a5f6de0684efd7185979. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6938) MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index out of range: -1
[ https://issues.apache.org/jira/browse/MNG-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149818#comment-17149818 ] Hudson commented on MNG-6938: - Build unstable in Jenkins: Maven TLP » maven » MNG-6512-build-11 #15 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6512-build-11/15/ > MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index > out of range: -1 > -- > > Key: MNG-6938 > URL: https://issues.apache.org/jira/browse/MNG-6938 > Project: Maven > Issue Type: Bug > Components: Integration Tests >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Critical > > This is caused when the IT is not related to a JIRA issue or an indexed test. > A regression caused by 2c060ccf4912313eef65a5f6de0684efd7185979. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149816#comment-17149816
]
Hudson commented on MNG-5868:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6512-build-11 #15
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6512-build-11/15/
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6939) ITs fail when MAVENCODEBASE is relative
[
https://issues.apache.org/jira/browse/MNG-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149819#comment-17149819
]
Hudson commented on MNG-6939:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6512-build-11 #15
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6512-build-11/15/
> ITs fail when MAVENCODEBASE is relative
> ---
>
> Key: MNG-6939
> URL: https://issues.apache.org/jira/browse/MNG-6939
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Reproducer:
> {noformat}
> osipovmi@deblndw011x:~/var/Projekte/maven-integration-testing
> $ export MAVENCODEBASE=../maven
> $ ./run-its.sh
> ...
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [ 5.221
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 57.130 s
> [INFO] Finished at: 2020-06-10T11:09:06+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (unpack-mav
>
> en-distro) on project core-it-suite: An Ant
> BuildException has occured: src '/var/osipovmi/Projek
>
>
> te/maven-integration-testing/maven/apache-maven/target/apache-maven-bin.zip'
> doesn't exist.
> [ERROR] around Ant part ... src="../maven/apache-maven/target/apache-maven-bin.zip" dest="/
>
>
> var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/apache-maven">...
> @ 5:158 in
>
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following a
> rticles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :core-it-suite
> {noformat}
> It is apparently not obvious that the env var is is normalized, nested or
> cannot be relative.
> [~rfscholte], [~olamy], can you both have a look? We either should fail
> properly or support it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149822#comment-17149822
]
Hudson commented on MNG-6656:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6512-build-11 #15
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6512-build-11/15/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149817#comment-17149817 ] Hudson commented on MNG-5937: - Build unstable in Jenkins: Maven TLP » maven » MNG-6512-build-11 #15 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6512-build-11/15/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149815#comment-17149815 ] Hudson commented on MNG-6919: - Build unstable in Jenkins: Maven TLP » maven » MNG-6512-build-11 #15 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6512-build-11/15/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6562) WARN if plugins injected by default lifecycle bindings don't have their version locked in pom.xml or parent
[
https://issues.apache.org/jira/browse/MNG-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149807#comment-17149807
]
Hudson commented on MNG-6562:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6909 #8
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6909/8/
> WARN if plugins injected by default lifecycle bindings don't have their
> version locked in pom.xml or parent
> ---
>
> Key: MNG-6562
> URL: https://issues.apache.org/jira/browse/MNG-6562
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, when building from a basic pom.xml:
> {code:xml}
> 4.0.0
> com.mycompany.app
> my-app
> 1.0-SNAPSHOT
> {code}
> many plugins are used, but their version is not locked by the user: the
> default plugins versions depend on Maven version used, which is not stable
> over different Maven versions.
> Adding a warning for this stability issue will help users know that they need
> to lock down plugins versions in their pom (or parent), something like:
> {noformat}[WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> [WARNING] Version not locked for default bindings plugins
> [maven-install-plugin, maven-resources-plugin, maven-surefire-plugin,
> maven-compiler-plugin, maven-jar-plugin, maven-deploy-plugin,
> maven-site-plugin], you should define versions in pluginManagement section of
> your pom.xml or parent
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149808#comment-17149808
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6909 #8
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6909/8/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6939) ITs fail when MAVENCODEBASE is relative
[
https://issues.apache.org/jira/browse/MNG-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149806#comment-17149806
]
Hudson commented on MNG-6939:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6909 #8
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6909/8/
> ITs fail when MAVENCODEBASE is relative
> ---
>
> Key: MNG-6939
> URL: https://issues.apache.org/jira/browse/MNG-6939
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Reproducer:
> {noformat}
> osipovmi@deblndw011x:~/var/Projekte/maven-integration-testing
> $ export MAVENCODEBASE=../maven
> $ ./run-its.sh
> ...
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [ 5.221
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 57.130 s
> [INFO] Finished at: 2020-06-10T11:09:06+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (unpack-mav
>
> en-distro) on project core-it-suite: An Ant
> BuildException has occured: src '/var/osipovmi/Projek
>
>
> te/maven-integration-testing/maven/apache-maven/target/apache-maven-bin.zip'
> doesn't exist.
> [ERROR] around Ant part ... src="../maven/apache-maven/target/apache-maven-bin.zip" dest="/
>
>
> var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/apache-maven">...
> @ 5:158 in
>
> /var/osipovmi/Projekte/maven-integration-testing/core-it-suite/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following a
> rticles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :core-it-suite
> {noformat}
> It is apparently not obvious that the env var is is normalized, nested or
> cannot be relative.
> [~rfscholte], [~olamy], can you both have a look? We either should fail
> properly or support it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6938) MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index out of range: -1
[ https://issues.apache.org/jira/browse/MNG-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149805#comment-17149805 ] Hudson commented on MNG-6938: - Build unstable in Jenkins: Maven TLP » maven » MNG-6909 #8 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6909/8/ > MavenITBootstrapTest fails with StringIndexOutOfBoundsException: String index > out of range: -1 > -- > > Key: MNG-6938 > URL: https://issues.apache.org/jira/browse/MNG-6938 > Project: Maven > Issue Type: Bug > Components: Integration Tests >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Critical > > This is caused when the IT is not related to a JIRA issue or an indexed test. > A regression caused by 2c060ccf4912313eef65a5f6de0684efd7185979. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149809#comment-17149809
]
Hudson commented on MNG-6656:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6909 #8
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6909/8/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149803#comment-17149803
]
Hudson commented on MNG-5868:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6909 #8
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6909/8/
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149804#comment-17149804 ] Hudson commented on MNG-5937: - Build unstable in Jenkins: Maven TLP » maven » MNG-6909 #8 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6909/8/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149802#comment-17149802 ] Hudson commented on MNG-6919: - Build unstable in Jenkins: Maven TLP » maven » MNG-6909 #8 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6909/8/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-parent] dependabot[bot] opened a new pull request #19: Bump extra-enforcer-rules from 1.2 to 1.3
dependabot[bot] opened a new pull request #19: URL: https://github.com/apache/maven-parent/pull/19 Bumps [extra-enforcer-rules](https://github.com/mojohaus/extra-enforcer-rules) from 1.2 to 1.3. Commits https://github.com/mojohaus/extra-enforcer-rules/commit/5b5bffb7af434882e2fa8ca9197caaeb9d7b4726;>5b5bffb [maven-release-plugin] prepare release extra-enforcer-rules-1.3 https://github.com/mojohaus/extra-enforcer-rules/commit/856f3efc9bd0a644690bf8eccac5d972f10fec18;>856f3ef Update parent to mojo-parent 50 https://github.com/mojohaus/extra-enforcer-rules/commit/bcce055876ab8a4b6941914ab2099f641ab84c8a;>bcce055 Implement EnforcerRule2 to enable warn level https://github.com/mojohaus/extra-enforcer-rules/commit/2d966875b4e11da1fe79294d787d1efd1fb27694;>2d96687 docs: fix typos https://github.com/mojohaus/extra-enforcer-rules/commit/79bea92517084b3f7788e32a4133bdfec01be398;>79bea92 Add bytecode mapping for Java 13 through 16 https://github.com/mojohaus/extra-enforcer-rules/commit/811b87469a23673c0c869dabcd291db35489fc7e;>811b874 Bump protocol for snapshot repository https://github.com/mojohaus/extra-enforcer-rules/commit/52017dd8ff5e9ed7356c4e8f4d52ba070a1ba03f;>52017dd Fix for issue https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/48;>#48 https://github.com/mojohaus/extra-enforcer-rules/commit/dea12f458a14aeeb39d8887a31a2a891a8046290;>dea12f4 Remove unused private field https://github.com/mojohaus/extra-enforcer-rules/commit/0796894975640040c920898bf1cce965b4d6277a;>0796894 Fix Java 7 build on Travis CI https://github.com/mojohaus/extra-enforcer-rules/commit/cce7642778242a8fc3408076d94bd53f5b66;>cce7633 Merge pull request https://github-redirect.dependabot.com/mojohaus/extra-enforcer-rules/issues/83;>#83 from elharo/patch-1 Additional commits viewable in https://github.com/mojohaus/extra-enforcer-rules/compare/extra-enforcer-rules-1.2...extra-enforcer-rules-1.3;>compare view [](https://help.github.com/articles/configuring-automated-security-fixes) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-6953) dependencyManagement scan dependency jar repository config
Wang Haiqi created MNG-6953: --- Summary: dependencyManagement scan dependency jar repository config Key: MNG-6953 URL: https://issues.apache.org/jira/browse/MNG-6953 Project: Maven Issue Type: Bug Components: Artifacts and Repositories Reporter: Wang Haiqi Attachments: image-2020-07-02-11-41-58-230.png, image-2020-07-02-11-46-14-728.png, image-2020-07-02-11-46-47-443.png !image-2020-07-02-11-41-58-230.png! dependencyManagement When there is a version configuration with scope in the dependency jar package, why is the repository repository configuration in the dependency package used in the package? How to disable? !image-2020-07-02-11-46-14-728.png! !image-2020-07-02-11-46-47-443.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] yangnuoyu opened a new pull request #366: [MNG-6893] Upgrade maven-dependency-plugin to 3.1.2
yangnuoyu opened a new pull request #366: URL: https://github.com/apache/maven/pull/366 [MNG-6893] Upgrade maven-dependency-plugin to 3.1.2 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DOXIASITETOOLS-219) fix javadoc issues with JDK 8 when generating documentation
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149718#comment-17149718
]
Abel Salgado Romero commented on DOXIASITETOOLS-219:
I am working on this pointing temporarilly to the snapshot version of modello.
Mostly filling "param" and "return" with descriptions from other methods, but I
found 2 references that I don't know what to proceed.
# In `AbstractITextRender` there's this old annotation. Should just mark is as
`{color:#629755}{{color}{color:#629755}@literal
{color}{color:#629755}@plexus.requirement}{color}`? I suspect that will break
something
{code:java}
/**
* @plexus.requirement
*/
protected Doxia doxia;
{code}
2. In `DocumentRender` line 70, there's a commented line with a
deprecated reference. Is it safe to assume is a typo an can be removed?
PS: I got it working for Java8, with 11 there were other errors with modules,
but I image we deal with them in another issue.
> fix javadoc issues with JDK 8 when generating documentation
> ---
>
> Key: DOXIASITETOOLS-219
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-219
> Project: Maven Doxia Sitetools
> Issue Type: Dependency upgrade
>Affects Versions: 1.9.2
>Reporter: Herve Boutemy
>Priority: Major
> Labels: up-for-grabs
> Fix For: 1.9.3
>
>
> when building Doxia Sitetools release with JDK 8:
> {noformat}mvn -Papache-release package -Dgpg.skip{noformat}
> some javadoc issues cause build failure
> for next release, it would be nice to not hit this issue any more
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1788) Unhandled native logs in SurefireForkChannel
[
https://issues.apache.org/jira/browse/SUREFIRE-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149712#comment-17149712
]
Tibor Digana commented on SUREFIRE-1788:
[~kriegaex]
The version {{3.0.0-M5}} was released in June.
Are you using it?
We deleted RC1.
> Unhandled native logs in SurefireForkChannel
>
>
> Key: SUREFIRE-1788
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1788
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
>
> This is related only to the internal change of the version 3.0.0-M5 itself.
> The
> [stdOut|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L153]
> should be printed to INFO on the console.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6054) Remove super POM plugin management section
[
https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149708#comment-17149708
]
Michael Osipov commented on MNG-6054:
-
Why should the Dependency Plugin stay? I'd remvoe the entire block.
> Remove super POM plugin management section
> --
>
> Key: MNG-6054
> URL: https://issues.apache.org/jira/browse/MNG-6054
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.0-alpha-1, 3.3.9, 3.6.3
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: 4.0.x-candidate, needing-scrub-3.4.0-fallout
>
>
> The super POM contains various plugins in the plugin management not part of
> any default lifecycle. These should be removed from the super POM.
> see [http://maven.apache.org/ref/3.5.2/maven-model-builder/super-pom.html]
> {code:xml}
>
>
>
>
>
> maven-antrun-plugin
> 1.3
>
>
> maven-assembly-plugin
> 2.2-beta-5
>
>
> maven-dependency-plugin
> 2.8
>
>
> maven-release-plugin
> 2.5.3
>
>
> {code}
> or
> http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml?revision=1004205=markup
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149705#comment-17149705
]
Pavel_K edited comment on SUREFIRE-1811 at 7/1/20, 9:39 PM:
[~sor] Do I understand you right - you want to find out if surefire copies
resources from src/main/resources to test module when we use the
/test/java/module-info.java, for example `open module theSameNameAsMainModule
\{...}` (same name as main module and open for deep reflection)?
was (Author: pavel_k):
[~sor] Do I understand you right - you want to find out it surefire copies
resources from src/main/resources to test module when we use the
/test/java/module-info.java, for example `open module theSameNameAsMainModule
\{...}` (same name as main module and open for deep reflection)?
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel_K updated SUREFIRE-1811:
--
Comment: was deleted
(was: [~tibordigana] Maybe you can advise something as maven expert?)
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149705#comment-17149705
]
Pavel_K commented on SUREFIRE-1811:
---
[~sor] Do I understand you right - you want to find out it surefire copies
resources from src/main/resources to test module when we use the
/test/java/module-info.java, for example `open module theSameNameAsMainModule
\{...}` (same name as main module and open for deep reflection)?
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
