[jira] [Closed] (MNG-6571) Maven memory consumption issue
[ https://issues.apache.org/jira/browse/MNG-6571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MNG-6571. -- Resolution: Fixed fixed in https://gitbox.apache.org/repos/asf?p=maven.git=commit=8f9075d3ad9a787f0c8ffd4d0e24a9c4339ace1d > Maven memory consumption issue > -- > > Key: MNG-6571 > URL: https://issues.apache.org/jira/browse/MNG-6571 > Project: Maven > Issue Type: Wish >Affects Versions: 3.6.0 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy >Priority: Major > Fix For: 3.6.1 > > Attachments: Maven-Reactor-Dump-Patched.png, Maven-Reactor-Dump.png > > > as reported on Users list: > https://lists.apache.org/thread.html/7d75142448b3c234742bdfd3c743e2f62065fe8e0a313905cbbb2523@%3Cusers.maven.apache.org%3E > then with details on Dev list: > https://lists.apache.org/thread.html/34b64295238594e554f1f2f119848bce3b60d4e1e22e09f26aa64166@%3Cdev.maven.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MSHARED-799) Change "Created-By" manifest entry value to be reproducible
[
https://issues.apache.org/jira/browse/MSHARED-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSHARED-799.
--
Resolution: Fixed
Fixed with
[7041fcace9210112f6745d880133769f954ef442|https://gitbox.apache.org/repos/asf?p=maven-archiver.git;a=commit;h=7041fcace9210112f6745d880133769f954ef442].
> Change "Created-By" manifest entry value to be reproducible
> ---
>
> Key: MSHARED-799
> URL: https://issues.apache.org/jira/browse/MSHARED-799
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> as seen during work on MSHARED-787, the current value for {{Created-By}}
> entry is {{Maven $\{maven.version}}} which is not reproducible
> it would be better to have {{Maven Archiver $\{ma.version\}}} value by default
> and an easy to use API for plugins that use the component to override the
> value with a more precise value like {{Maven XXX Plugin $\{version\}}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-799) Change "Created-By" manifest entry value to be reproducible
[
https://issues.apache.org/jira/browse/MSHARED-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760529#comment-16760529
]
Hudson commented on MSHARED-799:
Build unstable in Jenkins: Maven TLP » maven-archiver » master #55
See https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/55/
> Change "Created-By" manifest entry value to be reproducible
> ---
>
> Key: MSHARED-799
> URL: https://issues.apache.org/jira/browse/MSHARED-799
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> as seen during work on MSHARED-787, the current value for {{Created-By}}
> entry is {{Maven $\{maven.version}}} which is not reproducible
> it would be better to have {{Maven Archiver $\{ma.version\}}} value by default
> and an easy to use API for plugins that use the component to override the
> value with a more precise value like {{Maven XXX Plugin $\{version\}}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6571) Maven memory consumption issue
[ https://issues.apache.org/jira/browse/MNG-6571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760366#comment-16760366 ] Hudson commented on MNG-6571: - Build failed in Jenkins: Maven TLP » maven » master #165 See https://builds.apache.org/job/maven-box/job/maven/job/master/165/ > Maven memory consumption issue > -- > > Key: MNG-6571 > URL: https://issues.apache.org/jira/browse/MNG-6571 > Project: Maven > Issue Type: Wish >Affects Versions: 3.6.0 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy >Priority: Major > Fix For: 3.6.1 > > Attachments: Maven-Reactor-Dump-Patched.png, Maven-Reactor-Dump.png > > > as reported on Users list: > https://lists.apache.org/thread.html/7d75142448b3c234742bdfd3c743e2f62065fe8e0a313905cbbb2523@%3Cusers.maven.apache.org%3E > then with details on Dev list: > https://lists.apache.org/thread.html/34b64295238594e554f1f2f119848bce3b60d4e1e22e09f26aa64166@%3Cdev.maven.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MINSTALL-156) generatePom=false not working with 3.0.0-M1
[
https://issues.apache.org/jira/browse/MINSTALL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760268#comment-16760268
]
Witold Markowski edited comment on MINSTALL-156 at 2/4/19 10:29 PM:
This behavior may be an expected behavior. It looks like *3.0.0-M1* will
install *pom* file always, if the *pom* is available from the inside of the
installed *jar* file. When the artifact is built by Maven, it will put the
*pom* in the *META-INF* directory inside of the jar. This *pom* file will be
installed always no matter what *generatePom* says.
However *generatePom* comes into action when you want to install a *jar* file
which doesn't contain any *META-INF* inside. [~robert12345], please do a simple
test:
* delete whole *META-INF* from the inside of your
*target/test1-1.0-SNAPSHOT.jar*
* execute *mvn
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file
-Dfile=target/test1-1.0-SNAPSHOT.jar -DgroupId=test1 -DartifactId=test1
-Dversion=1.0-SNAPSHOT -Dpackaging=jar -DgeneratePom=false*
In my test *pom* file is not generated by *maven-install-plugin* as below:
{noformat}
$ mvn org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file
-Dfile=target/test1-1.0-SNAPSHOT.jar -DgroupId=test1 -DartifactId=test1
-Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dgene ratePom=false
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building test1 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @ test1 ---
[INFO] pom.xml not found in test1-1.0-SNAPSHOT.jar
[INFO] Installing
C:\Users\wmarkowski\dev-test\sources\test1\target\test1-1.0-SNAPSHOT.jar to
C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.730 s
[INFO] Finished at: 2019-02-04T23:13:56+01:00
[INFO] Final Memory: 9M/245M
[INFO]
{noformat}
>From the other hand, this behavior may break the back compatibility with
>*2.5.2* version, where it was possible to *NOT* to install *pom*. The question
>is: does *3.0.0-M1* need to be as much back compatible with *2.5.2*? Second
>thing: it seems to be a good idea to have *pom* as well installed; maven will
>have then all information about dependencies used by the installed *jar*.
was (Author: wmarkow):
This behavior may be an expected behavior. It looks like *3.0.0-M1* will
install *pom* file always, if the *pom* is available from the inside of the
installed *jar* file. When the artifact is built by Maven, it will put the
*pom* in the *META-INF* directory inside of the jar. This *pom* file will be
installed always no matter what *generatePom* says.
However *generatePom* comes into action when you want to install a *jar* file
which doesn't contain any *META-INF* inside. [~robert12345], please do a simple
test:
* delete whole *META-INF* from the inside of your
*target/test1-1.0-SNAPSHOT.jar*
* execute *mvn
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file
-Dfile=target/test1-1.0-SNAPSHOT.jar -DgroupId=test1 -DartifactId=test1
-Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dgene ratePom=false*
In my test *pom* file is not generated by *maven-install-plugin* as below:
{noformat}
$ mvn org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file
-Dfile=target/test1-1.0-SNAPSHOT.jar -DgroupId=test1 -DartifactId=test1
-Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dgene ratePom=false
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building test1 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @ test1 ---
[INFO] pom.xml not found in test1-1.0-SNAPSHOT.jar
[INFO] Installing
C:\Users\wmarkowski\dev-test\sources\test1\target\test1-1.0-SNAPSHOT.jar to
C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.730 s
[INFO] Finished at: 2019-02-04T23:13:56+01:00
[INFO] Final Memory: 9M/245M
[INFO]
{noformat}
>From the other hand, this behavior may break the back compatibility with
>*2.5.2* version, where it was possible to *NOT* to install *pom*. The question
>is: does *3.0.0-M1* need to be
[jira] [Commented] (MINSTALL-156) generatePom=false not working with 3.0.0-M1
[
https://issues.apache.org/jira/browse/MINSTALL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760268#comment-16760268
]
Witold Markowski commented on MINSTALL-156:
---
This behavior may be an expected behavior. It looks like *3.0.0-M1* will
install *pom* file always, if the *pom* is available from the inside of the
installed *jar* file. When the artifact is built by Maven, it will put the
*pom* in the *META-INF* directory inside of the jar. This *pom* file will be
installed always no matter what *generatePom* says.
However *generatePom* comes into action when you want to install a *jar* file
which doesn't contain any *META-INF* inside. [~robert12345], please do a simple
test:
* delete whole *META-INF* from the inside of your
*target/test1-1.0-SNAPSHOT.jar*
* execute *mvn
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file
-Dfile=target/test1-1.0-SNAPSHOT.jar -DgroupId=test1 -DartifactId=test1
-Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dgene ratePom=false*
In my test *pom* file is not generated by *maven-install-plugin* as below:
{noformat}
$ mvn org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file
-Dfile=target/test1-1.0-SNAPSHOT.jar -DgroupId=test1 -DartifactId=test1
-Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dgene ratePom=false
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building test1 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @ test1 ---
[INFO] pom.xml not found in test1-1.0-SNAPSHOT.jar
[INFO] Installing
C:\Users\wmarkowski\dev-test\sources\test1\target\test1-1.0-SNAPSHOT.jar to
C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.730 s
[INFO] Finished at: 2019-02-04T23:13:56+01:00
[INFO] Final Memory: 9M/245M
[INFO]
{noformat}
>From the other hand, this behavior may break the back compatibility with
>*2.5.2* version, where it was possible to *NOT* to install *pom*. The question
>is: does *3.0.0-M1* need to be as much back compatible with *2.5.2*? Second
>thing: it seems to be a good idea to have *pom* as well installed; maven will
>have then all information about dependencies used by the installed *jar*.
> generatePom=false not working with 3.0.0-M1
> ---
>
> Key: MINSTALL-156
> URL: https://issues.apache.org/jira/browse/MINSTALL-156
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Robert Lieske
>Priority: Major
>
> Steps to reproduce:
> {{mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DgroupId=test1 -DartifactId=test1 -Dversion=1.0-SNAPSHOT}}
>
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:2.5.2:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO]
>
> {quote}
>
> changing the version of the maven-install-plugin in pom.xml to
> {{}}
> {{ maven-install-plugin}}
> {{ 3.0.0-M1}}
> {{ }}
>
> the same call to
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO] Installing
> C:\Users\xxx\AppData\Local\Temp\test1-1.0-SNAPSHOT7157743325898943802.pom to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
> [INFO]
>
> {quote}
>
> Which also installs a POM - which is not what we want!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-157) Seting custom packaging not working with 3.0.0-M1
[
https://issues.apache.org/jira/browse/MINSTALL-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760257#comment-16760257
]
Michael Osipov commented on MINSTALL-157:
-
That's interesting because packaging {{maven-plugin}} isn't installed a
{{.maven-plugin}}. There is a config for this likely. Did you bisect on this?
> Seting custom packaging not working with 3.0.0-M1
> -
>
> Key: MINSTALL-157
> URL: https://issues.apache.org/jira/browse/MINSTALL-157
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Witold Markowski
>Priority: Major
>
> Preparation to reproduce, in console execute:
> {noformat}
> mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DgroupId=test1 -DartifactId=test1 -Dversion=1. 0-SNAPSHOT
> {noformat}
> {noformat}
> cd test1
> {noformat}
> {noformat}
> mvn clean package
> {noformat}
> With *3.0.0-M1* while installing and using *packaging* the output is:
> {noformat}
> $ mvn org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file
> -Dfile=target/test1-1.0-SNAPSHOT.jar -Dpackaging=xyz
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building test1 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @ test1
> ---
> [INFO] Installing
> C:\Users\wmarkowski\dev-test\sources\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO] Installing C:\cygwin64\tmp\test1-1.0-SNAPSHOT6382239492754272802.pom
> to
> C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.722 s
> [INFO] Finished at: 2019-02-04T22:39:45+01:00
> [INFO] Final Memory: 9M/245M
> [INFO]
>
> {noformat}
> The artifact is still installed as *jar*, however it should be installed as
> *xyz*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MINSTALL-157) Seting custom packaging not working with 3.0.0-M1
Witold Markowski created MINSTALL-157:
-
Summary: Seting custom packaging not working with 3.0.0-M1
Key: MINSTALL-157
URL: https://issues.apache.org/jira/browse/MINSTALL-157
Project: Maven Install Plugin
Issue Type: Bug
Affects Versions: 3.0.0-M1
Reporter: Witold Markowski
Preparation to reproduce, in console execute:
{noformat}
mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
-DgroupId=test1 -DartifactId=test1 -Dversion=1. 0-SNAPSHOT
{noformat}
{noformat}
cd test1
{noformat}
{noformat}
mvn clean package
{noformat}
With *3.0.0-M1* while installing and using *packaging* the output is:
{noformat}
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building test1 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @ test1 ---
[INFO] Installing
C:\Users\wmarkowski\dev-test\sources\test1\target\test1-1.0-SNAPSHOT.jar to
C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
[INFO] Installing C:\cygwin64\tmp\test1-1.0-SNAPSHOT6382239492754272802.pom to
C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.722 s
[INFO] Finished at: 2019-02-04T22:39:45+01:00
[INFO] Final Memory: 9M/245M
[INFO]
{noformat}
The artifact is still installed as *jar*, however it should be installed as
*xyz*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-157) Seting custom packaging not working with 3.0.0-M1
[
https://issues.apache.org/jira/browse/MINSTALL-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760253#comment-16760253
]
Witold Markowski commented on MINSTALL-157:
---
When using *maven-install-plugin:3.5.2* the artifact is installed as *xyz*.
Here is the output from the console:
{noformat}
$ mvn org.apache.maven.plugins:maven-install-plugin:2.5.2:install-file
-Dfile=target/test1-1.0-SNAPSHOT.jar -Dpackaging=xyz
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building test1 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-install-plugin:2.5.2:install-file (default-cli) @ test1 ---
[INFO] Installing
C:\Users\wmarkowski\dev-test\sources\test1\target\test1-1.0-SNAPSHOT.jar to
C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.xyz
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.684 s
[INFO] Finished at: 2019-02-04T22:40:30+01:00
[INFO] Final Memory: 8M/245M
[INFO]
{noformat}
> Seting custom packaging not working with 3.0.0-M1
> -
>
> Key: MINSTALL-157
> URL: https://issues.apache.org/jira/browse/MINSTALL-157
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Witold Markowski
>Priority: Major
>
> Preparation to reproduce, in console execute:
> {noformat}
> mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DgroupId=test1 -DartifactId=test1 -Dversion=1. 0-SNAPSHOT
> {noformat}
> {noformat}
> cd test1
> {noformat}
> {noformat}
> mvn clean package
> {noformat}
> With *3.0.0-M1* while installing and using *packaging* the output is:
> {noformat}
> $ mvn org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file
> -Dfile=target/test1-1.0-SNAPSHOT.jar -Dpackaging=xyz
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building test1 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @ test1
> ---
> [INFO] Installing
> C:\Users\wmarkowski\dev-test\sources\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO] Installing C:\cygwin64\tmp\test1-1.0-SNAPSHOT6382239492754272802.pom
> to
> C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.722 s
> [INFO] Finished at: 2019-02-04T22:39:45+01:00
> [INFO] Final Memory: 9M/245M
> [INFO]
>
> {noformat}
> The artifact is still installed as *jar*, however it should be installed as
> *xyz*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MINSTALL-157) Seting custom packaging not working with 3.0.0-M1
[
https://issues.apache.org/jira/browse/MINSTALL-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Witold Markowski updated MINSTALL-157:
--
Description:
Preparation to reproduce, in console execute:
{noformat}
mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
-DgroupId=test1 -DartifactId=test1 -Dversion=1. 0-SNAPSHOT
{noformat}
{noformat}
cd test1
{noformat}
{noformat}
mvn clean package
{noformat}
With *3.0.0-M1* while installing and using *packaging* the output is:
{noformat}
$ mvn org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file
-Dfile=target/test1-1.0-SNAPSHOT.jar -Dpackaging=xyz
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building test1 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @ test1 ---
[INFO] Installing
C:\Users\wmarkowski\dev-test\sources\test1\target\test1-1.0-SNAPSHOT.jar to
C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
[INFO] Installing C:\cygwin64\tmp\test1-1.0-SNAPSHOT6382239492754272802.pom to
C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.722 s
[INFO] Finished at: 2019-02-04T22:39:45+01:00
[INFO] Final Memory: 9M/245M
[INFO]
{noformat}
The artifact is still installed as *jar*, however it should be installed as
*xyz*.
was:
Preparation to reproduce, in console execute:
{noformat}
mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
-DgroupId=test1 -DartifactId=test1 -Dversion=1. 0-SNAPSHOT
{noformat}
{noformat}
cd test1
{noformat}
{noformat}
mvn clean package
{noformat}
With *3.0.0-M1* while installing and using *packaging* the output is:
{noformat}
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building test1 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @ test1 ---
[INFO] Installing
C:\Users\wmarkowski\dev-test\sources\test1\target\test1-1.0-SNAPSHOT.jar to
C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
[INFO] Installing C:\cygwin64\tmp\test1-1.0-SNAPSHOT6382239492754272802.pom to
C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.722 s
[INFO] Finished at: 2019-02-04T22:39:45+01:00
[INFO] Final Memory: 9M/245M
[INFO]
{noformat}
The artifact is still installed as *jar*, however it should be installed as
*xyz*.
> Seting custom packaging not working with 3.0.0-M1
> -
>
> Key: MINSTALL-157
> URL: https://issues.apache.org/jira/browse/MINSTALL-157
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Witold Markowski
>Priority: Major
>
> Preparation to reproduce, in console execute:
> {noformat}
> mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DgroupId=test1 -DartifactId=test1 -Dversion=1. 0-SNAPSHOT
> {noformat}
> {noformat}
> cd test1
> {noformat}
> {noformat}
> mvn clean package
> {noformat}
> With *3.0.0-M1* while installing and using *packaging* the output is:
> {noformat}
> $ mvn org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file
> -Dfile=target/test1-1.0-SNAPSHOT.jar -Dpackaging=xyz
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building test1 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @ test1
> ---
> [INFO] Installing
> C:\Users\wmarkowski\dev-test\sources\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\wmarkowski\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO] Installing
[jira] [Closed] (MNG-6528) Add unit tests for org.apache.maven.plugin.CacheUtils
[
https://issues.apache.org/jira/browse/MNG-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6528.
---
Resolution: Won't Fix
{{CacheUtils}} have been changed, this issue has been superseded.
> Add unit tests for org.apache.maven.plugin.CacheUtils
> -
>
> Key: MNG-6528
> URL: https://issues.apache.org/jira/browse/MNG-6528
> Project: Maven
> Issue Type: Test
>Reporter: Louis Mills
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> These tests were written by Diffblue Cover.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o closed pull request #199: [MNG-6535] - Add unit tests for org.apache.maven.model.path.DefaultUrlNormalizer
michael-o closed pull request #199: [MNG-6535] - Add unit tests for org.apache.maven.model.path.DefaultUrlNormalizer URL: https://github.com/apache/maven/pull/199 This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services
[GitHub] michael-o commented on issue #199: [MNG-6535] - Add unit tests for org.apache.maven.model.path.DefaultUrlNormalizer
michael-o commented on issue #199: [MNG-6535] - Add unit tests for org.apache.maven.model.path.DefaultUrlNormalizer URL: https://github.com/apache/maven/pull/199#issuecomment-460418931 No reaction. This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services
[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760215#comment-16760215 ] Michael Osipov commented on WAGON-541: -- Feel free to do so. > Command Line Not Showing ReasonPhrase for Errors > > > Key: WAGON-541 > URL: https://issues.apache.org/jira/browse/WAGON-541 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Windows 10 >Reporter: Aurelie Pluche >Priority: Minor > Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, > MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG > > > Hi, > I work in the Azure DevOps Artifacts Packaging team at Microsoft where we > provide a Maven service to our customers. We often use a Reason-Phrase to > return information on failed requests to customers. This functionality was > available in previous versions of maven but seems to have disappeared in > Maven 3.6.0. Was this intentional? > I have included screenshots of the cmd line response using two different > maven versions (3.3.9 and 3.6.0). I intentionally made a call that would > return a 405 error to be able to get an error response. I also used the same > package. > Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6477) Check dependency is already downloaded and up-to-date locally, instead of downloading each time on mvn update
[ https://issues.apache.org/jira/browse/MNG-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6477: - Fix Version/s: waiting-for-feedback > Check dependency is already downloaded and up-to-date locally, instead of > downloading each time on mvn update > - > > Key: MNG-6477 > URL: https://issues.apache.org/jira/browse/MNG-6477 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.5.0 >Reporter: chamarthi venkata hrudayanath >Priority: Critical > Fix For: waiting-for-feedback > > > Check whether the dependency is already downloaded in local system and is > up-to-date with latest one before downloading a new one from mvn repository > each time when doing a maven update. Thereby it improves the performance and > saves lot of data for all using maven project. > Approaches that can be used: > 1) when requested for a maven update, get the individual hash of dependencies > already downloaded locally and sent them to mvn repo server. then mvn server > should figure out the updated dependencies and new ones based on hashes. then > it must download only those which are updated and new ones. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6482) Artifactory returns oldest snapshot instead of newest
[ https://issues.apache.org/jira/browse/MNG-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNG-6482. Resolution: Cannot Reproduce Unfortunately no feedback. If you have further details please reopen the issue. > Artifactory returns oldest snapshot instead of newest > - > > Key: MNG-6482 > URL: https://issues.apache.org/jira/browse/MNG-6482 > Project: Maven > Issue Type: Bug >Reporter: Chandan >Priority: Major > Fix For: waiting-for-feedback > > > Artifactory returns oldest snapshot instead of newest > When repoA is built locally, it is not using the latest snapshot of repoB. It > uses the SNAPSHOT which was downloaded the first time. This is the case even > when repoA is built using -U maven flag: mvn -U clean install. > The repoB SNAPSHOT is uploaded in the artifactory, but maven is not > downloading the latest SNAPSHOT to the local repository. > Steps tried to resolve the issue: > 1) Used -U to build repoA locally, which should force maven to check the > availability of latest snapshot. RESULT: Only the > maven-metadata-snapshots-local.xml is updated but the SNAPSHOT is not > downloaded. > 2) executed rm -rf ~/.m2/repository/repoB/repoB/ to delete the local > repository which contains the repoB SNAPSHOT.RESULT: When repoA code is built > locally, maven is downloading the lastest SNAPSHOT of repoB. > 3)Added to both the build profiles present in repoA code > pom.xml file.*For intergration > profile*int-repository-internalhttp://maven.repoB.net/repository/internaltrueneverwarntruealwayswarn > For wombat build > profilewombat-repository-internalhttp://maven.repoB.net/repository/internaltrueneverwarntruealwayswarnNo > luck. > 4)Used in repository id=snapshots-local in > section by changing the > following.truealwayswarnsnapshots-locallibs-snapshothttp://artifactory.devaws.repoB.net/artifactory/libs-snapshot-localNo > luck. > 5)Used in settings.xml by adding the > followinglocal-repotruealwayswarn > No luck. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6482) Artifactory returns oldest snapshot instead of newest
[ https://issues.apache.org/jira/browse/MNG-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6482: - Fix Version/s: waiting-for-feedback > Artifactory returns oldest snapshot instead of newest > - > > Key: MNG-6482 > URL: https://issues.apache.org/jira/browse/MNG-6482 > Project: Maven > Issue Type: Bug >Reporter: Chandan >Priority: Major > Fix For: waiting-for-feedback > > > Artifactory returns oldest snapshot instead of newest > When repoA is built locally, it is not using the latest snapshot of repoB. It > uses the SNAPSHOT which was downloaded the first time. This is the case even > when repoA is built using -U maven flag: mvn -U clean install. > The repoB SNAPSHOT is uploaded in the artifactory, but maven is not > downloading the latest SNAPSHOT to the local repository. > Steps tried to resolve the issue: > 1) Used -U to build repoA locally, which should force maven to check the > availability of latest snapshot. RESULT: Only the > maven-metadata-snapshots-local.xml is updated but the SNAPSHOT is not > downloaded. > 2) executed rm -rf ~/.m2/repository/repoB/repoB/ to delete the local > repository which contains the repoB SNAPSHOT.RESULT: When repoA code is built > locally, maven is downloading the lastest SNAPSHOT of repoB. > 3)Added to both the build profiles present in repoA code > pom.xml file.*For intergration > profile*int-repository-internalhttp://maven.repoB.net/repository/internaltrueneverwarntruealwayswarn > For wombat build > profilewombat-repository-internalhttp://maven.repoB.net/repository/internaltrueneverwarntruealwayswarnNo > luck. > 4)Used in repository id=snapshots-local in > section by changing the > following.truealwayswarnsnapshots-locallibs-snapshothttp://artifactory.devaws.repoB.net/artifactory/libs-snapshot-localNo > luck. > 5)Used in settings.xml by adding the > followinglocal-repotruealwayswarn > No luck. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6499) Introducing source dependencies
[ https://issues.apache.org/jira/browse/MNG-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6499: - Fix Version/s: waiting-for-feedback > Introducing source dependencies > --- > > Key: MNG-6499 > URL: https://issues.apache.org/jira/browse/MNG-6499 > Project: Maven > Issue Type: New Feature >Reporter: netroby >Priority: Major > Fix For: waiting-for-feedback > > > The gradle build tool now provided us a new dependencies management tools. > > Refer: [https://blog.gradle.org/introducing-source-dependencies] > > Hope maven can do same work for us. > Maven is good. but the mvn repository management ugly. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6499) Introducing source dependencies
[ https://issues.apache.org/jira/browse/MNG-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760217#comment-16760217 ] Karl Heinz Marbaise commented on MNG-6499: -- Can you please more in detail explain what the issue is? What is about the repository management ? > Introducing source dependencies > --- > > Key: MNG-6499 > URL: https://issues.apache.org/jira/browse/MNG-6499 > Project: Maven > Issue Type: New Feature >Reporter: netroby >Priority: Major > > The gradle build tool now provided us a new dependencies management tools. > > Refer: [https://blog.gradle.org/introducing-source-dependencies] > > Hope maven can do same work for us. > Maven is good. but the mvn repository management ugly. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6500) Dependency resolution broken with Java 11
[ https://issues.apache.org/jira/browse/MNG-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNG-6500. Resolution: Not A Problem Assignee: Karl Heinz Marbaise > Dependency resolution broken with Java 11 > - > > Key: MNG-6500 > URL: https://issues.apache.org/jira/browse/MNG-6500 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.4 > Environment: Java 11 >Reporter: Jörg Hohwiller >Assignee: Karl Heinz Marbaise >Priority: Major > > I am facing an issue that some transitive dependencies are missing on maven > dependency resolution. This reproducible works fine with older Java (java8) > and always fails with java 11. > The code that fails can be found in this feature branch: > [https://github.com/hohwille/devon4j/tree/feature-16-java-11-build] > A detailed description of the issue can be found here: > [https://github.com/devonfw/devon4j/issues/16] > It would be awesome if someone could have a look and make maven work smooth > with Java 11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6500) Dependency resolution broken with Java 11
[
https://issues.apache.org/jira/browse/MNG-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760216#comment-16760216
]
Karl Heinz Marbaise commented on MNG-6500:
--
Ok. I have checked another time: First we start with large number of warnings:
{code}
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.devonfw.java.boms:devon4j-minimal-bom:pom:3.0.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
com.devonfw.java.boms:devon4j-minimal-bom:${devon4j.version},
/Users/khmarbaise/ws-git-so/devon4j/boms/minimal/pom.xml, line 12, column 12
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.devonfw.java.boms:devon4j-bom:pom:3.0.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
com.devonfw.java.boms:devon4j-bom:${devon4j.version},
/Users/khmarbaise/ws-git-so/devon4j/boms/bom/pom.xml, line 12, column 12
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.devonfw.java.modules:devon4j-logging:jar:3.0.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
com.devonfw.java.modules:devon4j-logging:${devon4j.version},
/Users/khmarbaise/ws-git-so/devon4j/modules/logging/pom.xml, line 12, column 12
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.devonfw.java.modules:devon4j-test:jar:3.0.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
com.devonfw.java.modules:devon4j-test:${devon4j.version},
/Users/khmarbaise/ws-git-so/devon4j/modules/test/pom.xml, line 11, column 12
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.devonfw.java.modules:devon4j-configuration:jar:3.0.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
com.devonfw.java.modules:devon4j-configuration:${devon4j.version},
/Users/khmarbaise/ws-git-so/devon4j/modules/configuration/pom.xml, line 12,
column 12
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.devonfw.java.modules:devon4j-beanmapping:jar:3.0.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
com.devonfw.java.modules:devon4j-beanmapping:${devon4j.version},
/Users/khmarbaise/ws-git-so/devon4j/modules/beanmapping/pom.xml, line 12,
column 12
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.devonfw.java.modules:devon4j-service:jar:3.0.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
com.devonfw.java.modules:devon4j-service:${devon4j.version},
/Users/khmarbaise/ws-git-so/devon4j/modules/service/pom.xml, line 12, column 12
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.devonfw.java.modules:devon4j-json:jar:3.0.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
com.devonfw.java.modules:devon4j-json:${devon4j.version},
/Users/khmarbaise/ws-git-so/devon4j/modules/json/pom.xml, line 12, column 12
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.devonfw.java.modules:devon4j-rest:jar:3.0.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
com.devonfw.java.modules:devon4j-rest:${devon4j.version},
/Users/khmarbaise/ws-git-so/devon4j/modules/rest/pom.xml, line 12, column 12
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.devonfw.java.modules:devon4j-cxf-client:jar:3.0.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
com.devonfw.java.modules:devon4j-cxf-client:${devon4j.version},
/Users/khmarbaise/ws-git-so/devon4j/modules/cxf-client/pom.xml, line 12, column
12
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.devonfw.java.modules:devon4j-cxf-client-rest:jar:3.0.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
com.devonfw.java.modules:devon4j-cxf-client-rest:${devon4j.version},
/Users/khmarbaise/ws-git-so/devon4j/modules/cxf-client-rest/pom.xml, line 12,
column 12
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.devonfw.java.modules:devon4j-cxf-client-ws:jar:3.0.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
com.devonfw.java.modules:devon4j-cxf-client-ws:${devon4j.version},
/Users/khmarbaise/ws-git-so/devon4j/modules/cxf-client-ws/pom.xml, line 12,
column 12
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.devonfw.java.modules:devon4j-cxf-server:jar:3.0.0-SNAPSHOT
[WARNING] 'version' contains an expression but
[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760210#comment-16760210 ] Peter lynch commented on WAGON-541: --- [~michael-o] a system property or anything that makes reason phrase optionally displayed is not ideal. People were using the status code and reason phrase to better understand why a build fails. This can help resolve build failures and get on with the important stuff more quickly. When a build fails, it is too late to retroactively go back and set a system property to determine why it failed in the past. Users can't reasonably be expected to pre-set a new system property to see reason phrases for future possible failures either. They can't with complete certainty in advance if any intermediary server, firewall, HTTP Proxy, or repository manager will be customizing the reason phrase, which may provide useful guidance for fixing a build failure. The persons running builds are often not in control of infrastructure between their build and the remote endpoint. They can't predict how it will fail or what reason phrase will be returned. I propose the spirit of the original change as I understand it be enhanced. Lets clean up code and make exception messages more consistent and less redundant across the 3 major HTTP wagon implementations. Exception messages could become consistently formatted with URL, status code and reason phrase while at the same time removing message redundancy. I would be happy to provide a PR for both cleaning up messages and providing contextual useful Wagon exception messages that can help solve build failures in the most efficient manner. It might take me this week to offer this PR up for review. My view point comes from trying to help enterprise customers who have Maven build failures trying to better understand what went wrong. [~michael-o] how does it sound? > Command Line Not Showing ReasonPhrase for Errors > > > Key: WAGON-541 > URL: https://issues.apache.org/jira/browse/WAGON-541 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Windows 10 >Reporter: Aurelie Pluche >Priority: Minor > Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, > MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG > > > Hi, > I work in the Azure DevOps Artifacts Packaging team at Microsoft where we > provide a Maven service to our customers. We often use a Reason-Phrase to > return information on failed requests to customers. This functionality was > available in previous versions of maven but seems to have disappeared in > Maven 3.6.0. Was this intentional? > I have included screenshots of the cmd line response using two different > maven versions (3.3.9 and 3.6.0). I intentionally made a call that would > return a 405 error to be able to get an error response. I also used the same > package. > Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6507) CI-friendly versioning doesn't work when included as dependency
[
https://issues.apache.org/jira/browse/MNG-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6507:
-
Issue Type: New Feature (was: Bug)
> CI-friendly versioning doesn't work when included as dependency
> ---
>
> Key: MNG-6507
> URL: https://issues.apache.org/jira/browse/MNG-6507
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.6.0
>Reporter: mike duigou
>Priority: Major
>
> I saw in the 3.6.0 release notes that several issues for CI friendly versions
> had been fixed so decided to try the feature.
> One of our reactor projects is (simplified):
> Reactor pom.xml:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Infrastructure}}
> {{ 7}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ App Reactor}}
> {{ App Reactor Project}}
> {{ ${revision}${changelist}}}
> {{ pom }}
> {{ 3.2.0}}
> {{ -SNAPSHOT}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ }}
> {{ core}}
> {{ configuration}}
> {{ }}{{ }}
> {{ }}{{ }}
> \{{ }}
> The configuration project pom.xml uses CI-friendly versioning:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ com.example.app}}
> {{ Configuration}}
> {{ App Configuration}}
> {{ jar}}
> {{ .}}{{ }}
> {{ }}
> The core project pom.xml uses CI-friendly versioning:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ com.example.app}}
> {{ Core}}
> {{ App Core}}
> {{ jar}}
> {{ }}
> {{ }}
> {{ }}
> {{ com.example.app}}
> {{ Configuration}}
> {{ ${revision}${changelist}}}
> {{ test}}
> {{ }}
> {{ .}}
> {{ }}
> {{ .}}
> {{ }}
>
> When building the reactor everything works as expected but building the core
> project independently results in maven attempting to resolve a version
> ${revision}${changelist} from the repos:
> {{[ERROR] Failed to execute goal on project Core: Could not resolve
> dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT: Failed to
> collect dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT:
> Failed to read artifact descriptor for
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT: Failure to find
> com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project Core: Could not resolve dependencies for project
> com.example:Core:jar:3.6.0-SNAPSHOT: Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}
> {{Caused by: org.apache.maven.project.DependencyResolutionException: Could
> not resolve dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT:
> Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}
> {{Caused by: org.eclipse.aether.collection.DependencyCollectionException:
> Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException:
> Failed to read artifact descriptor for
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.apache.maven.model.resolution.UnresolvableModelException:
> Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.eclipse.aether.resolution.ArtifactResolutionException:
> Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced}}
> {{... stack omitted ...}}
> {{Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Failure
> to find com.example.app:Reactor:pom:${revision}${changelist} in
>
[jira] [Updated] (MNG-6507) CI-friendly versioning doesn't work when included as dependency
[
https://issues.apache.org/jira/browse/MNG-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6507:
-
Priority: Minor (was: Major)
> CI-friendly versioning doesn't work when included as dependency
> ---
>
> Key: MNG-6507
> URL: https://issues.apache.org/jira/browse/MNG-6507
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.6.0
>Reporter: mike duigou
>Priority: Minor
>
> I saw in the 3.6.0 release notes that several issues for CI friendly versions
> had been fixed so decided to try the feature.
> One of our reactor projects is (simplified):
> Reactor pom.xml:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Infrastructure}}
> {{ 7}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ App Reactor}}
> {{ App Reactor Project}}
> {{ ${revision}${changelist}}}
> {{ pom }}
> {{ 3.2.0}}
> {{ -SNAPSHOT}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ }}
> {{ core}}
> {{ configuration}}
> {{ }}{{ }}
> {{ }}{{ }}
> \{{ }}
> The configuration project pom.xml uses CI-friendly versioning:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ com.example.app}}
> {{ Configuration}}
> {{ App Configuration}}
> {{ jar}}
> {{ .}}{{ }}
> {{ }}
> The core project pom.xml uses CI-friendly versioning:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ com.example.app}}
> {{ Core}}
> {{ App Core}}
> {{ jar}}
> {{ }}
> {{ }}
> {{ }}
> {{ com.example.app}}
> {{ Configuration}}
> {{ ${revision}${changelist}}}
> {{ test}}
> {{ }}
> {{ .}}
> {{ }}
> {{ .}}
> {{ }}
>
> When building the reactor everything works as expected but building the core
> project independently results in maven attempting to resolve a version
> ${revision}${changelist} from the repos:
> {{[ERROR] Failed to execute goal on project Core: Could not resolve
> dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT: Failed to
> collect dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT:
> Failed to read artifact descriptor for
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT: Failure to find
> com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project Core: Could not resolve dependencies for project
> com.example:Core:jar:3.6.0-SNAPSHOT: Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}
> {{Caused by: org.apache.maven.project.DependencyResolutionException: Could
> not resolve dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT:
> Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}
> {{Caused by: org.eclipse.aether.collection.DependencyCollectionException:
> Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException:
> Failed to read artifact descriptor for
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.apache.maven.model.resolution.UnresolvableModelException:
> Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.eclipse.aether.resolution.ArtifactResolutionException:
> Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced}}
> {{... stack omitted ...}}
> {{Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Failure
> to find com.example.app:Reactor:pom:${revision}${changelist} in
>
[jira] [Closed] (MNG-6502) More performant AbstractZipArchiver when maven module contains lots of big resources
[ https://issues.apache.org/jira/browse/MNG-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNG-6502. Resolution: Won't Fix no feedback for two month. I will close the issue. If you have further details please reopen the issue or don't hesitate to contact me. > More performant AbstractZipArchiver when maven module contains lots of big > resources > > > Key: MNG-6502 > URL: https://issues.apache.org/jira/browse/MNG-6502 > Project: Maven > Issue Type: Improvement >Reporter: Hoa Phan >Priority: Major > Fix For: waiting-for-feedback > > Attachments: Screen Shot 2018-11-01 at 2.22.42 am.png, Screen Shot > 2018-11-01 at 2.25.22 am.png > > > *Consider process resources in parallel > * > > !Screen Shot 2018-11-01 at 2.22.42 am.png! > *Consider flexible/adjustable buffer size for IOUtil.copy > *!Screen Shot 2018-11-01 at 2.25.22 am.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6507) CI-friendly versioning doesn't work when included as dependency
[
https://issues.apache.org/jira/browse/MNG-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6507:
-
Fix Version/s: waiting-for-feedback
> CI-friendly versioning doesn't work when included as dependency
> ---
>
> Key: MNG-6507
> URL: https://issues.apache.org/jira/browse/MNG-6507
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.6.0
>Reporter: mike duigou
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I saw in the 3.6.0 release notes that several issues for CI friendly versions
> had been fixed so decided to try the feature.
> One of our reactor projects is (simplified):
> Reactor pom.xml:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Infrastructure}}
> {{ 7}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ App Reactor}}
> {{ App Reactor Project}}
> {{ ${revision}${changelist}}}
> {{ pom }}
> {{ 3.2.0}}
> {{ -SNAPSHOT}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ }}
> {{ core}}
> {{ configuration}}
> {{ }}{{ }}
> {{ }}{{ }}
> \{{ }}
> The configuration project pom.xml uses CI-friendly versioning:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ com.example.app}}
> {{ Configuration}}
> {{ App Configuration}}
> {{ jar}}
> {{ .}}{{ }}
> {{ }}
> The core project pom.xml uses CI-friendly versioning:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ com.example.app}}
> {{ Core}}
> {{ App Core}}
> {{ jar}}
> {{ }}
> {{ }}
> {{ }}
> {{ com.example.app}}
> {{ Configuration}}
> {{ ${revision}${changelist}}}
> {{ test}}
> {{ }}
> {{ .}}
> {{ }}
> {{ .}}
> {{ }}
>
> When building the reactor everything works as expected but building the core
> project independently results in maven attempting to resolve a version
> ${revision}${changelist} from the repos:
> {{[ERROR] Failed to execute goal on project Core: Could not resolve
> dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT: Failed to
> collect dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT:
> Failed to read artifact descriptor for
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT: Failure to find
> com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project Core: Could not resolve dependencies for project
> com.example:Core:jar:3.6.0-SNAPSHOT: Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}
> {{Caused by: org.apache.maven.project.DependencyResolutionException: Could
> not resolve dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT:
> Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}
> {{Caused by: org.eclipse.aether.collection.DependencyCollectionException:
> Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException:
> Failed to read artifact descriptor for
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.apache.maven.model.resolution.UnresolvableModelException:
> Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.eclipse.aether.resolution.ArtifactResolutionException:
> Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced}}
> {{... stack omitted ...}}
> {{Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Failure
> to find
[jira] [Comment Edited] (MNG-6507) CI-friendly versioning doesn't work when included as dependency
[
https://issues.apache.org/jira/browse/MNG-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760205#comment-16760205
]
Karl Heinz Marbaise edited comment on MNG-6507 at 2/4/19 8:48 PM:
--
I've updated the documentation and documented the use case as I suggested. If
you like to implement this please contact me on the dev list so we can discuss
the issues related to this.
was (Author: khmarbaise):
I've updated the documentation and documented the use case as I suggested. I
will close this. If you like to implement this please reopen this or contact me
on the dev list so we can discuss the issues related to this.
> CI-friendly versioning doesn't work when included as dependency
> ---
>
> Key: MNG-6507
> URL: https://issues.apache.org/jira/browse/MNG-6507
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.6.0
>Reporter: mike duigou
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I saw in the 3.6.0 release notes that several issues for CI friendly versions
> had been fixed so decided to try the feature.
> One of our reactor projects is (simplified):
> Reactor pom.xml:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Infrastructure}}
> {{ 7}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ App Reactor}}
> {{ App Reactor Project}}
> {{ ${revision}${changelist}}}
> {{ pom }}
> {{ 3.2.0}}
> {{ -SNAPSHOT}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ }}
> {{ core}}
> {{ configuration}}
> {{ }}{{ }}
> {{ }}{{ }}
> \{{ }}
> The configuration project pom.xml uses CI-friendly versioning:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ com.example.app}}
> {{ Configuration}}
> {{ App Configuration}}
> {{ jar}}
> {{ .}}{{ }}
> {{ }}
> The core project pom.xml uses CI-friendly versioning:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ com.example.app}}
> {{ Core}}
> {{ App Core}}
> {{ jar}}
> {{ }}
> {{ }}
> {{ }}
> {{ com.example.app}}
> {{ Configuration}}
> {{ ${revision}${changelist}}}
> {{ test}}
> {{ }}
> {{ .}}
> {{ }}
> {{ .}}
> {{ }}
>
> When building the reactor everything works as expected but building the core
> project independently results in maven attempting to resolve a version
> ${revision}${changelist} from the repos:
> {{[ERROR] Failed to execute goal on project Core: Could not resolve
> dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT: Failed to
> collect dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT:
> Failed to read artifact descriptor for
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT: Failure to find
> com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project Core: Could not resolve dependencies for project
> com.example:Core:jar:3.6.0-SNAPSHOT: Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}
> {{Caused by: org.apache.maven.project.DependencyResolutionException: Could
> not resolve dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT:
> Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}
> {{Caused by: org.eclipse.aether.collection.DependencyCollectionException:
> Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException:
> Failed to read artifact descriptor for
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.apache.maven.model.resolution.UnresolvableModelException:
> Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced}}
> {{... stack omitted ...}}{{ }}
> {{Caused by:
[jira] [Commented] (MNG-6507) CI-friendly versioning doesn't work when included as dependency
[
https://issues.apache.org/jira/browse/MNG-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760206#comment-16760206
]
Hudson commented on MNG-6507:
-
Build succeeded in Jenkins: Maven TLP » maven-site » master #175
See https://builds.apache.org/job/maven-box/job/maven-site/job/master/175/
> CI-friendly versioning doesn't work when included as dependency
> ---
>
> Key: MNG-6507
> URL: https://issues.apache.org/jira/browse/MNG-6507
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.6.0
>Reporter: mike duigou
>Priority: Major
>
> I saw in the 3.6.0 release notes that several issues for CI friendly versions
> had been fixed so decided to try the feature.
> One of our reactor projects is (simplified):
> Reactor pom.xml:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Infrastructure}}
> {{ 7}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ App Reactor}}
> {{ App Reactor Project}}
> {{ ${revision}${changelist}}}
> {{ pom }}
> {{ 3.2.0}}
> {{ -SNAPSHOT}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ }}
> {{ core}}
> {{ configuration}}
> {{ }}{{ }}
> {{ }}{{ }}
> \{{ }}
> The configuration project pom.xml uses CI-friendly versioning:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ com.example.app}}
> {{ Configuration}}
> {{ App Configuration}}
> {{ jar}}
> {{ .}}{{ }}
> {{ }}
> The core project pom.xml uses CI-friendly versioning:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ com.example.app}}
> {{ Core}}
> {{ App Core}}
> {{ jar}}
> {{ }}
> {{ }}
> {{ }}
> {{ com.example.app}}
> {{ Configuration}}
> {{ ${revision}${changelist}}}
> {{ test}}
> {{ }}
> {{ .}}
> {{ }}
> {{ .}}
> {{ }}
>
> When building the reactor everything works as expected but building the core
> project independently results in maven attempting to resolve a version
> ${revision}${changelist} from the repos:
> {{[ERROR] Failed to execute goal on project Core: Could not resolve
> dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT: Failed to
> collect dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT:
> Failed to read artifact descriptor for
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT: Failure to find
> com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project Core: Could not resolve dependencies for project
> com.example:Core:jar:3.6.0-SNAPSHOT: Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}
> {{Caused by: org.apache.maven.project.DependencyResolutionException: Could
> not resolve dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT:
> Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}
> {{Caused by: org.eclipse.aether.collection.DependencyCollectionException:
> Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException:
> Failed to read artifact descriptor for
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.apache.maven.model.resolution.UnresolvableModelException:
> Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.eclipse.aether.resolution.ArtifactResolutionException:
> Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced}}
> {{... stack omitted ...}}
> {{Caused by:
[jira] [Commented] (MNG-6507) CI-friendly versioning doesn't work when included as dependency
[
https://issues.apache.org/jira/browse/MNG-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760205#comment-16760205
]
Karl Heinz Marbaise commented on MNG-6507:
--
I've updated the documentation and documented the use case as I suggested. I
will close this. If you like to implement this please reopen this or contact me
on the dev list so we can discuss the issues related to this.
> CI-friendly versioning doesn't work when included as dependency
> ---
>
> Key: MNG-6507
> URL: https://issues.apache.org/jira/browse/MNG-6507
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.6.0
>Reporter: mike duigou
>Priority: Major
>
> I saw in the 3.6.0 release notes that several issues for CI friendly versions
> had been fixed so decided to try the feature.
> One of our reactor projects is (simplified):
> Reactor pom.xml:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Infrastructure}}
> {{ 7}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ App Reactor}}
> {{ App Reactor Project}}
> {{ ${revision}${changelist}}}
> {{ pom }}
> {{ 3.2.0}}
> {{ -SNAPSHOT}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ }}
> {{ core}}
> {{ configuration}}
> {{ }}{{ }}
> {{ }}{{ }}
> \{{ }}
> The configuration project pom.xml uses CI-friendly versioning:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ com.example.app}}
> {{ Configuration}}
> {{ App Configuration}}
> {{ jar}}
> {{ .}}{{ }}
> {{ }}
> The core project pom.xml uses CI-friendly versioning:
> {{}}
> {{ 4.0.0}}
> {{ }}
> {{ com.example.app}}
> {{ Reactor}}
> {{ ${revision}${changelist}}}
> {{ }}
> {{ com.example.app}}
> {{ Core}}
> {{ App Core}}
> {{ jar}}
> {{ }}
> {{ }}
> {{ }}
> {{ com.example.app}}
> {{ Configuration}}
> {{ ${revision}${changelist}}}
> {{ test}}
> {{ }}
> {{ .}}
> {{ }}
> {{ .}}
> {{ }}
>
> When building the reactor everything works as expected but building the core
> project independently results in maven attempting to resolve a version
> ${revision}${changelist} from the repos:
> {{[ERROR] Failed to execute goal on project Core: Could not resolve
> dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT: Failed to
> collect dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT:
> Failed to read artifact descriptor for
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT: Failure to find
> com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project Core: Could not resolve dependencies for project
> com.example:Core:jar:3.6.0-SNAPSHOT: Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}
> {{Caused by: org.apache.maven.project.DependencyResolutionException: Could
> not resolve dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT:
> Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}
> {{Caused by: org.eclipse.aether.collection.DependencyCollectionException:
> Failed to collect dependencies at
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException:
> Failed to read artifact descriptor for
> com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.apache.maven.model.resolution.UnresolvableModelException:
> Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has elapsed or updates are forced}}
> {{... stack omitted ...}}{{ }}
> {{Caused by: org.eclipse.aether.resolution.ArtifactResolutionException:
> Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
> [http://artifactory.example.com:8081/artifactory/libs-release] was cached in
> the local repository, resolution will not be reattempted until the update
> interval of central has
[jira] [Comment Edited] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[
https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760200#comment-16760200
]
Michael Osipov edited comment on WAGON-541 at 2/4/19 8:45 PM:
--
bq. It seems like the main thrust of your concern was originally that so much
of the message was repetitive information. What if you instead simply truncated
the output and only showed the first 80 chars of the phrase?
Yes, I think that 90% of the users will see the very same information as the
status code provided in contrast to {{Requested item is quarantined}}. The
problem with 80 chars is that it won't simply scale. Given that almost all
standard phrases are less than 80 chars, we'd we back at the beginning of
message duplication. Having {{Access denied to: , ReasonPhrase:
Forbidden}} does not add any value to the {{Access denied}}.
I am thinking of something like
{code}
my-server
false
{code}
This may work, but I need to evaluate this. I'd be happy if someone could
provide a PR for this.
was (Author: michael-o):
bq. It seems like the main thrust of your concern was originally that so much
of the message was repetitive information. What if you instead simply truncated
the output and only showed the first 80 chars of the phrase?
Yes, I think that 90% of the users will see the very same information as the
status code provided in contrast to {{Requested item is quarantined}}. The
problem with 80 chars is that it won't simply scale. Given that almost all
standard phrases are less than 80 chars, we'd we back at the beginning of
message duplication. Having {{Access denied to: ,
ReasonPhrase: Forbidden}} does not add any value to the {{Access denied}}.
I am thinking of something like
{code}
my-server
false
{code}
This may work, but I need to evaluate this. I'd be happy if someone could
provide a PR for this.
> Command Line Not Showing ReasonPhrase for Errors
>
>
> Key: WAGON-541
> URL: https://issues.apache.org/jira/browse/WAGON-541
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.2.0
> Environment: Windows 10
>Reporter: Aurelie Pluche
>Priority: Minor
> Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG,
> MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG
>
>
> Hi,
> I work in the Azure DevOps Artifacts Packaging team at Microsoft where we
> provide a Maven service to our customers. We often use a Reason-Phrase to
> return information on failed requests to customers. This functionality was
> available in previous versions of maven but seems to have disappeared in
> Maven 3.6.0. Was this intentional?
> I have included screenshots of the cmd line response using two different
> maven versions (3.3.9 and 3.6.0). I intentionally made a call that would
> return a 405 error to be able to get an error response. I also used the same
> package.
> Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[
https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760200#comment-16760200
]
Michael Osipov commented on WAGON-541:
--
bq. It seems like the main thrust of your concern was originally that so much
of the message was repetitive information. What if you instead simply truncated
the output and only showed the first 80 chars of the phrase?
Yes, I think that 90% of the users will see the very same information as the
status code provided in contrast to {{Requested item is quarantined}}. The
problem with 80 chars is that it won't simply scale. Given that almost all
standard phrases are less than 80 chars, we'd we back at the beginning of
message duplication. Having {{Access denied to: ,
ReasonPhrase: Forbidden}} does not add any value to the {{Access denied}}.
I am thinking of something like
{code}
my-server
false
{code}
This may work, but I need to evaluate this. I'd be happy if someone could
provide a PR for this.
> Command Line Not Showing ReasonPhrase for Errors
>
>
> Key: WAGON-541
> URL: https://issues.apache.org/jira/browse/WAGON-541
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.2.0
> Environment: Windows 10
>Reporter: Aurelie Pluche
>Priority: Minor
> Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG,
> MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG
>
>
> Hi,
> I work in the Azure DevOps Artifacts Packaging team at Microsoft where we
> provide a Maven service to our customers. We often use a Reason-Phrase to
> return information on failed requests to customers. This functionality was
> available in previous versions of maven but seems to have disappeared in
> Maven 3.6.0. Was this intentional?
> I have included screenshots of the cmd line response using two different
> maven versions (3.3.9 and 3.6.0). I intentionally made a call that would
> return a 405 error to be able to get an error response. I also used the same
> package.
> Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6563) StackOverflowError when reading deep (1000) project hierarchy
[ https://issues.apache.org/jira/browse/MNG-6563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760196#comment-16760196 ] Mickael Istria commented on MNG-6563: - m2e doesn't scale (at the moment) with "deep" projects. By deep, I mean deep in the sense of Maven parenthood, not necessarily deep on file-system. I wrote this test as an extreme case to cover MNG-6530 in the IDE; but it's indeed not a realistic one. But the deep recursion and the StackOverflowError here hughlught some areas where improvement is possible. Not high priority though. > StackOverflowError when reading deep (1000) project hierarchy > - > > Key: MNG-6563 > URL: https://issues.apache.org/jira/browse/MNG-6563 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Mickael Istria >Priority: Major > > I'm trying to write tests loading huge extreme Maven projects in m2e to check > how it likes it or not and how to improve it. > One of the tests creates 1000 projects, each one being a parent of the other. > When trying to read it, Maven (and thus m2e) crashes with a > StackOverflowError because it deeply recurses on build/initParent methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6527) Add unit tests for org.apache.maven.repository.MavenArtifactMetadata
[ https://issues.apache.org/jira/browse/MNG-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNG-6527. Resolution: Incomplete The PR has been closed on Github already. > Add unit tests for org.apache.maven.repository.MavenArtifactMetadata > > > Key: MNG-6527 > URL: https://issues.apache.org/jira/browse/MNG-6527 > Project: Maven > Issue Type: Test >Reporter: Louis Mills >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > These tests were written by Diffblue Cover. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6563) StackOverflowError when reading deep (1000) project hierarchy
[
https://issues.apache.org/jira/browse/MNG-6563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760176#comment-16760176
]
Karl Heinz Marbaise commented on MNG-6563:
--
So you are creating a structure like this:
{code}
+- parent
+- sub1
+-- sub11
+-sub111
...
{code}
this means a structure with 1000 levels in depth..This is a thing which will
fail in reality cause in Windows you have limits on the path length which do
not allow such a long path..Apart from that I have already worked on projects
which have ca. 1200 modules which are loaded into Eclipse with m2e and worked.
Of course you have to configure memory in different things which is expected
...?
Can you more in detail explain what the intention of such tests would be? I
have written a groovy tool to generate me larger maven multi module structures
which helped me to identify memory issues...?
> StackOverflowError when reading deep (1000) project hierarchy
> -
>
> Key: MNG-6563
> URL: https://issues.apache.org/jira/browse/MNG-6563
> Project: Maven
> Issue Type: Bug
> Components: core
>Reporter: Mickael Istria
>Priority: Major
>
> I'm trying to write tests loading huge extreme Maven projects in m2e to check
> how it likes it or not and how to improve it.
> One of the tests creates 1000 projects, each one being a parent of the other.
> When trying to read it, Maven (and thus m2e) crashes with a
> StackOverflowError because it deeply recurses on build/initParent methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6508) maven profile overwrites test resources
[
https://issues.apache.org/jira/browse/MNG-6508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MNG-6508.
Resolution: Not A Problem
> maven profile overwrites test resources
> ---
>
> Key: MNG-6508
> URL: https://issues.apache.org/jira/browse/MNG-6508
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.3.9, 3.6.0
> Environment: Windows 8.1, Ubuntu 14.04, jdk1.8.0_191
>Reporter: Tsukanov Ilya Vladimirovich
>Priority: Critical
>
> I'm trying to make maven profiles which would use two difference DBMS. DBMS
> configs are stored in maven profiles. Web App gets settings from file
> connection.properties in src/main/resources. There is also a similar file
> with same title connection.properties in src/test/resources and this file
> should be uploaded only during test lyfecycle maven. Then spring core uses
> the DBMS connection settings specified in connection.properties.
> I have problem with maven profile which overwrites resources such as
> src/test/resources/connection.properties on
> src/main/resources/connection.properties from test directory when test
> lifecycle maven is running.
> {code:xml}
>
>
> profile-postgres
>
> true
>
>
>
> org.postgresql.Driver
>
> jdbc:postgresql://127.0.0.1:5432/bulls_and_cows
> postgres
> postgres
> true
> true
> POSTGRESQL
>
> org.hibernate.dialect.PostgreSQL95Dialect
>
> validate
> false
> test
>
>
>
>
> org.postgresql
> postgresql
> 42.2.1
>
>
>
>
> profile-h2
>
> false
>
>
>
> org.h2.Driver
>
> jdbc:h2:mem:h2db;DB_CLOSE_DELAY=-1
> sa
> sa
> true
> true
> H2
>
> org.hibernate.dialect.H2Dialect
>
> create-drop
> false
> compile
>
>
>
> {code}
> This profile overwrites my connection.properties from src/test/resources on
> src/main/resources.
> connection.properties from src/test/resources
> {noformat}
> database.driver_class_name=org.h2.Driver
> database.url=jdbc:h2:mem:h2db;DB_CLOSE_DELAY=-1
> database.username=sa
> database.password=sa
> {noformat}
> connection.properties from src/main/resources
> {noformat}
> database.driver_class_name=${database.driver_class_name}
> database.url=${database.url}
> database.username=${database.username}
> database.password=${database.password}
> {noformat}
> I wrote testResources tag in build tag of root pom file and in build tag of
> profile tag such as
> {code:xml}
>
>
> ${project.basedir}/src/test/resources
> true
>
>
> {code}
> But instead connection.properties from src/main/resources was always used in
> test lifecycle of maven.
> My old failed build where I used profiles from
> https://travis-ci.org/WeDism/BullsAndCows/builds/449051809.
> My repo with master branch
> https://github.com/WeDism/BullsAndCows/blob/master/pom.xml.
> My repo with with_profiles_h2_postgres branch
> https://github.com/WeDism/BullsAndCows/blob/with_profiles_h2_postgres/pom.xml
> Profile profile-postgres should be main such as activeByDefault = true
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6564) Lack of ability to overwrite properties of specified dependencies
[
https://issues.apache.org/jira/browse/MNG-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760173#comment-16760173
]
Karl Heinz Marbaise commented on MNG-6564:
--
If you like to use a more recent version of the dependency than simply write
that in your pom file as you already mentioned. This is a clear hint for some
later reader that you are confident to use a more recent version than defined
by the {{spring-boot-dependencies:bom}}.
If you think about allowing such a thing the following thing could happen:
BOM File 1 defines some properties and a one like this: {{xyz.version}} and BOM
File 2 defines also some properties and cause the maintainers don't know each
other using the same property {{xyz.version}} and now you define the property
in your pom which uses both of the BOM files. So what should be the result? To
be honest that would result in a chaos. You can't define properties for all
existing dependencies.
> Lack of ability to overwrite properties of specified dependencies
> -
>
> Key: MNG-6564
> URL: https://issues.apache.org/jira/browse/MNG-6564
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Rik Schaaf
>Priority: Major
>
> For example, if I want to update the flyway version to 4.2.0 in spring boot
> 1.5 (by default Flyway 3.2.1) I want to do something like this:
> {code:xml}
>
> 4.2.0
> 1.5.17.RELEASE
>
>
>
>
> org.springframework.boot
> spring-boot-dependencies
> ${springboot.version}
> pom
> import
>
>
>
> {code}
> The flyway dependency is already defined in the dependency management of
> spring-boot-dependencies:
> {code:xml}
>
> org.flywaydb
> flyway-core
> ${flyway.version}
>
> {code}
> But that same pom also defines flyway.version to be 3.2.1. When I include the
> flyway dependency in my own dependency management, my application does
> correctly use Flyway 4.2.0, but if I only provide the property, it
> incorrectly uses version 3.2.1, meaning that my property was ignored. I have
> heard from others that you can forcefully override a property by using a
> commandline parameter or an environment variable, but I would prefer to use a
> property in my pom file instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6584) Maven version 3.6.0 does not show ReasonPhrase anymore
[ https://issues.apache.org/jira/browse/MNG-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6584: - Priority: Major (was: Blocker) > Maven version 3.6.0 does not show ReasonPhrase anymore > -- > > Key: MNG-6584 > URL: https://issues.apache.org/jira/browse/MNG-6584 > Project: Maven > Issue Type: Bug >Affects Versions: 3.6.0 >Reporter: Lucas Ludueño >Priority: Major > Fix For: 3.6.1 > > > Hi! I noticed that version 3.6.0 does not show the ReasonPhrase anymore (for > example when you run mvn deploy to a custom Maven service). > With version 3.5.0 the ReasonPhrase is shown in a message like: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on > project mule-module-tooling-service: Failed to deploy artifacts: Could not > transfer artifact > 2b34662a-6937-4581-b954-71ba35a53519:mule-module-tooling-service:jar:mule-plugin:2.1.3 > from/to exchange-repository > (http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven): Failed to > transfer file: > http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven/2b34662a-6937-4581-b954-71ba35a53519/mule-module-tooling-service/2.1.3/mule-module-tooling-service-2.1.3-mule-plugin.jar. > Return code is: 400, ReasonPhrase: my-custom-ReasonPhrase. -> [Help 1] > I am not completely sure if the ReasonPhrase has been removed intentionally. > If the answer is no, can you fix it? If the answer is yes, how can I simulate > the behavior to indicate to someone what was happening? > > Thanks!! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6508) maven profile overwrites test resources
[
https://issues.apache.org/jira/browse/MNG-6508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760148#comment-16760148
]
Karl Heinz Marbaise commented on MNG-6508:
--
Based on the log and your configuration the build in Travis simply failed cause
it's trying to use the postrgres driver which is working as expected cause the
activeByDefault:true is set for the postgres profile.
And the {{connection.properties}} is use from {{src/main/resources}} in cases
where there is no other file like this on the classpath which is usually the
case except someone places an other one on the classpath during the tests
phase. But in this case the activeByDefault controls which driver is being
used. Apart from the above this is not a bug it's intended behavour.
Furthermore such question should be done on the users mailing list first. Apart
from that I strongly recommend never to change/having dependencies controlled
by profiles. If you need different things it would be better to create
separated modules which have different dependencies.
So I will close this. If you have further details what the expected behaviour
is etc. please reopen this issue or ask on the users mailing list.
> maven profile overwrites test resources
> ---
>
> Key: MNG-6508
> URL: https://issues.apache.org/jira/browse/MNG-6508
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.3.9, 3.6.0
> Environment: Windows 8.1, Ubuntu 14.04, jdk1.8.0_191
>Reporter: Tsukanov Ilya Vladimirovich
>Priority: Critical
>
> I'm trying to make maven profiles which would use two difference DBMS. DBMS
> configs are stored in maven profiles. Web App gets settings from file
> connection.properties in src/main/resources. There is also a similar file
> with same title connection.properties in src/test/resources and this file
> should be uploaded only during test lyfecycle maven. Then spring core uses
> the DBMS connection settings specified in connection.properties.
> I have problem with maven profile which overwrites resources such as
> src/test/resources/connection.properties on
> src/main/resources/connection.properties from test directory when test
> lifecycle maven is running.
> {code:xml}
>
>
> profile-postgres
>
> true
>
>
>
> org.postgresql.Driver
>
> jdbc:postgresql://127.0.0.1:5432/bulls_and_cows
> postgres
> postgres
> true
> true
> POSTGRESQL
>
> org.hibernate.dialect.PostgreSQL95Dialect
>
> validate
> false
> test
>
>
>
>
> org.postgresql
> postgresql
> 42.2.1
>
>
>
>
> profile-h2
>
> false
>
>
>
> org.h2.Driver
>
> jdbc:h2:mem:h2db;DB_CLOSE_DELAY=-1
> sa
> sa
> true
> true
> H2
>
> org.hibernate.dialect.H2Dialect
>
> create-drop
> false
> compile
>
>
>
> {code}
> This profile overwrites my connection.properties from src/test/resources on
> src/main/resources.
> connection.properties from src/test/resources
> {noformat}
> database.driver_class_name=org.h2.Driver
> database.url=jdbc:h2:mem:h2db;DB_CLOSE_DELAY=-1
> database.username=sa
> database.password=sa
> {noformat}
> connection.properties from src/main/resources
> {noformat}
> database.driver_class_name=${database.driver_class_name}
> database.url=${database.url}
> database.username=${database.username}
> database.password=${database.password}
> {noformat}
> I wrote testResources tag in build tag of root pom file and in build tag of
> profile tag such as
> {code:xml}
>
>
> ${project.basedir}/src/test/resources
> true
>
>
> {code}
> But instead connection.properties from src/main/resources was always used in
> test lifecycle of maven.
> My old failed build where I used profiles from
> https://travis-ci.org/WeDism/BullsAndCows/builds/449051809.
> My repo with master branch
> https://github.com/WeDism/BullsAndCows/blob/master/pom.xml.
> My repo with with_profiles_h2_postgres branch
> https://github.com/WeDism/BullsAndCows/blob/with_profiles_h2_postgres/pom.xml
> Profile profile-postgres should be main such as activeByDefault = true
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] eolivelli edited a comment on issue #5: [MCHECKSTYLE-353] - Don't resolve any dependencies
eolivelli edited a comment on issue #5: [MCHECKSTYLE-353] - Don't resolve any dependencies URL: https://github.com/apache/maven-checkstyle-plugin/pull/5#issuecomment-460376346 @zregvart thank you so much for you work seems that this patch is against another issue: https://issues.apache.org/jira/browse/MCHECKSTYLE-166 For sure we are missing important integration tests around core checkstyle features. We have to add tests to prove MCHECKSTYLE-166 I guess this patch will break that behaviour. I guess the safest way would be to add a new mojo. Otherwise we should introduce some more complex implementation which allows to not download/resolve dependencies. cc @rfscholte This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services
[GitHub] eolivelli commented on issue #5: [MCHECKSTYLE-353] - Don't resolve any dependencies
eolivelli commented on issue #5: [MCHECKSTYLE-353] - Don't resolve any dependencies URL: https://github.com/apache/maven-checkstyle-plugin/pull/5#issuecomment-460376346 @zregvart than you so much for you work seems that this patch is against another issue: https://issues.apache.org/jira/browse/MCHECKSTYLE-166 For sure we are missing important integration tests around core checkstyle features. We have to add tests to prove MCHECKSTYLE-166 I guess this patch will break that behaviour. I guess the safest way would be to add a new mojo. Otherwise we should introduce some more complex implementation which allows to not download/resolve dependencies. cc @rfscholte This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services
[jira] [Updated] (MNG-6584) Maven version 3.6.0 does not show ReasonPhrase anymore
[ https://issues.apache.org/jira/browse/MNG-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNG-6584: --- Fix Version/s: 3.6.1 > Maven version 3.6.0 does not show ReasonPhrase anymore > -- > > Key: MNG-6584 > URL: https://issues.apache.org/jira/browse/MNG-6584 > Project: Maven > Issue Type: Bug >Reporter: Lucas Ludueño >Priority: Blocker > Fix For: 3.6.1 > > > Hi! I noticed that version 3.6.0 does not show the ReasonPhrase anymore (for > example when you run mvn deploy to a custom Maven service). > With version 3.5.0 the ReasonPhrase is shown in a message like: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on > project mule-module-tooling-service: Failed to deploy artifacts: Could not > transfer artifact > 2b34662a-6937-4581-b954-71ba35a53519:mule-module-tooling-service:jar:mule-plugin:2.1.3 > from/to exchange-repository > (http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven): Failed to > transfer file: > http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven/2b34662a-6937-4581-b954-71ba35a53519/mule-module-tooling-service/2.1.3/mule-module-tooling-service-2.1.3-mule-plugin.jar. > Return code is: 400, ReasonPhrase: my-custom-ReasonPhrase. -> [Help 1] > I am not completely sure if the ReasonPhrase has been removed intentionally. > If the answer is no, can you fix it? If the answer is yes, how can I simulate > the behavior to indicate to someone what was happening? > > Thanks!! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6584) Maven version 3.6.0 does not show ReasonPhrase anymore
[ https://issues.apache.org/jira/browse/MNG-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNG-6584: --- Affects Version/s: 3.6.0 > Maven version 3.6.0 does not show ReasonPhrase anymore > -- > > Key: MNG-6584 > URL: https://issues.apache.org/jira/browse/MNG-6584 > Project: Maven > Issue Type: Bug >Affects Versions: 3.6.0 >Reporter: Lucas Ludueño >Priority: Blocker > Fix For: 3.6.1 > > > Hi! I noticed that version 3.6.0 does not show the ReasonPhrase anymore (for > example when you run mvn deploy to a custom Maven service). > With version 3.5.0 the ReasonPhrase is shown in a message like: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on > project mule-module-tooling-service: Failed to deploy artifacts: Could not > transfer artifact > 2b34662a-6937-4581-b954-71ba35a53519:mule-module-tooling-service:jar:mule-plugin:2.1.3 > from/to exchange-repository > (http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven): Failed to > transfer file: > http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven/2b34662a-6937-4581-b954-71ba35a53519/mule-module-tooling-service/2.1.3/mule-module-tooling-service-2.1.3-mule-plugin.jar. > Return code is: 400, ReasonPhrase: my-custom-ReasonPhrase. -> [Help 1] > I am not completely sure if the ReasonPhrase has been removed intentionally. > If the answer is no, can you fix it? If the answer is yes, how can I simulate > the behavior to indicate to someone what was happening? > > Thanks!! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (MNG-6584) Maven version 3.6.0 does not show ReasonPhrase anymore
[ https://issues.apache.org/jira/browse/MNG-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy reopened MNG-6584: > Maven version 3.6.0 does not show ReasonPhrase anymore > -- > > Key: MNG-6584 > URL: https://issues.apache.org/jira/browse/MNG-6584 > Project: Maven > Issue Type: Bug >Reporter: Lucas Ludueño >Priority: Blocker > > Hi! I noticed that version 3.6.0 does not show the ReasonPhrase anymore (for > example when you run mvn deploy to a custom Maven service). > With version 3.5.0 the ReasonPhrase is shown in a message like: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on > project mule-module-tooling-service: Failed to deploy artifacts: Could not > transfer artifact > 2b34662a-6937-4581-b954-71ba35a53519:mule-module-tooling-service:jar:mule-plugin:2.1.3 > from/to exchange-repository > (http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven): Failed to > transfer file: > http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven/2b34662a-6937-4581-b954-71ba35a53519/mule-module-tooling-service/2.1.3/mule-module-tooling-service-2.1.3-mule-plugin.jar. > Return code is: 400, ReasonPhrase: my-custom-ReasonPhrase. -> [Help 1] > I am not completely sure if the ReasonPhrase has been removed intentionally. > If the answer is no, can you fix it? If the answer is yes, how can I simulate > the behavior to indicate to someone what was happening? > > Thanks!! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MDEPLOY-251) generatePom=false not working with 3.0.0-M1
Robert Lieske created MDEPLOY-251:
-
Summary: generatePom=false not working with 3.0.0-M1
Key: MDEPLOY-251
URL: https://issues.apache.org/jira/browse/MDEPLOY-251
Project: Maven Deploy Plugin
Issue Type: Bug
Affects Versions: 3.0.0-M1
Reporter: Robert Lieske
Steps to reproduce:
{{mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
-DgroupId=test1 -DartifactId=test1 -Dversion=1.0-SNAPSHOT}}
{{mvn clean package deploy:deploy-file -Dfile=target/test1-1.0-SNAPSHOT.jar
-DgeneratePom=false -DgroupId=test1 -DartifactId=test1 -Dversion=1.0-SNAPSHOT
-DrepositoryId=snapshotRepository -Durl=${snapshotRepositoryUrl}}}
produces:
{quote}[INFO] --- maven-deploy-plugin:2.8.2:deploy-file (default-cli) @ test1
---
Downloading from snapshotRepository:
http://xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/maven-metadata.xml
Downloaded from snapshotRepository:
http://de01-xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/maven-metadata.xml
(583 B at 2.0 kB/s)
Uploading to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/test1-1.0-20190204.162443-2.jar
Uploaded to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/test1-1.0-20190204.162443-2.jar
(2.4 kB at 8.1 kB/s)
Downloading from snapshotRepository:
http://xxx/repository/snapshots/test1/test1/maven-metadata.xml
Downloaded from snapshotRepository:
http://xxx/repository/snapshots/test1/test1/maven-metadata.xml (268 B at 1.8
kB/s)
Uploading to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/maven-metadata.xml
Uploaded to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/maven-metadata.xml
(583 B at 3.3 kB/s)
Uploading to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/maven-metadata.xml
Uploaded to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/maven-metadata.xml (268 B at 1.4
kB/s)
[INFO]
{quote}
changing the version of the maven-deploy-plugin in pom.xml to
{{}}
maven-deploy-plugin
3.0.0-M1
the same call to
{{mvn clean package deploy:deploy-file -Dfile=target/test1-1.0-SNAPSHOT.jar
-DgeneratePom=false -DgroupId=test1 -DartifactId=test1 -Dversion=1.0-SNAPSHOT
-DrepositoryId=snapshotRepository -Durl=${snapshotRepositoryUrl}}}
produces:
{quote}[INFO] --- maven-deploy-plugin:3.0.0-M1:deploy-file (default-cli) @
test1 ---
Downloading from snapshotRepository:
http://xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/maven-metadata.xml
Downloaded from snapshotRepository:
http://xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/maven-metadata.xml
(583 B at 1.6 kB/s)
Uploading to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/test1-1.0-20190204.162607-3.jar
Uploaded to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/test1-1.0-20190204.162607-3.jar
(2.4 kB at 7.7 kB/s)
{color:#d04437}Uploading to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/test1-1.0-20190204.162607-3.pom{color}
{color:#d04437}Uploaded to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/test1-1.0-20190204.162607-3.pom
(2.7 kB at 9.6 kB/s){color}
Downloading from snapshotRepository:
http://xxx/repository/snapshots/test1/test1/maven-metadata.xml
Downloaded from snapshotRepository:
http://xxx/repository/snapshots/test1/test1/maven-metadata.xml (268 B at 2.6
kB/s)
Uploading to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/maven-metadata.xml
Uploaded to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/1.0-SNAPSHOT/maven-metadata.xml
(754 B at 4.0 kB/s)
Uploading to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/maven-metadata.xml
Uploaded to snapshotRepository:
http://xxx/repository/snapshots/test1/test1/maven-metadata.xml (268 B at 1.5
kB/s)
[INFO]
{quote}
Which also deploys a POM - which is not what we want!
NOTE: there is a similar issue with the maven-install-plugin
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1676#comment-1676 ] Brian Fox commented on WAGON-541: - A system property isn't a great solution. For companies trying to roll out a repo framework that does provide useful information, requiring all systems to set that property is essentially a non-starter. It seems like the main thrust of your concern was originally that so much of the message was repetitive information. What if you instead simply truncated the output and only showed the first 80 chars of the phrase? > Command Line Not Showing ReasonPhrase for Errors > > > Key: WAGON-541 > URL: https://issues.apache.org/jira/browse/WAGON-541 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Windows 10 >Reporter: Aurelie Pluche >Priority: Minor > Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, > MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG > > > Hi, > I work in the Azure DevOps Artifacts Packaging team at Microsoft where we > provide a Maven service to our customers. We often use a Reason-Phrase to > return information on failed requests to customers. This functionality was > available in previous versions of maven but seems to have disappeared in > Maven 3.6.0. Was this intentional? > I have included screenshots of the cmd line response using two different > maven versions (3.3.9 and 3.6.0). I intentionally made a call that would > return a 405 error to be able to get an error response. I also used the same > package. > Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINSTALL-156) generatePom=false not working with 3.0.0-M1
Robert Lieske created MINSTALL-156:
--
Summary: generatePom=false not working with 3.0.0-M1
Key: MINSTALL-156
URL: https://issues.apache.org/jira/browse/MINSTALL-156
Project: Maven Install Plugin
Issue Type: Bug
Affects Versions: 3.0.0-M1
Reporter: Robert Lieske
Steps to reproduce:
{{mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
-DgroupId=test1 -DartifactId=test1 -Dversion=1.0-SNAPSHOT}}
{{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
-DgeneratePom=false}}
produces:
{quote}[INFO] --- maven-install-plugin:2.5.2:install-file (default-cli) @ test1
---
[INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
[INFO]
{quote}
changing the version of the maven-install-plugin in pom.xml to
{{}}
{{ maven-install-plugin}}
{{ 3.0.0-M1}}
{{ }}
the same call to
{{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
-DgeneratePom=false}}
produces:
{quote}[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @
test1 ---
[INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
[INFO] Installing
C:\Users\xxx\AppData\Local\Temp\test1-1.0-SNAPSHOT7157743325898943802.pom to
C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
[INFO]
{quote}
Which also installs a POM - which is not what we want!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MENFORCER-326) Log output
Thomas Nikolay created MENFORCER-326:
Summary: Log output
Key: MENFORCER-326
URL: https://issues.apache.org/jira/browse/MENFORCER-326
Project: Maven Enforcer Plugin
Issue Type: Improvement
Components: Plugin
Affects Versions: 3.0.0-M2
Reporter: Thomas Nikolay
Please improve the output - because it is not clear which rule execution raise
an error
{noformat}
INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce (enforce-plugin-versions) @
bhs-ws-interface ---
[INFO] Adding ignore: module-info
[INFO] Adding ignore: META-INF/versions/*/module-info
[INFO] Adding ignore: org.jaxen.*
[INFO] Adding ignore: org.xml.sax.*
[INFO] Adding ignore: com.l2fprod.common.*
[INFO] Adding ignore: net.sf.json.*
[INFO] Adding ignore: com.eviware.soapui.analytics.providers.*
[INFO] Adding ignore: net.sf.ezmorph.*
[INFO] Adding ignore: org.apache.xmlbeans.*
[INFO] Adding ignore: schemaorg_apache_xmlbeans.system.*
[INFO] Adding ignore: org.apache.commons.httpclient.*
[INFO] Adding ignore: org.w3c.dom.*
[INFO] Adding ignore: org.aopalliance.*
[INFO] Adding ignorable dependency: null:jaxb-core:null
[INFO] Adding ignore: com.sun.istack.*
[INFO] Adding ignorable dependency: null:xml-apis:null
[INFO] Adding ignore: org.w3c.dom.*
[INFO] Adding ignore: javax.xml.*
[INFO] Adding ignorable dependency: null:cxf-bundle-jaxrs:null
[INFO] Adding ignore: org.apache.cxf.*
[INFO] Adding ignorable dependency: null:asm:null
[INFO] Adding ignore: org.objectweb.*
[INFO] Adding ignorable dependency: null:shtrihjavapos:null
[INFO] Adding ignore: *
[INFO] Adding ignorable dependency: null:commons-collections:null
[INFO] Adding ignore: org.apache.commons.collections.*
[INFO] Adding ignorable dependency: null:commons-beanutils:null
[INFO] Adding ignore: org.apache.commons.beanutils.*
[INFO] Adding ignorable dependency: null:lib-common-utils:null
[INFO] Adding ignore: org.springframework.beans.CachedIntrospectionResults
[INFO] Adding ignorable dependency: null:bcprov-jdk15on:null
[INFO] Adding ignore: org.bouncycastle.*
[INFO] Adding ignorable dependency: null:bcprov-ext-jdk15on:null
[INFO] Adding ignore: org.bouncycastle.*
[INFO] Adding ignorable dependency: null:geronimo-jaxws_2.2_spec:null
[INFO] Adding ignore: org.apache.geronimo.osgi.locator.*
[INFO] Adding ignorable dependency: null:org.eclipse.jdt.core:null
[INFO] Adding ignore: org.eclipse.jdt.*
[INFO] Adding ignorable dependency: null:mod-reporting-if:null
[INFO] Adding ignorable dependency: null:namespace:null
[INFO] Adding ignore: javax.xml.*
[INFO] Adding ignorable dependency: null:mod-md-master-data-api:null
[INFO] Adding ignorable dependency: null:stax-api:null
[INFO] Adding ignore: javax.xml.stream.*
[INFO] Adding ignorable dependency: null:barcode4j-light:null
[INFO] Adding ignore: *
[INFO] Adding ignorable dependency: null:mod-data-provider-server:null
[INFO] Adding ignore: com.sap.*
[INFO] Adding ignorable dependency: null:commons-logging-api:null
[INFO] Adding ignore: org.apache.commons.logging.*
[INFO] Adding ignorable dependency: org.apache.derby:derby:null
[INFO] Adding ignore: org.apache.derby.*
[INFO] Adding ignorable dependency: org.apache.xmlgraphics:batik-ext:null
[INFO] Adding ignore: org.w3c.*
[INFO] Adding ignorable dependency: jfree:jcommon:null
[INFO] Adding ignore: com.keypoint.PngEncoder
[INFO] Adding ignorable dependency: aopalliance:aopalliance:null
[INFO] Adding ignore: org.aopalliance*
[INFO] Adding ignorable dependency:
org.apache.geronimo.specs:geronimo-javamail_1.4_spec:null
[INFO] Adding ignore: javax.mail.*
[INFO] Adding ignorable dependency: org.mortbay.jetty:servlet-api:null
[INFO] Adding ignore: javax.servlet.*
[INFO] Adding ignorable dependency: com.google.code.findbugs:jsr305:null
[INFO] Adding ignore: javax.annotation.*
[WARNING] Could not find org.powermock:powermock-reflect:jar:1.7.3:test at null
[WARNING] Could not find
org.powermock:powermock-module-junit4-common:jar:1.7.3:test at null
[WARNING] Could not find
org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.7.18:compile at null
[WARNING] Could not find
org.codehaus.jackson:jackson-mapper-asl:jar:1.9.11:compile at null
[WARNING] Could not find
org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.7.18:compile at null
[WARNING] Could not find
org.powermock:powermock-module-junit4-legacy:jar:1.7.3:test at null
[WARNING] Could not find org.codehaus.jackson:jackson-xc:jar:1.9.11:compile at
null
[WARNING] Could not find org.powermock:powermock-api-mockito:jar:1.7.3:test at
null
[WARNING] Could not find org.mockito:mockito-core:jar:1.10.19:test at null
[WARNING] Could not find org.apache.derby:derby:jar:10.10.2.0:test at null
[WARNING] Could not find
com.smartbear.soapui:soapui-maven-plugin:jar:5.2.1:test at null
[WARNING] Could not find org.powermock:powermock-api-support:jar:1.7.3:test at
null
[WARNING] Could not find
org.powermock:powermock-classloading-base:jar:1.7.3:test
[jira] [Commented] (MENFORCER-168) In a multi module project "bannedDependencies" rule tries to resolve project artifacts from external repository
[
https://issues.apache.org/jira/browse/MENFORCER-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16759951#comment-16759951
]
Martijn Dashorst commented on MENFORCER-168:
The enforcer plugin fails without mvn install also in our multi-module project.
I've included the full stack trace below:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2:enforce (default-cli)
on project iridium-common-dao: Execution default-cli of goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2:enforce failed:
org.apache.maven.shared.dependency.graph.DependencyGraphBuilderException: Could
not resolve following dependencies:
[nl.topicus.iridium:iridium-common-beans:jar:9.8.0-SNAPSHOT (compile),
nl.topicus.iridium:iridium-common-entities:jar:9.8.0-SNAPSHOT (compile)]: Could
not resolve dependencies for project
nl.topicus.iridium:iridium-common-dao:ejb:9.8.0-SNAPSHOT: The following
artifacts could not be resolved:
nl.topicus.iridium:iridium-common-beans:jar:9.8.0-SNAPSHOT,
nl.topicus.iridium:iridium-common-entities:jar:9.8.0-SNAPSHOT: Could not find
artifact nl.topicus.iridium:iridium-common-beans:jar:9.8.0-SNAPSHOT in
topicus-repository (https://repo.topicusonderwijs.nl/artifactory/maven/) ->
[Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2:enforce (default-cli)
on project iridium-common-dao: Execution default-cli of goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2:enforce failed:
org.apache.maven.shared.dependency.graph.DependencyGraphBuilderException: Could
not resolve following dependencies:
[nl.topicus.iridium:iridium-common-beans:jar:9.8.0-SNAPSHOT (compile),
nl.topicus.iridium:iridium-common-entities:jar:9.8.0-SNAPSHOT (compile)]
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2:enforce failed:
org.apache.maven.shared.dependency.graph.DependencyGraphBuilderException: Could
not resolve following dependencies:
[nl.topicus.iridium:iridium-common-beans:jar:9.8.0-SNAPSHOT (compile),
nl.topicus.iridium:iridium-common-entities:jar:9.8.0-SNAPSHOT (compile)]
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute
