[ANN] Release Maven Dependency Plugin 3.8.0 released
The Apache Maven team is pleased to announce the release of the Maven Dependency Plugin version 3.8.0. https://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.8.0 Release Notes - Maven Dependency Plugin - Version 3.8.0 ** Task * [MDEP-913] - dependency:collect missing from index page ** Dependency upgrade * [MDEP-903] - Upgrade to Doxia 2.0.0 Milestone Stack * [MDEP-951] - Upgrade to Parent 43 NOTE: Read the details on this release here: https://cwiki.apache.org/confluence/display/MAVEN/Towards+Doxia+2.0.0+Stack Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)
On 26.06.24 21:26, Robert Turner wrote: On Wed, Jun 26, 2024 at 5:12 AM Karl Heinz Marbaise wrote: Hi, On 26.06.24 03:51, Robert Turner wrote: On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise wrote: Hi, I'm not sure if I understand your problem correct, because based on the copy-dependencies goal as stated in the docs: "Goal that copies the project dependencies from the repository to a defined location." it copies as stated... The question is what you expect to be copied and furthermore the the more important question: Why do you need to copy those parts? Sorry if it wasn't very clear -- I have done a bit of digging into it just now, and hopefully this additional information will help to explain what I'm seeing (and I think it makes sense now, but still has an undesirable result). (see below) It was not the question of digging into that... The question was: Why do need to use copy-dependencies in your build? Ah, sorry I misunderstood. That is a very relevant question, and for the most part, we do not need the dependencies with our packages, except for one or two, where they become an output artifact for executing from the command line (and the dependencies either need to be in the JAR or accessible to the environment executing it. In such case I would suggest, either to use maven-shade-plugin to create an executable jar or maven-assembly-plugin instead of coping deps into a lib directory... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)
On Wed, Jun 26, 2024 at 6:04 AM Tamás Cservenák wrote: > Howdy, > > So here is how one can figure this out: using the "reverse tree" feature. > > Modified your reproducer command like this: > > $ $ rm -rf maven-cache && > MAVEN_ARGS="-Dmaven.repo.local.recordReverseTree=true > -Dmaven.repo.local=./maven-cache" mvn -V package > > after invocation take a peek at recorded tracking data: > $ cat > > maven-cache/log4j/log4j/1.2.12/.tracking/org.apache.maven.plugins_maven-dependency-plugin_jar_3.7.1.dep > log4j:log4j:pom:1.2.12 > log4j:log4j:jar:1.2.12 (compile) (plugin) > commons-logging:commons-logging:jar:1.1 (compile) (plugin) > commons-digester:commons-digester:jar:1.8 (compile) (plugin) > org.apache.velocity:velocity-tools:jar:2.0 (compile) (plugin) > org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1 (compile) > (plugin) > org.apache.maven.reporting:maven-reporting-impl:jar:3.2.0 > (compile) (plugin) > org.apache.maven.plugins:maven-dependency-plugin:jar:3.7.1 () > (plugin) > > Repository: central (https://repo.maven.apache.org/maven2/, default, > releases) > > So, this node was _collected_ due commons-logging 1.1, and POM > commons-logging 1.1 really states dep on log4j 1.2.12: > > https://repo.maven.apache.org/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.pom > > But, as Karl said, your local repository contains POM only, not the JAR, > and this JAR was _not resolved_ (as its parent is "loser", was > eliminated as commons-logging 1.2 prevailed): > https://gist.github.com/cstamas/2843a4dacee418026f7f18206eabd315 > > The POM is downloaded to build a "dirty graph" of the dependency tree, and > in the next step is being _eliminated_ due reason noted in the tree, in > this case "(conflicts with 1.2)". > See > > https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-11/common-misconceptions.html > > So the POM is downloaded in the "collect" step, but is eliminated in the > "transform" step, and log4j (nor commons-logging 1.1) is never "resolved" > (JAR downloaded) that would be last step. > > Thanks > T > Thanks for the detailed explanation -- it is much appreciated. (as well as the suggestion to bump up the logging on Maven to find the details on what is being fetched). > > On Wed, Jun 26, 2024 at 11:11 AM Karl Heinz Marbaise > wrote: > > > Hi, > > > > On 26.06.24 03:51, Robert Turner wrote: > > > On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise > > > wrote: > > > > > >> Hi, > > >> > > >> I'm not sure if I understand your problem correct, because based on > the > > >> copy-dependencies goal as stated in the docs: > > >> > > >> "Goal that copies the project dependencies from the repository to a > > >> defined location." > > >> > > >> it copies as stated... > > >> > > >> The question is what you expect to be copied and furthermore the the > > >> more important question: Why do you need to copy those parts? > > >> > > >> > > > Sorry if it wasn't very clear -- I have done a bit of digging into it > > just > > > now, and hopefully this additional information will help to explain > what > > > I'm seeing (and I think it makes sense now, but still has an > > > undesirable result). (see below) > > > > It was not the question of digging into that... The question was: Why do > > need to use copy-dependencies in your build? > > > > > > > > > > > > > > > >> It would also very helpful to have a full pom file of that project or > > >> maybe a link to a github project (or alike)? > > >> > > > > > > > > > I think what is happening is that `maven-dependency-plugin` (3.7.1) > > depends > > > transitively on log4j 1.2.12 -- I'm still working through trying to > > figure > > > that out though. > > > Originally (a few months ago), I worked around it a while back by > simply > > > disabling the copying of the dependencies to the target file (as > visible > > by > > > the "comments" in the pom.xml [1] file), but that wasn't really ideal. > > > > > > > > > To reproduce, I created a trivial pom.xml [1], and used a clean local > > > repository for Maven, executing Maven as follows: > > > > > > rm -rf maven-cache && > MAVEN_OPTS=&
Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)
On Wed, Jun 26, 2024 at 5:12 AM Karl Heinz Marbaise wrote: > Hi, > > On 26.06.24 03:51, Robert Turner wrote: > > On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise > > wrote: > > > >> Hi, > >> > >> I'm not sure if I understand your problem correct, because based on the > >> copy-dependencies goal as stated in the docs: > >> > >> "Goal that copies the project dependencies from the repository to a > >> defined location." > >> > >> it copies as stated... > >> > >> The question is what you expect to be copied and furthermore the the > >> more important question: Why do you need to copy those parts? > >> > >> > > Sorry if it wasn't very clear -- I have done a bit of digging into it > just > > now, and hopefully this additional information will help to explain what > > I'm seeing (and I think it makes sense now, but still has an > > undesirable result). (see below) > > It was not the question of digging into that... The question was: Why do > need to use copy-dependencies in your build? Ah, sorry I misunderstood. That is a very relevant question, and for the most part, we do not need the dependencies with our packages, except for one or two, where they become an output artifact for executing from the command line (and the dependencies either need to be in the JAR or accessible to the environment executing it. > > > > > > > >> It would also very helpful to have a full pom file of that project or > >> maybe a link to a github project (or alike)? > >> > > > > > > I think what is happening is that `maven-dependency-plugin` (3.7.1) > depends > > transitively on log4j 1.2.12 -- I'm still working through trying to > figure > > that out though. > > Originally (a few months ago), I worked around it a while back by simply > > disabling the copying of the dependencies to the target file (as visible > by > > the "comments" in the pom.xml [1] file), but that wasn't really ideal. > > > > > > To reproduce, I created a trivial pom.xml [1], and used a clean local > > repository for Maven, executing Maven as follows: > > > > rm -rf maven-cache && MAVEN_OPTS="-Dmaven.repo.local=./maven-cache" > mvn > > package > > > > This "builds" the trivial empty JAR file, and copies no dependencies (as > > none are declared). > > > > > > However, my local Maven repository (cache) now contains a really old > > version of log4j: > > > > $ ls maven-cache/log4j/log4j/1.2.12/ > > _remote.repositories log4j-1.2.12.pom log4j-1.2.12.pom.sha1 > > first that's not quite correct, because you have only the "pom" file not > the jar here... > Doh -- not sure how I missed that, but you are of course correct. I'm trying to figure out why I have it on the build node now -- maybe I've been chasing a red herring, or maybe I was building the "site" goal or something -- I will narrow this down. But without the JAR, the scanner shouldn't be finding it -- however, I do see the JAR file on the build node, so now I need to track down which job, and when / how it got there. > > Furthermore having a pom file on your hard disk does not mean any code > is being executed... furthermore the log4shell part was to have service > started which accepts things etc... > Yep, I totally agree -- I don't think it's running, so I don't think it's a risk --- just annoying to have to get exclusions approved, etc. > > > Kind regards > Karl Heinz Marbaise > > > > > Reviewing the downloading order from the central repository, log4j-1.2.12 > > seems to come after commons-logging-1.1, and as part of the > > `dependency:3.7.1:copy-dependencies` goal. [3] > > > > > > > >> > >> Another point is: do you use the most recent version of all plugins in > >> your build ? > >> > > > > In the sample pom.xml, I am using the latest `maven-dependency-plugin` > > (3.7.1) -- in this specific sample, I didn't override all the system > > plug-ins with the latest version to keep the sample file smaller. > However, > > we generally keep our plug-ins up-to-date every few months. > > > > ..snipped original posting... > > > > > > > > The "problem" is not that the old log4j gets copied to the output folder, > > it's that it is fetched into the local Maven cache / repository, which is > > then picked up by se
Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)
On Wed, Jun 26, 2024 at 1:36 AM Nils Breunese wrote: > Robert Turner wrote: > > > The "problem" is not that the old log4j gets copied to the output folder, > > it's that it is fetched into the local Maven cache / repository, which is > > then picked up by security tooling (which of course complains that it is > > ancient and has vulnerabilities). > > There is no guarantee that the artifacts in the local Maven repository are > actually executed or part of the result of your build. I don’t know if it’s > an option to change the scanning strategy in your situation, but I would > suggest executing builds in a CI environment that doesn’t provide access to > the public internet (use a repository manager like Artifactory or Nexus and > have it proxy any public repositories you need, like Maven Central), > optionally scanning build artifacts before they get deployed, and > definitely scanning deployed artifacts periodically, because > vulnerabilities can get discovered after deployment time. I wouldn’t then > worry about the contents of the local Maven repository after a build so > much anymore. > > Nils. > > Yeah, those are options of course -- I was hoping to avoid making lots of changes to the environment if possible (lots of work of course). Thanks for the suggestions.
Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)
Howdy, So here is how one can figure this out: using the "reverse tree" feature. Modified your reproducer command like this: $ $ rm -rf maven-cache && MAVEN_ARGS="-Dmaven.repo.local.recordReverseTree=true -Dmaven.repo.local=./maven-cache" mvn -V package after invocation take a peek at recorded tracking data: $ cat maven-cache/log4j/log4j/1.2.12/.tracking/org.apache.maven.plugins_maven-dependency-plugin_jar_3.7.1.dep log4j:log4j:pom:1.2.12 log4j:log4j:jar:1.2.12 (compile) (plugin) commons-logging:commons-logging:jar:1.1 (compile) (plugin) commons-digester:commons-digester:jar:1.8 (compile) (plugin) org.apache.velocity:velocity-tools:jar:2.0 (compile) (plugin) org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1 (compile) (plugin) org.apache.maven.reporting:maven-reporting-impl:jar:3.2.0 (compile) (plugin) org.apache.maven.plugins:maven-dependency-plugin:jar:3.7.1 () (plugin) Repository: central (https://repo.maven.apache.org/maven2/, default, releases) So, this node was _collected_ due commons-logging 1.1, and POM commons-logging 1.1 really states dep on log4j 1.2.12: https://repo.maven.apache.org/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.pom But, as Karl said, your local repository contains POM only, not the JAR, and this JAR was _not resolved_ (as its parent is "loser", was eliminated as commons-logging 1.2 prevailed): https://gist.github.com/cstamas/2843a4dacee418026f7f18206eabd315 The POM is downloaded to build a "dirty graph" of the dependency tree, and in the next step is being _eliminated_ due reason noted in the tree, in this case "(conflicts with 1.2)". See https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-11/common-misconceptions.html So the POM is downloaded in the "collect" step, but is eliminated in the "transform" step, and log4j (nor commons-logging 1.1) is never "resolved" (JAR downloaded) that would be last step. Thanks T On Wed, Jun 26, 2024 at 11:11 AM Karl Heinz Marbaise wrote: > Hi, > > On 26.06.24 03:51, Robert Turner wrote: > > On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise > > wrote: > > > >> Hi, > >> > >> I'm not sure if I understand your problem correct, because based on the > >> copy-dependencies goal as stated in the docs: > >> > >> "Goal that copies the project dependencies from the repository to a > >> defined location." > >> > >> it copies as stated... > >> > >> The question is what you expect to be copied and furthermore the the > >> more important question: Why do you need to copy those parts? > >> > >> > > Sorry if it wasn't very clear -- I have done a bit of digging into it > just > > now, and hopefully this additional information will help to explain what > > I'm seeing (and I think it makes sense now, but still has an > > undesirable result). (see below) > > It was not the question of digging into that... The question was: Why do > need to use copy-dependencies in your build? > > > > > > > > > >> It would also very helpful to have a full pom file of that project or > >> maybe a link to a github project (or alike)? > >> > > > > > > I think what is happening is that `maven-dependency-plugin` (3.7.1) > depends > > transitively on log4j 1.2.12 -- I'm still working through trying to > figure > > that out though. > > Originally (a few months ago), I worked around it a while back by simply > > disabling the copying of the dependencies to the target file (as visible > by > > the "comments" in the pom.xml [1] file), but that wasn't really ideal. > > > > > > To reproduce, I created a trivial pom.xml [1], and used a clean local > > repository for Maven, executing Maven as follows: > > > > rm -rf maven-cache && MAVEN_OPTS="-Dmaven.repo.local=./maven-cache" > mvn > > package > > > > This "builds" the trivial empty JAR file, and copies no dependencies (as > > none are declared). > > > > > > However, my local Maven repository (cache) now contains a really old > > version of log4j: > > > > $ ls maven-cache/log4j/log4j/1.2.12/ > > _remote.repositories log4j-1.2.12.pom log4j-1.2.12.pom.sha1 > > first that's not quite correct, because you have only the "pom" file not > the jar here... > > Furthermore having a pom file on your hard disk does not mean any code > is being executed... furthermore the log4shell part was to have service > started which accepts things etc
Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)
Hi, On 26.06.24 03:51, Robert Turner wrote: On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise wrote: Hi, I'm not sure if I understand your problem correct, because based on the copy-dependencies goal as stated in the docs: "Goal that copies the project dependencies from the repository to a defined location." it copies as stated... The question is what you expect to be copied and furthermore the the more important question: Why do you need to copy those parts? Sorry if it wasn't very clear -- I have done a bit of digging into it just now, and hopefully this additional information will help to explain what I'm seeing (and I think it makes sense now, but still has an undesirable result). (see below) It was not the question of digging into that... The question was: Why do need to use copy-dependencies in your build? It would also very helpful to have a full pom file of that project or maybe a link to a github project (or alike)? I think what is happening is that `maven-dependency-plugin` (3.7.1) depends transitively on log4j 1.2.12 -- I'm still working through trying to figure that out though. Originally (a few months ago), I worked around it a while back by simply disabling the copying of the dependencies to the target file (as visible by the "comments" in the pom.xml [1] file), but that wasn't really ideal. To reproduce, I created a trivial pom.xml [1], and used a clean local repository for Maven, executing Maven as follows: rm -rf maven-cache && MAVEN_OPTS="-Dmaven.repo.local=./maven-cache" mvn package This "builds" the trivial empty JAR file, and copies no dependencies (as none are declared). However, my local Maven repository (cache) now contains a really old version of log4j: $ ls maven-cache/log4j/log4j/1.2.12/ _remote.repositories log4j-1.2.12.pom log4j-1.2.12.pom.sha1 first that's not quite correct, because you have only the "pom" file not the jar here... Furthermore having a pom file on your hard disk does not mean any code is being executed... furthermore the log4shell part was to have service started which accepts things etc... Kind regards Karl Heinz Marbaise Reviewing the downloading order from the central repository, log4j-1.2.12 seems to come after commons-logging-1.1, and as part of the `dependency:3.7.1:copy-dependencies` goal. [3] Another point is: do you use the most recent version of all plugins in your build ? In the sample pom.xml, I am using the latest `maven-dependency-plugin` (3.7.1) -- in this specific sample, I didn't override all the system plug-ins with the latest version to keep the sample file smaller. However, we generally keep our plug-ins up-to-date every few months. ..snipped original posting... The "problem" is not that the old log4j gets copied to the output folder, it's that it is fetched into the local Maven cache / repository, which is then picked up by security tooling (which of course complains that it is ancient and has vulnerabilities). Yes, but as I mentioned before there are "only" pom file not the jar itself... Looking at the dependencies for `maven-dependency-plugin` on https://maven.apache.org/plugins/maven-dependency-plugin/dependencies.html doesn't show log4j in the list -- so I'm a bit confused as to why the package would be fetched to execute the goal. I'm sure I'm missing something obvious, so hopefully someone can clarify what's going on. Thanks, Robert --- [x] referenced data --- [1] pom.xml http://maven.apache.org/POM/4.0.0"; xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 org.fake dependency-fetching-issue jar dependency-fetching-issue 1.${revision} Dependency Fetching Issue maven-dependency-plugin 3.7.1 package copy-dependencies ${project.build.directory}/lib 0-SNAPSHOT UTF-8 [2] mvn --version output Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec Java version: 17.0.11, vendor: Amazon.com Inc., runtime: /Library/Java/JavaVirtualMachines/amazon-corretto-17.jdk/Contents/Home Default locale: en_CA, platform encoding: UTF-8 OS name: "mac os x", version: "14.5", arch: "aarch64", family: "mac" [3] downloading output for dependency:3.7.1:copy-dependenc
Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)
Robert Turner wrote: > The "problem" is not that the old log4j gets copied to the output folder, > it's that it is fetched into the local Maven cache / repository, which is > then picked up by security tooling (which of course complains that it is > ancient and has vulnerabilities). There is no guarantee that the artifacts in the local Maven repository are actually executed or part of the result of your build. I don’t know if it’s an option to change the scanning strategy in your situation, but I would suggest executing builds in a CI environment that doesn’t provide access to the public internet (use a repository manager like Artifactory or Nexus and have it proxy any public repositories you need, like Maven Central), optionally scanning build artifacts before they get deployed, and definitely scanning deployed artifacts periodically, because vulnerabilities can get discovered after deployment time. I wouldn’t then worry about the contents of the local Maven repository after a build so much anymore. Nils. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)
On Tue, Jun 25, 2024 at 9:51 PM Robert Turner wrote: > > On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise > wrote: > >> Hi, >> >> I'm not sure if I understand your problem correct, because based on the >> copy-dependencies goal as stated in the docs: >> >> "Goal that copies the project dependencies from the repository to a >> defined location." >> >> it copies as stated... >> >> The question is what you expect to be copied and furthermore the the >> more important question: Why do you need to copy those parts? >> >> > Sorry if it wasn't very clear -- I have done a bit of digging into it just > now, and hopefully this additional information will help to explain what > I'm seeing (and I think it makes sense now, but still has an > undesirable result). (see below) > > > >> It would also very helpful to have a full pom file of that project or >> maybe a link to a github project (or alike)? >> > > > I think what is happening is that `maven-dependency-plugin` (3.7.1) > depends transitively on log4j 1.2.12 -- I'm still working through trying to > figure that out though. > I think the dependency tree is as follows (running `mvn dependencies:tree` on the `maven-dependency-plugin` code results in the following): org.apache.maven.plugins:maven-dependency-plugin:maven-plugin:3.7.1 org.apache.maven.reporting:maven-reporting-impl:jar:3.2.0 org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1 org.apache.velocity:velocity-tools:jar:2.0 commons-logging:commons-logging:jar:1.1 ... the tree stops here, butcommons-logging:1.1 shows log4j 1.2.12 as a compile dependency ( https://mvnrepository.com/artifact/commons-logging/commons-logging/1.1) But (as of yet) I don't know why it would get pulled in as a runtime dependency > Originally (a few months ago), I worked around it a while back by simply > disabling the copying of the dependencies to the target file (as visible by > the "comments" in the pom.xml [1] file), but that wasn't really ideal. > > > To reproduce, I created a trivial pom.xml [1], and used a clean local > repository for Maven, executing Maven as follows: > > rm -rf maven-cache && MAVEN_OPTS="-Dmaven.repo.local=./maven-cache" > mvn package > > This "builds" the trivial empty JAR file, and copies no dependencies (as > none are declared). > > > However, my local Maven repository (cache) now contains a really old > version of log4j: > > $ ls maven-cache/log4j/log4j/1.2.12/ > _remote.repositories log4j-1.2.12.pom log4j-1.2.12.pom.sha1 > > Reviewing the downloading order from the central repository, log4j-1.2.12 > seems to come after commons-logging-1.1, and as part of the > `dependency:3.7.1:copy-dependencies` goal. [3] > > > >> >> Another point is: do you use the most recent version of all plugins in >> your build ? >> > > In the sample pom.xml, I am using the latest `maven-dependency-plugin` > (3.7.1) -- in this specific sample, I didn't override all the system > plug-ins with the latest version to keep the sample file smaller. However, > we generally keep our plug-ins up-to-date every few months. > > ..snipped original posting... > > > > The "problem" is not that the old log4j gets copied to the output folder, > it's that it is fetched into the local Maven cache / repository, which is > then picked up by security tooling (which of course complains that it is > ancient and has vulnerabilities). > > Looking at the dependencies for `maven-dependency-plugin` on > https://maven.apache.org/plugins/maven-dependency-plugin/dependencies.html > doesn't show log4j in the list -- so I'm a bit confused as to why the > package would be fetched to execute the goal. > > I'm sure I'm missing something obvious, so hopefully someone can clarify > what's going on. > > Thanks, > > Robert > > > > --- [x] referenced data --- > > [1] pom.xml > > http://maven.apache.org/POM/4.0.0"; xmlns:xsi=" > http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > org.fake > dependency-fetching-issue > jar > dependency-fetching-issue > 1.${revision} > Dependency Fetching Issue > > > > > maven-dependency-plugin > 3.7.1 > > > > package > >
Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)
On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise wrote: > Hi, > > I'm not sure if I understand your problem correct, because based on the > copy-dependencies goal as stated in the docs: > > "Goal that copies the project dependencies from the repository to a > defined location." > > it copies as stated... > > The question is what you expect to be copied and furthermore the the > more important question: Why do you need to copy those parts? > > Sorry if it wasn't very clear -- I have done a bit of digging into it just now, and hopefully this additional information will help to explain what I'm seeing (and I think it makes sense now, but still has an undesirable result). (see below) > It would also very helpful to have a full pom file of that project or > maybe a link to a github project (or alike)? > I think what is happening is that `maven-dependency-plugin` (3.7.1) depends transitively on log4j 1.2.12 -- I'm still working through trying to figure that out though. Originally (a few months ago), I worked around it a while back by simply disabling the copying of the dependencies to the target file (as visible by the "comments" in the pom.xml [1] file), but that wasn't really ideal. To reproduce, I created a trivial pom.xml [1], and used a clean local repository for Maven, executing Maven as follows: rm -rf maven-cache && MAVEN_OPTS="-Dmaven.repo.local=./maven-cache" mvn package This "builds" the trivial empty JAR file, and copies no dependencies (as none are declared). However, my local Maven repository (cache) now contains a really old version of log4j: $ ls maven-cache/log4j/log4j/1.2.12/ _remote.repositories log4j-1.2.12.pom log4j-1.2.12.pom.sha1 Reviewing the downloading order from the central repository, log4j-1.2.12 seems to come after commons-logging-1.1, and as part of the `dependency:3.7.1:copy-dependencies` goal. [3] > > Another point is: do you use the most recent version of all plugins in > your build ? > In the sample pom.xml, I am using the latest `maven-dependency-plugin` (3.7.1) -- in this specific sample, I didn't override all the system plug-ins with the latest version to keep the sample file smaller. However, we generally keep our plug-ins up-to-date every few months. ..snipped original posting... The "problem" is not that the old log4j gets copied to the output folder, it's that it is fetched into the local Maven cache / repository, which is then picked up by security tooling (which of course complains that it is ancient and has vulnerabilities). Looking at the dependencies for `maven-dependency-plugin` on https://maven.apache.org/plugins/maven-dependency-plugin/dependencies.html doesn't show log4j in the list -- so I'm a bit confused as to why the package would be fetched to execute the goal. I'm sure I'm missing something obvious, so hopefully someone can clarify what's going on. Thanks, Robert --- [x] referenced data --- [1] pom.xml http://maven.apache.org/POM/4.0.0"; xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 org.fake dependency-fetching-issue jar dependency-fetching-issue 1.${revision} Dependency Fetching Issue maven-dependency-plugin 3.7.1 package copy-dependencies ${project.build.directory}/lib 0-SNAPSHOT UTF-8 [2] mvn --version output Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec Java version: 17.0.11, vendor: Amazon.com Inc., runtime: /Library/Java/JavaVirtualMachines/amazon-corretto-17.jdk/Contents/Home Default locale: en_CA, platform encoding: UTF-8 OS name: "mac os x", version: "14.5", arch: "aarch64", family: "mac" [3] downloading output for dependency:3.7.1:copy-dependencies goal [INFO] --- dependency:3.7.1:copy-dependencies (default) @ dependency-fetching-issue --- Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.12.0/doxia-sink-api-1.12.0.pom Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.12.0/doxia-sink-api-1.12.0.pom (1.5 kB at 22 kB/s) Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia/1.12.0/doxia-1.12.0.pom Downloaded from central:
Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)
Hi, I'm not sure if I understand your problem correct, because based on the copy-dependencies goal as stated in the docs: "Goal that copies the project dependencies from the repository to a defined location." it copies as stated... The question is what you expect to be copied and furthermore the the more important question: Why do you need to copy those parts? It would also very helpful to have a full pom file of that project or maybe a link to a github project (or alike)? Another point is: do you use the most recent version of all plugins in your build ? Kind regards Karl Heinz Marbaise On 24.06.24 17:31, Robert Turner wrote: (Note I had originally sent this on Feb 14, but I think it never got posted to the mailing list -- likely because I forgot to subscribe first -- as such, some of the version information may not be "current" as of today). All: I'm looking into an issue where we had an old package [1] flagged by security tooling as being present on our build servers in the Maven repository (~/.m2/repository). After a bit of digging, I managed to narrow down where it came from and when it got fetched, and I can reproduce in a pretty narrow use case as well. We have a library (jar) that gets built for the purposes of a REST API. This package was generated with some automated tooling, but has been hand-tweaked. However, the specifics of the package do not seem to be that important (other than the tools it uses). The specific plugin with the transitive dependency to the offending package [1] is "maven-javadoc-plugin" (which likely needs some updates of dependencies, etc, in particular maven-reporting- which seem to be the ones that are older). During our build process, "maven-dependency-plugin" is used with the goal "copy-dependencies" to copy runtime artifacts to the output directory (target/lib) [2]. It does this, and copies in about 15 or so files as expected. [3] None of these files are the "offending" package being flagged by the security tools. However, if you clean your Maven repository (rm -rf ~/.m2/repository), and run either the build up to and including the dependency copying (e.g. mvn package) [3], or just run "mvn dependency:tree" [4], the offending package gets copied into the local Maven repository (~/.m2/repository). So, my questions are: a) Why does maven-dependency-plugin fetch absolutely everything regardless of how far it actually needs to traverse the tree to do the task it's performing? (or does it really need to traverse the whole tree?) b) Is there a way to stop this behaviour without either removing the dependency (maven-javadoc.plugin) with the offending dependency [1] from the project, or not using "maven-dependency-plugin"? I have tried some exclusion methods documented for the goals, but they do not seem to change the fetching / tree traversal behaviour. Thanks, Robert == References / Details == [1] log4j:log4j:1.2.12 [2] maven-dependency-plugin 3.6.1 package copy-dependencies ${project.build.directory}/lib [3] $ rm -rf ~/.m2/repository $ mvn package 09:26:55.703 [INFO] Scanning for projects... 09:26:55.726 [INFO] ...snip... 09:27:14.083 [INFO] 09:27:14.083 [INFO] --- dependency:3.6.1:copy-dependencies (default) @ --- Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.11.1/doxia-sink-api-1.11.1.pom Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.11.1/doxia-sink-api-1.11.1.pom (1.6 kB at 27 kB/s) ...snip... Downloading from central: https://repo.maven.apache.org/maven2/log4j/log4j/1.2.12/log4j-1.2.12.pom Downloaded from central: https://repo.maven.apache.org/maven2/log4j/log4j/1.2.12/log4j-1.2.12.pom (145 B at 2.1 kB/s) ...snip... Downloaded from central: https://repo.maven.apache.org/maven2/com/github/luben/zstd-jni/1.5.5-5/zstd-jni-1.5.5-5.jar (5.9 MB at 3.7 MB/s) 09:27:28.043 [INFO] com.google.code.findbugs:jsr305:jar:3.0.2 already exists in destination. 09:27:28.043 [INFO] org.apache.httpcomponents.client5:httpclient5:jar:5.2.1 already exists in destination. 09:27:28.043 [INFO] org.apache.httpcomponents.core5:httpcore5:jar:5.2 already exists in destination. 09:27:28.043 [INFO] org.apache.httpcomponents.core5:httpcore5-h2:jar:5.2 already exists in destination. 09:27:28.043 [INFO] org.slf4j:slf4j-api:jar:1.7.36 already exists in destination. 09:27:28.043 [INFO] com.fasterxml.jackson.core:jackson-core:jar:2.15.2 already exists in destination. 09:27:28.043 [INFO] com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2 already exists in
maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)
(Note I had originally sent this on Feb 14, but I think it never got posted to the mailing list -- likely because I forgot to subscribe first -- as such, some of the version information may not be "current" as of today). All: I'm looking into an issue where we had an old package [1] flagged by security tooling as being present on our build servers in the Maven repository (~/.m2/repository). After a bit of digging, I managed to narrow down where it came from and when it got fetched, and I can reproduce in a pretty narrow use case as well. We have a library (jar) that gets built for the purposes of a REST API. This package was generated with some automated tooling, but has been hand-tweaked. However, the specifics of the package do not seem to be that important (other than the tools it uses). The specific plugin with the transitive dependency to the offending package [1] is "maven-javadoc-plugin" (which likely needs some updates of dependencies, etc, in particular maven-reporting- which seem to be the ones that are older). During our build process, "maven-dependency-plugin" is used with the goal "copy-dependencies" to copy runtime artifacts to the output directory (target/lib) [2]. It does this, and copies in about 15 or so files as expected. [3] None of these files are the "offending" package being flagged by the security tools. However, if you clean your Maven repository (rm -rf ~/.m2/repository), and run either the build up to and including the dependency copying (e.g. mvn package) [3], or just run "mvn dependency:tree" [4], the offending package gets copied into the local Maven repository (~/.m2/repository). So, my questions are: a) Why does maven-dependency-plugin fetch absolutely everything regardless of how far it actually needs to traverse the tree to do the task it's performing? (or does it really need to traverse the whole tree?) b) Is there a way to stop this behaviour without either removing the dependency (maven-javadoc.plugin) with the offending dependency [1] from the project, or not using "maven-dependency-plugin"? I have tried some exclusion methods documented for the goals, but they do not seem to change the fetching / tree traversal behaviour. Thanks, Robert == References / Details == [1] log4j:log4j:1.2.12 [2] maven-dependency-plugin 3.6.1 package copy-dependencies ${project.build.directory}/lib [3] $ rm -rf ~/.m2/repository $ mvn package 09:26:55.703 [INFO] Scanning for projects... 09:26:55.726 [INFO] ...snip... 09:27:14.083 [INFO] 09:27:14.083 [INFO] --- dependency:3.6.1:copy-dependencies (default) @ --- Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.11.1/doxia-sink-api-1.11.1.pom Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.11.1/doxia-sink-api-1.11.1.pom (1.6 kB at 27 kB/s) ...snip... Downloading from central: https://repo.maven.apache.org/maven2/log4j/log4j/1.2.12/log4j-1.2.12.pom Downloaded from central: https://repo.maven.apache.org/maven2/log4j/log4j/1.2.12/log4j-1.2.12.pom (145 B at 2.1 kB/s) ...snip... Downloaded from central: https://repo.maven.apache.org/maven2/com/github/luben/zstd-jni/1.5.5-5/zstd-jni-1.5.5-5.jar (5.9 MB at 3.7 MB/s) 09:27:28.043 [INFO] com.google.code.findbugs:jsr305:jar:3.0.2 already exists in destination. 09:27:28.043 [INFO] org.apache.httpcomponents.client5:httpclient5:jar:5.2.1 already exists in destination. 09:27:28.043 [INFO] org.apache.httpcomponents.core5:httpcore5:jar:5.2 already exists in destination. 09:27:28.043 [INFO] org.apache.httpcomponents.core5:httpcore5-h2:jar:5.2 already exists in destination. 09:27:28.043 [INFO] org.slf4j:slf4j-api:jar:1.7.36 already exists in destination. 09:27:28.043 [INFO] com.fasterxml.jackson.core:jackson-core:jar:2.15.2 already exists in destination. 09:27:28.043 [INFO] com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2 already exists in destination. 09:27:28.043 [INFO] com.fasterxml.jackson.core:jackson-databind:jar:2.15.2 already exists in destination. 09:27:28.043 [INFO] com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.15.2 already exists in destination. 09:27:28.043 [INFO] com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.15.2 already exists in destination. 09:27:28.043 [INFO] com.fasterxml.jackson.module:jackson-module-jaxb-annotations:jar:2.15.2 already exists in destination. 09:27:28.043 [INFO] jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.3 already exists in destination. 09:27:28.043 [INFO] jakarta.activation:jakarta.activation-api:jar:1.2.2 already exists in destination. 09:27
[ANN] Apache Maven Dependency Plugin 3.7.1 released
The Apache Maven team is pleased to announce the release of the Maven Dependency Plugin version 3.7.1 https://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.7.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-dependency-plugin/download.cgi Release Notes - Maven Dependency Plugin - Version 3.7.1 ** Bug * [MDEP-943] - [REGRESSION] appendOutput for tree goal broken for multi-module project ** Improvement * [MDEP-940] - Use Resolver API instead of m-a-t for resolving artifacts ** Task * [MDEP-945] - Fix documentation about get goal ** Dependency upgrade * [MDEP-944] - Bump org.apache.maven.shared:maven-common-artifact-filters from 3.3.2 to 3.4.0 Enjoy, -The Apache Maven team
[ANN] Release Maven Dependency Plugin 3.7.0 released
The Apache Maven team is pleased to announce the release of the Maven Dependency Plugin version 3.7.0. https://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.7.0 Release Notes - Maven Dependency Plugin - Version 3.7.0 ** Bug * [MDEP-835] - dependency:tree no longer shows optional flag * [MDEP-838] - "Artifact has not been packaged yet" error message is not very helpful * [MDEP-938] - 'mdep.overIfNewer' is misnamed from its usage of 'mdep.overWriteIfNewer' ** New Feature * [MDEP-317] - Add goal dependency:analyze-exclusions - check for invalid excludes * [MDEP-799] - improve mvn dependency:tree - add optional JSON output of the results * [MDEP-928] - Allow to exclude classes from dependency:analyze ** Improvement * [MDEP-669] - Optimize the documentation of of build-classpath-mojo * [MDEP-893] - Get rid of commons-lang3 * [MDEP-894] - Use @Component instead of @Parameter for session/project * [MDEP-896] - Removing unused code * [MDEP-897] - Remove old style JavaDoc Plexus docs * [MDEP-899] - Upgrade maven-plugin parent to 42 * [MDEP-917] - dependency:analyze-exclusions - use Resolver API instead of ProjectBuilder * [MDEP-924] - Get rid of maven-artifact-transfer from list-classes goal * [MDEP-925] - Require Maven 3.6.3 * [MDEP-939] - Lock down classifier in dependency:sources goal ** Test * [MDEP-710] - reenable TestTreeMojo ** Task * [MDEP-912] - Use version for plexus-utils/plexus-xml from parent * [MDEP-914] - collect goal description broken in documentation * [MDEP-918] - Use standard updatePolicy for repositories in ITs * [MDEP-923] - Code cleanups * [MDEP-935] - Improvement ITs for dependency:tree * [MDEP-941] - Deprecate dependency:sources in favor of dependency:resolve-sources ** Dependency upgrade * [MDEP-911] - Bump org.codehaus.plexus:plexus-archiver from 4.8.0 to 4.9.2 * [MDEP-915] - Upgrade commons-io:commons-io from 2.15.1 to 2.16.1 * [MDEP-920] - Bump org.assertj:assertj-core from 3.24.2 to 3.26.0 * [MDEP-921] - Bump org.apache.commons:commons-text from 1.11.0 to 1.12.0 * [MDEP-922] - dependency:analyze-exclusions - should report issue only in current project * [MDEP-929] - Bump org.apache.maven.shared:maven-dependency-analyzer from 1.13.2 to 1.14.1 * [MDEP-936] - Bump org.apache.maven.shared:maven-dependency-tree from 3.2.1 to 3.3.0 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
Howdy, 0.1.3 out, got unpack ability (actually UnpackSink). Here is 0.1.3 in action, doing "side-by-side" and "overlay" way of unpack: https://gist.github.com/cstamas/36c49da724100a19feab1397e7381d0f Oh, and Martin, the sink also unpacks only "unique" artifacts, so it will not over-and-over-and-over unpack the same thing... T On Tue, Mar 26, 2024 at 9:07 PM Tamás Cservenák wrote: > Oh, and as a side effect, the plugin is way more snappier as well, look at > execution time diffs (I know, this is not "benchmark", but is telling): > https://gist.github.com/cstamas/6026436527cbd669ce1a5f183f03fe51 > > toolbox needs almost only 60% of runtime that m-dep-p have. > > T > > On Tue, Mar 26, 2024 at 8:56 PM Tamás Cservenák > wrote: > >> Rudimentary support for those is already present (equals, startWith, >> endsWith) :) >> >> So one can write ArtifactMatcher "spec expression" (that will be parsed >> into ArtifactMatcher that is actually Predicate) as: >> "artifact(gavoid)" >> where "gavoid" can be "string" or "g:a" or "g:a:v" etc >> Each field currently support: >> * - any >> foo - equals foo >> foo* - "starts with foo" >> *foo - "ends with foo" >> >> Here is UT >> >> https://github.com/maveniverse/toolbox/blob/main/shared/src/test/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcherTest.java >> >> So for your case, to filter dependencies by classifier it would be >> >> "artifact(*:*:*x86:*)" => it would parse into ArtifactMatcher instance >> that filters for "classifier ends with x86". >> "artifact(*:*:native*:*)" => it would parse into ArtifactMatcher instance >> that filters for "classifier starts with native". >> etc >> >> key to interpret is here: >> >> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L225-L250 >> and that prototype is later used here >> >> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L77-L84 >> >> T >> >> >> >> >> >> On Tue, Mar 26, 2024 at 8:41 PM Francois Marot >> wrote: >> >>> Thanks Tamas for all your work. I'll sure have a look (but not right now >>> as >>> I'm in a train station on a phone). Just to mention a feature I missed >>> yesterday in m-d-p: ability to filter on classifiers including >>> *wildcards*. >>> Because I have dependencies with this kind of classifiers: natives-win, >>> natives-linux, natives-x86, natives-amd64 and so on... >>> >>> Wildcard are sometimes a feature I miss in many plugins. >>> Thanks again for the work, wildcards or not ! >>> >>> Francois >>> >>> Le mar. 26 mars 2024, 17:58, Tamás Cservenák a >>> écrit : >>> >>> > Just for those brave... if you toy with it. >>> > >>> > The "copy" and "copy-transitive" CLI commands and Mojos have >>> "targetSpec" >>> > parameters, that are parsed into ArtifactSink here: >>> > >>> > >>> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288 >>> > >>> > So, the copy (and copy-transitive) resolve (transitively) and push the >>> > results into an ArtifactSink. >>> > >>> > Sink spec can be: >>> > "foo" -> implied "flat:foo" >>> > "flat:" -> a "flat directory" to copy artifacts to, like >>> "flat:lib" >>> > (is resolved from basedir) >>> > "repository:" -> creates a repo that can be used as "file://" >>> uri or >>> > published via HTTP (is resolved from basedir) >>> > "install:" -> will install them into local repository (session >>> > default in no path specified), ie. good to prep a local repo -- TBD >>> >>> > param >>> > "deploy:id::url" -> will deploy them to Remote Repo >>> > "purge:" -> will purge them from local repository (session >>> default in >>> > no path specified) -- TBD param >>> > >>> > So, following command: >>> > >>> > copy -DdepSpec="any()" -DtargetSpec="purge:" >>> > >>> > actually does the purge from the local repository. Same stands for >>> gav-copy >>> > (and gav-copy-transitively), but they do not use MavenProject to >>> > "contextualize" but need to be told explicitly what to resolve... >>> > >>> > >>> > On Tue, Mar 26, 2024 at 5:34 PM Tamás Cservenák >>> > wrote: >>> > >>> > > Howdy, >>> > > >>> > > Yes, m-dep-p is under maintained, it actually would need a rewrite >>> as it >>> > > still uses MAT (and many other Maven2 archaic stuff) internally. >>> > > Hence, it will fail if used with 3.9+ features like "split >>> repository" >>> > and >>> > > is suboptimal in many areas. >>> > > >>> > > Toolbox 0.1.0 released, btw: >>> > > >>> > > jbang toolbox@maveniverse >>> > > >>> > > or >>> > > >>> > > mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl >>> > > >>> > > to enter REPL (same as in MIMA CLI was). >>> > > >>> > > T >>> > > >>> > > On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala >> > >>> > > wrote: >>> > > >>> > >> Hello Tamás, >>> > >> >>> > >> For context, what are the tensions that you're trying to so
Re: [DISCUSS] Maven Dependency Plugin
Oh, and as a side effect, the plugin is way more snappier as well, look at execution time diffs (I know, this is not "benchmark", but is telling): https://gist.github.com/cstamas/6026436527cbd669ce1a5f183f03fe51 toolbox needs almost only 60% of runtime that m-dep-p have. T On Tue, Mar 26, 2024 at 8:56 PM Tamás Cservenák wrote: > Rudimentary support for those is already present (equals, startWith, > endsWith) :) > > So one can write ArtifactMatcher "spec expression" (that will be parsed > into ArtifactMatcher that is actually Predicate) as: > "artifact(gavoid)" > where "gavoid" can be "string" or "g:a" or "g:a:v" etc > Each field currently support: > * - any > foo - equals foo > foo* - "starts with foo" > *foo - "ends with foo" > > Here is UT > > https://github.com/maveniverse/toolbox/blob/main/shared/src/test/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcherTest.java > > So for your case, to filter dependencies by classifier it would be > > "artifact(*:*:*x86:*)" => it would parse into ArtifactMatcher instance > that filters for "classifier ends with x86". > "artifact(*:*:native*:*)" => it would parse into ArtifactMatcher instance > that filters for "classifier starts with native". > etc > > key to interpret is here: > > https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L225-L250 > and that prototype is later used here > > https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L77-L84 > > T > > > > > > On Tue, Mar 26, 2024 at 8:41 PM Francois Marot > wrote: > >> Thanks Tamas for all your work. I'll sure have a look (but not right now >> as >> I'm in a train station on a phone). Just to mention a feature I missed >> yesterday in m-d-p: ability to filter on classifiers including >> *wildcards*. >> Because I have dependencies with this kind of classifiers: natives-win, >> natives-linux, natives-x86, natives-amd64 and so on... >> >> Wildcard are sometimes a feature I miss in many plugins. >> Thanks again for the work, wildcards or not ! >> >> Francois >> >> Le mar. 26 mars 2024, 17:58, Tamás Cservenák a >> écrit : >> >> > Just for those brave... if you toy with it. >> > >> > The "copy" and "copy-transitive" CLI commands and Mojos have >> "targetSpec" >> > parameters, that are parsed into ArtifactSink here: >> > >> > >> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288 >> > >> > So, the copy (and copy-transitive) resolve (transitively) and push the >> > results into an ArtifactSink. >> > >> > Sink spec can be: >> > "foo" -> implied "flat:foo" >> > "flat:" -> a "flat directory" to copy artifacts to, like >> "flat:lib" >> > (is resolved from basedir) >> > "repository:" -> creates a repo that can be used as "file://" uri >> or >> > published via HTTP (is resolved from basedir) >> > "install:" -> will install them into local repository (session >> > default in no path specified), ie. good to prep a local repo -- TBD >> >> > param >> > "deploy:id::url" -> will deploy them to Remote Repo >> > "purge:" -> will purge them from local repository (session >> default in >> > no path specified) -- TBD param >> > >> > So, following command: >> > >> > copy -DdepSpec="any()" -DtargetSpec="purge:" >> > >> > actually does the purge from the local repository. Same stands for >> gav-copy >> > (and gav-copy-transitively), but they do not use MavenProject to >> > "contextualize" but need to be told explicitly what to resolve... >> > >> > >> > On Tue, Mar 26, 2024 at 5:34 PM Tamás Cservenák >> > wrote: >> > >> > > Howdy, >> > > >> > > Yes, m-dep-p is under maintained, it actually would need a rewrite as >> it >> > > still uses MAT (and many other Maven2 archaic stuff) internally. >> > > Hence, it will fail if used with 3.9+ features like "split repository" >> > and >> > > is suboptimal in many areas. >> > > >> > > Toolbox 0.1.0 released, btw: >> > > >> > > jbang toolbox@maveniverse >> > > >> > > or >> > > >> > > mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl >> > > >> > > to enter REPL (same as in MIMA CLI was). >> > > >> > > T >> > > >> > > On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala >> > > wrote: >> > > >> > >> Hello Tamás, >> > >> >> > >> For context, what are the tensions that you're trying to solve here? >> > >> >> > >> Is m-dependency-p too big/getting unmaintainable/becoming a kitchen >> > sink? >> > >> >> > >> Do some goals feel like a bad fit? >> > >> >> > >> Are you thinking of breaking it up or replacing it? >> > >> >> > >> Greg >> > >> >> > >> On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák > > >> > >> wrote: >> > >> >> > >> > Howdy, >> > >> > >> > >> > just to not let this discussion die off. Let me show a take on a >> "how >> > >> > modern Maven plugin should look like" (that targets m-dependency-p >> > >> goals, >>
Re: [DISCUSS] Maven Dependency Plugin
Rudimentary support for those is already present (equals, startWith, endsWith) :) So one can write ArtifactMatcher "spec expression" (that will be parsed into ArtifactMatcher that is actually Predicate) as: "artifact(gavoid)" where "gavoid" can be "string" or "g:a" or "g:a:v" etc Each field currently support: * - any foo - equals foo foo* - "starts with foo" *foo - "ends with foo" Here is UT https://github.com/maveniverse/toolbox/blob/main/shared/src/test/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcherTest.java So for your case, to filter dependencies by classifier it would be "artifact(*:*:*x86:*)" => it would parse into ArtifactMatcher instance that filters for "classifier ends with x86". "artifact(*:*:native*:*)" => it would parse into ArtifactMatcher instance that filters for "classifier starts with native". etc key to interpret is here: https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L225-L250 and that prototype is later used here https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L77-L84 T On Tue, Mar 26, 2024 at 8:41 PM Francois Marot wrote: > Thanks Tamas for all your work. I'll sure have a look (but not right now as > I'm in a train station on a phone). Just to mention a feature I missed > yesterday in m-d-p: ability to filter on classifiers including *wildcards*. > Because I have dependencies with this kind of classifiers: natives-win, > natives-linux, natives-x86, natives-amd64 and so on... > > Wildcard are sometimes a feature I miss in many plugins. > Thanks again for the work, wildcards or not ! > > Francois > > Le mar. 26 mars 2024, 17:58, Tamás Cservenák a > écrit : > > > Just for those brave... if you toy with it. > > > > The "copy" and "copy-transitive" CLI commands and Mojos have "targetSpec" > > parameters, that are parsed into ArtifactSink here: > > > > > https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288 > > > > So, the copy (and copy-transitive) resolve (transitively) and push the > > results into an ArtifactSink. > > > > Sink spec can be: > > "foo" -> implied "flat:foo" > > "flat:" -> a "flat directory" to copy artifacts to, like "flat:lib" > > (is resolved from basedir) > > "repository:" -> creates a repo that can be used as "file://" uri > or > > published via HTTP (is resolved from basedir) > > "install:" -> will install them into local repository (session > > default in no path specified), ie. good to prep a local repo -- TBD > > > param > > "deploy:id::url" -> will deploy them to Remote Repo > > "purge:" -> will purge them from local repository (session default > in > > no path specified) -- TBD param > > > > So, following command: > > > > copy -DdepSpec="any()" -DtargetSpec="purge:" > > > > actually does the purge from the local repository. Same stands for > gav-copy > > (and gav-copy-transitively), but they do not use MavenProject to > > "contextualize" but need to be told explicitly what to resolve... > > > > > > On Tue, Mar 26, 2024 at 5:34 PM Tamás Cservenák > > wrote: > > > > > Howdy, > > > > > > Yes, m-dep-p is under maintained, it actually would need a rewrite as > it > > > still uses MAT (and many other Maven2 archaic stuff) internally. > > > Hence, it will fail if used with 3.9+ features like "split repository" > > and > > > is suboptimal in many areas. > > > > > > Toolbox 0.1.0 released, btw: > > > > > > jbang toolbox@maveniverse > > > > > > or > > > > > > mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl > > > > > > to enter REPL (same as in MIMA CLI was). > > > > > > T > > > > > > On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala > > > wrote: > > > > > >> Hello Tamás, > > >> > > >> For context, what are the tensions that you're trying to solve here? > > >> > > >> Is m-dependency-p too big/getting unmaintainable/becoming a kitchen > > sink? > > >> > > >> Do some goals feel like a bad fit? > > >> > > >> Are you thinking of breaking it up or replacing it? > > >> > > >> Greg > > >> > > >> On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák > > >> wrote: > > >> > > >> > Howdy, > > >> > > > >> > just to not let this discussion die off. Let me show a take on a > "how > > >> > modern Maven plugin should look like" (that targets m-dependency-p > > >> goals, > > >> > sans analyze and some others) could look like: > > >> > https://github.com/maveniverse/toolbox > > >> > > > >> > The "unpack" related goals are missing, not yet done, but there are > > >> already > > >> > 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally > > same > > >> as > > >> > CLI commands, and they do NOT require Project, are meant to be "ad > > hoc" > > >> > invoked. > > >> > The non-"gav-"-prefixed mojos use MavenProject instead to > > >> "contextualize" > > >> > themselves (so they
Re: [DISCUSS] Maven Dependency Plugin
Thanks Tamas for all your work. I'll sure have a look (but not right now as I'm in a train station on a phone). Just to mention a feature I missed yesterday in m-d-p: ability to filter on classifiers including *wildcards*. Because I have dependencies with this kind of classifiers: natives-win, natives-linux, natives-x86, natives-amd64 and so on... Wildcard are sometimes a feature I miss in many plugins. Thanks again for the work, wildcards or not ! Francois Le mar. 26 mars 2024, 17:58, Tamás Cservenák a écrit : > Just for those brave... if you toy with it. > > The "copy" and "copy-transitive" CLI commands and Mojos have "targetSpec" > parameters, that are parsed into ArtifactSink here: > > https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288 > > So, the copy (and copy-transitive) resolve (transitively) and push the > results into an ArtifactSink. > > Sink spec can be: > "foo" -> implied "flat:foo" > "flat:" -> a "flat directory" to copy artifacts to, like "flat:lib" > (is resolved from basedir) > "repository:" -> creates a repo that can be used as "file://" uri or > published via HTTP (is resolved from basedir) > "install:" -> will install them into local repository (session > default in no path specified), ie. good to prep a local repo -- TBD > param > "deploy:id::url" -> will deploy them to Remote Repo > "purge:" -> will purge them from local repository (session default in > no path specified) -- TBD param > > So, following command: > > copy -DdepSpec="any()" -DtargetSpec="purge:" > > actually does the purge from the local repository. Same stands for gav-copy > (and gav-copy-transitively), but they do not use MavenProject to > "contextualize" but need to be told explicitly what to resolve... > > > On Tue, Mar 26, 2024 at 5:34 PM Tamás Cservenák > wrote: > > > Howdy, > > > > Yes, m-dep-p is under maintained, it actually would need a rewrite as it > > still uses MAT (and many other Maven2 archaic stuff) internally. > > Hence, it will fail if used with 3.9+ features like "split repository" > and > > is suboptimal in many areas. > > > > Toolbox 0.1.0 released, btw: > > > > jbang toolbox@maveniverse > > > > or > > > > mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl > > > > to enter REPL (same as in MIMA CLI was). > > > > T > > > > On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala > > wrote: > > > >> Hello Tamás, > >> > >> For context, what are the tensions that you're trying to solve here? > >> > >> Is m-dependency-p too big/getting unmaintainable/becoming a kitchen > sink? > >> > >> Do some goals feel like a bad fit? > >> > >> Are you thinking of breaking it up or replacing it? > >> > >> Greg > >> > >> On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák > >> wrote: > >> > >> > Howdy, > >> > > >> > just to not let this discussion die off. Let me show a take on a "how > >> > modern Maven plugin should look like" (that targets m-dependency-p > >> goals, > >> > sans analyze and some others) could look like: > >> > https://github.com/maveniverse/toolbox > >> > > >> > The "unpack" related goals are missing, not yet done, but there are > >> already > >> > 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally > same > >> as > >> > CLI commands, and they do NOT require Project, are meant to be "ad > hoc" > >> > invoked. > >> > The non-"gav-"-prefixed mojos use MavenProject instead to > >> "contextualize" > >> > themselves (so they work with the Project, and the "plugin-" prefixed > >> ones > >> > with Project defined plugins). > >> > > >> > Note1: not yet released (is not on Central), if you want to test drive > >> it, > >> > build it locally). > >> > Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the > CLI > >> > uber is toolbox-1.0.0-SNAPSHOT-cli.jar) > >> > Note3: some of the missing goals mentioned on this thread are > >> implemented > >> > > >> > Thanks > >> > T > >> > > >> > > >
Re: [DISCUSS] Maven Dependency Plugin
Just for those brave... if you toy with it. The "copy" and "copy-transitive" CLI commands and Mojos have "targetSpec" parameters, that are parsed into ArtifactSink here: https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288 So, the copy (and copy-transitive) resolve (transitively) and push the results into an ArtifactSink. Sink spec can be: "foo" -> implied "flat:foo" "flat:" -> a "flat directory" to copy artifacts to, like "flat:lib" (is resolved from basedir) "repository:" -> creates a repo that can be used as "file://" uri or published via HTTP (is resolved from basedir) "install:" -> will install them into local repository (session default in no path specified), ie. good to prep a local repo -- TBD param "deploy:id::url" -> will deploy them to Remote Repo "purge:" -> will purge them from local repository (session default in no path specified) -- TBD param So, following command: copy -DdepSpec="any()" -DtargetSpec="purge:" actually does the purge from the local repository. Same stands for gav-copy (and gav-copy-transitively), but they do not use MavenProject to "contextualize" but need to be told explicitly what to resolve... On Tue, Mar 26, 2024 at 5:34 PM Tamás Cservenák wrote: > Howdy, > > Yes, m-dep-p is under maintained, it actually would need a rewrite as it > still uses MAT (and many other Maven2 archaic stuff) internally. > Hence, it will fail if used with 3.9+ features like "split repository" and > is suboptimal in many areas. > > Toolbox 0.1.0 released, btw: > > jbang toolbox@maveniverse > > or > > mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl > > to enter REPL (same as in MIMA CLI was). > > T > > On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala > wrote: > >> Hello Tamás, >> >> For context, what are the tensions that you're trying to solve here? >> >> Is m-dependency-p too big/getting unmaintainable/becoming a kitchen sink? >> >> Do some goals feel like a bad fit? >> >> Are you thinking of breaking it up or replacing it? >> >> Greg >> >> On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák >> wrote: >> >> > Howdy, >> > >> > just to not let this discussion die off. Let me show a take on a "how >> > modern Maven plugin should look like" (that targets m-dependency-p >> goals, >> > sans analyze and some others) could look like: >> > https://github.com/maveniverse/toolbox >> > >> > The "unpack" related goals are missing, not yet done, but there are >> already >> > 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally same >> as >> > CLI commands, and they do NOT require Project, are meant to be "ad hoc" >> > invoked. >> > The non-"gav-"-prefixed mojos use MavenProject instead to >> "contextualize" >> > themselves (so they work with the Project, and the "plugin-" prefixed >> ones >> > with Project defined plugins). >> > >> > Note1: not yet released (is not on Central), if you want to test drive >> it, >> > build it locally). >> > Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the CLI >> > uber is toolbox-1.0.0-SNAPSHOT-cli.jar) >> > Note3: some of the missing goals mentioned on this thread are >> implemented >> > >> > Thanks >> > T >> > >> >
Re: [DISCUSS] Maven Dependency Plugin
Howdy, Yes, m-dep-p is under maintained, it actually would need a rewrite as it still uses MAT (and many other Maven2 archaic stuff) internally. Hence, it will fail if used with 3.9+ features like "split repository" and is suboptimal in many areas. Toolbox 0.1.0 released, btw: jbang toolbox@maveniverse or mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl to enter REPL (same as in MIMA CLI was). T On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala wrote: > Hello Tamás, > > For context, what are the tensions that you're trying to solve here? > > Is m-dependency-p too big/getting unmaintainable/becoming a kitchen sink? > > Do some goals feel like a bad fit? > > Are you thinking of breaking it up or replacing it? > > Greg > > On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák > wrote: > > > Howdy, > > > > just to not let this discussion die off. Let me show a take on a "how > > modern Maven plugin should look like" (that targets m-dependency-p goals, > > sans analyze and some others) could look like: > > https://github.com/maveniverse/toolbox > > > > The "unpack" related goals are missing, not yet done, but there are > already > > 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally same > as > > CLI commands, and they do NOT require Project, are meant to be "ad hoc" > > invoked. > > The non-"gav-"-prefixed mojos use MavenProject instead to "contextualize" > > themselves (so they work with the Project, and the "plugin-" prefixed > ones > > with Project defined plugins). > > > > Note1: not yet released (is not on Central), if you want to test drive > it, > > build it locally). > > Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the CLI > > uber is toolbox-1.0.0-SNAPSHOT-cli.jar) > > Note3: some of the missing goals mentioned on this thread are implemented > > > > Thanks > > T > > >
Re: [DISCUSS] Maven Dependency Plugin
Hello Tamás, For context, what are the tensions that you're trying to solve here? Is m-dependency-p too big/getting unmaintainable/becoming a kitchen sink? Do some goals feel like a bad fit? Are you thinking of breaking it up or replacing it? Greg On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák wrote: > Howdy, > > just to not let this discussion die off. Let me show a take on a "how > modern Maven plugin should look like" (that targets m-dependency-p goals, > sans analyze and some others) could look like: > https://github.com/maveniverse/toolbox > > The "unpack" related goals are missing, not yet done, but there are already > 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally same as > CLI commands, and they do NOT require Project, are meant to be "ad hoc" > invoked. > The non-"gav-"-prefixed mojos use MavenProject instead to "contextualize" > themselves (so they work with the Project, and the "plugin-" prefixed ones > with Project defined plugins). > > Note1: not yet released (is not on Central), if you want to test drive it, > build it locally). > Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the CLI > uber is toolbox-1.0.0-SNAPSHOT-cli.jar) > Note3: some of the missing goals mentioned on this thread are implemented > > Thanks > T >
Re: [DISCUSS] Maven Dependency Plugin
Howdy, just to not let this discussion die off. Let me show a take on a "how modern Maven plugin should look like" (that targets m-dependency-p goals, sans analyze and some others) could look like: https://github.com/maveniverse/toolbox The "unpack" related goals are missing, not yet done, but there are already 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally same as CLI commands, and they do NOT require Project, are meant to be "ad hoc" invoked. The non-"gav-"-prefixed mojos use MavenProject instead to "contextualize" themselves (so they work with the Project, and the "plugin-" prefixed ones with Project defined plugins). Note1: not yet released (is not on Central), if you want to test drive it, build it locally). Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the CLI uber is toolbox-1.0.0-SNAPSHOT-cli.jar) Note3: some of the missing goals mentioned on this thread are implemented Thanks T On Sat, Mar 23, 2024 at 9:43 AM Oliver B. Fischer wrote: > Yes, all of them. > > purge-local-repository I use very often in Jenkins pipelines to clean up > afterwards. > > Over the years I build a lot of pipelines, added checks to projects and so > on. The dependency plugin was very often my rescue. I can't remember each > single usage and project and its context, but there is a reason why these > goals/functions have been added. > > Oliver > > > > > Am 21.03.24 um 19:43 schrieb Tamás Cservenák: > > Howdy, > > > > Oliver: all, really? > > I wonder what you used for goals like "purge-local-repository", > > "resolve-plugins" etc :) > > > > I mean, I know what those goals do, I am just unsure WHY you needed > those. > > > > T > > > > On Thu, Mar 21, 2024 at 6:41 PM Oliver B. Fischer< > o.b.fisc...@swe-blog.net> > > wrote: > > > >> Hi, > >> > >> over the time I used all of them in different projects and I think all > >> of them are needed. > >> > >> Viele Grüße > >> > >> Oliver > >> > >> > >> Am 21.03.24 um 17:04 schrieb Tamás Cservenák: > >>> Howdy, > >>> > >>> I'd would be interested in how users and devs are using > >>> maven-dependency-plugin: > >>> https://maven.apache.org/plugins/maven-dependency-plugin/ > >>> > >>> I collected some basic questions I'd like to have answered (but feel > free > >>> to add more info!): > >>> - which goals are "must have" for you > >>> - which goals are "I never touched" for you (or, "I really don't need" > or > >>> "never used" or "shrug") > >>> - what is missing? > >>> > >>> Thanks > >>> T > >>> > >> -- > >> N Oliver B. Fischer > >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > >> P +49 30 44793251 > >> M +49 178 7903538 > >> eo.b.fisc...@swe-blog.net > >> > >> > >> - > >> To unsubscribe, e-mail:users-unsubscr...@maven.apache.org > >> For additional commands, e-mail:users-h...@maven.apache.org > >> > >> > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > eo.b.fisc...@swe-blog.net >
Re: [DISCUSS] Maven Dependency Plugin
Yes, all of them. purge-local-repository I use very often in Jenkins pipelines to clean up afterwards. Over the years I build a lot of pipelines, added checks to projects and so on. The dependency plugin was very often my rescue. I can't remember each single usage and project and its context, but there is a reason why these goals/functions have been added. Oliver Am 21.03.24 um 19:43 schrieb Tamás Cservenák: Howdy, Oliver: all, really? I wonder what you used for goals like "purge-local-repository", "resolve-plugins" etc :) I mean, I know what those goals do, I am just unsure WHY you needed those. T On Thu, Mar 21, 2024 at 6:41 PM Oliver B. Fischer wrote: Hi, over the time I used all of them in different projects and I think all of them are needed. Viele Grüße Oliver Am 21.03.24 um 17:04 schrieb Tamás Cservenák: Howdy, I'd would be interested in how users and devs are using maven-dependency-plugin: https://maven.apache.org/plugins/maven-dependency-plugin/ I collected some basic questions I'd like to have answered (but feel free to add more info!): - which goals are "must have" for you - which goals are "I never touched" for you (or, "I really don't need" or "never used" or "shrug") - what is missing? Thanks T -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 eo.b.fisc...@swe-blog.net - To unsubscribe, e-mail:users-unsubscr...@maven.apache.org For additional commands, e-mail:users-h...@maven.apache.org -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 eo.b.fisc...@swe-blog.net
Re: [DISCUSS] Maven Dependency Plugin
I most frequently use tree and analyze, but have used others like the copy* and unpack* goals, too. I do miss an equivalent to tree for plugin dependencies. -- Alexander Kriegisch https://scrum-master.de Tamás Cservenák schrieb am 21.03.2024 17:04 (GMT +01:00): > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
Many downstream package maintainers use :go-offline to build packages offline in a container w/o outbound network access. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
czw., 21 mar 2024 o 20:54 Tamás Cservenák napisał(a): > Howdy, > > What is the use case of "go offline"? > For me - I use go-offline to prefetch local repo. I have a simple project which have a common dependencies like spring-boot and some home made other commons dependencies in company, On this project I execute go-offline from time to time on git-lab Next other projects use prefeched repo as maven.repo.local.tail, each project uses its own cached local repo, repositories not used by some time are removed. All cached repositories are mounted by nfs on git-lub runners - so I minimize using the same repo by many build to avoid locks problems I know that go offline has many bugs ... but it is accepted in my scenario > That is yet another goal coming from "Maven2 era" and messes up your local > repository (wrt back tracing dependencies, > https://issues.apache.org/jira/browse/MNG-7619) > I mean, if you do a build (w/o tests, or skipping most time stealing > steps), like "dry build", why is that not an option? > > T > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz wrote: > > > +1 to this list from Slawomir: > > > > - dependency:analyze / dependency:analyze-only > > - dependency:copy > > - dependency:copy-dependencies > > - dependency:go-offline > > - dependency:list > > - dependency:tree > > - dependency:unpack > > - dependency:unpack-dependencies > > > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > > s.jaranow...@gmail.com> > > wrote: > > > > > Hi > > > I use: > > > > > > - dependency:analyze / dependency:analyze-only > > > - dependency:copy > > > - dependency:copy-dependencies > > > - dependency:go-offline > > > - dependency:list > > > - dependency:tree > > > - dependency:unpack > > > - dependency:unpack-dependencies > > > > > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > > napisał(a): > > > > > > > Howdy, > > > > > > > > I'd would be interested in how users and devs are using > > > > maven-dependency-plugin: > > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > > > I collected some basic questions I'd like to have answered (but feel > > free > > > > to add more info!): > > > > - which goals are "must have" for you > > > > - which goals are "I never touched" for you (or, "I really don't > need" > > or > > > > "never used" or "shrug") > > > > - what is missing? > > > > > > > > Thanks > > > > T > > > > > > > > > > > > > -- > > > Sławomir Jaranowski > > > > > > -- Sławomir Jaranowski
Re: [DISCUSS] Maven Dependency Plugin
Hey ! First of all, for everyone asking more info to understand where the pom values come from and how they are computed, I think a very useful command is: ** mvn org.apache.maven.plugins:maven-help-plugin:3.4.0:effective-pom -Dverbose=true ** It will display your effective pom but also will tell you in comments for each value where (which pom) it comes from. Regarding the dependency plugin, what I use very frequently: * copy-dependencies (including all the options) * tree What may be usefull to me * analyze-* * build-classpath * dependency:unpack-dependencies (see below) For the record, I forked/rewrote a plugin kinda similar to the unpack-dependencies specifically aimed at unzipping zip or tar.gz containing dlls being identified by the classifier "natives-win" or "natives-linux": https://github.com/fmarot/nativedependencies-maven The main selling point to this plugin is its speed in a multi-module project (I have 150 modules needing native dependencies being unzipped in their PATH for the tests) because it keeps record of the unpacked dependencies and will skip unpacking the same dependency again and again when you want all the dlls being unpacked at ${session.executionRootDirectory}\target\natives for example. Regards, François Le jeu. 21 mars 2024 à 17:06, Tamás Cservenák a écrit : > Howdy, > > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? > > Thanks > T >
Re: [DISCUSS] Maven Dependency Plugin
Greg, For example, we recently converted the TrinoDB ( https://github.com/trinodb/trino) build, removed their use of "go offline" So am just interested in any other patterns out there. T On Thu, Mar 21, 2024 at 9:40 PM Greg Chabala wrote: > I do have an example at hand, though I am not sure I would advocate for it: > https://blog.frankel.ch/faster-maven-builds/2/ > > There are undoubtedly better ways to achieve the author's goals, but I'm > not sure that's the fault of dependency:go-offline. > > On Thu, Mar 21, 2024 at 3:19 PM Tamás Cservenák > wrote: > > > Greg, > > > > would like to see such a project, do you have any examples at hand? > > Am sure there are much simpler/better/more correct ways to do the same > > thing. > > > > T > > > > On Thu, Mar 21, 2024 at 9:15 PM Greg Chabala > > wrote: > > > > > My understanding is dependency:go-offline is an effective way to > > > pre-download plugins and dependencies, for instance if one is making > some > > > layer in a docker build container for later reuse. > > > > > > On Thu, Mar 21, 2024 at 2:54 PM Tamás Cservenák > > > wrote: > > > > > > > Howdy, > > > > > > > > What is the use case of "go offline"? > > > > That is yet another goal coming from "Maven2 era" and messes up your > > > local > > > > repository (wrt back tracing dependencies, > > > > https://issues.apache.org/jira/browse/MNG-7619) > > > > I mean, if you do a build (w/o tests, or skipping most time stealing > > > > steps), like "dry build", why is that not an option? > > > > > > > > T > > > > > > > > > > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz > > wrote: > > > > > > > > > +1 to this list from Slawomir: > > > > > > > > > > - dependency:analyze / dependency:analyze-only > > > > > - dependency:copy > > > > > - dependency:copy-dependencies > > > > > - dependency:go-offline > > > > > - dependency:list > > > > > - dependency:tree > > > > > - dependency:unpack > > > > > - dependency:unpack-dependencies > > > > > > > > > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > > > > > s.jaranow...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hi > > > > > > I use: > > > > > > > > > > > > - dependency:analyze / dependency:analyze-only > > > > > > - dependency:copy > > > > > > - dependency:copy-dependencies > > > > > > - dependency:go-offline > > > > > > - dependency:list > > > > > > - dependency:tree > > > > > > - dependency:unpack > > > > > > - dependency:unpack-dependencies > > > > > > > > > > > > > > > > > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > > > > > napisał(a): > > > > > > > > > > > > > Howdy, > > > > > > > > > > > > > > I'd would be interested in how users and devs are using > > > > > > > maven-dependency-plugin: > > > > > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > > > > > > > > > I collected some basic questions I'd like to have answered (but > > > feel > > > > > free > > > > > > > to add more info!): > > > > > > > - which goals are "must have" for you > > > > > > > - which goals are "I never touched" for you (or, "I really > don't > > > > need" > > > > > or > > > > > > > "never used" or "shrug") > > > > > > > - what is missing? > > > > > > > > > > > > > > Thanks > > > > > > > T > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Sławomir Jaranowski > > > > > > > > > > > > > > > > > > > > >
Re: [DISCUSS] Maven Dependency Plugin
I do have an example at hand, though I am not sure I would advocate for it: https://blog.frankel.ch/faster-maven-builds/2/ There are undoubtedly better ways to achieve the author's goals, but I'm not sure that's the fault of dependency:go-offline. On Thu, Mar 21, 2024 at 3:19 PM Tamás Cservenák wrote: > Greg, > > would like to see such a project, do you have any examples at hand? > Am sure there are much simpler/better/more correct ways to do the same > thing. > > T > > On Thu, Mar 21, 2024 at 9:15 PM Greg Chabala > wrote: > > > My understanding is dependency:go-offline is an effective way to > > pre-download plugins and dependencies, for instance if one is making some > > layer in a docker build container for later reuse. > > > > On Thu, Mar 21, 2024 at 2:54 PM Tamás Cservenák > > wrote: > > > > > Howdy, > > > > > > What is the use case of "go offline"? > > > That is yet another goal coming from "Maven2 era" and messes up your > > local > > > repository (wrt back tracing dependencies, > > > https://issues.apache.org/jira/browse/MNG-7619) > > > I mean, if you do a build (w/o tests, or skipping most time stealing > > > steps), like "dry build", why is that not an option? > > > > > > T > > > > > > > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz > wrote: > > > > > > > +1 to this list from Slawomir: > > > > > > > > - dependency:analyze / dependency:analyze-only > > > > - dependency:copy > > > > - dependency:copy-dependencies > > > > - dependency:go-offline > > > > - dependency:list > > > > - dependency:tree > > > > - dependency:unpack > > > > - dependency:unpack-dependencies > > > > > > > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > > > > s.jaranow...@gmail.com> > > > > wrote: > > > > > > > > > Hi > > > > > I use: > > > > > > > > > > - dependency:analyze / dependency:analyze-only > > > > > - dependency:copy > > > > > - dependency:copy-dependencies > > > > > - dependency:go-offline > > > > > - dependency:list > > > > > - dependency:tree > > > > > - dependency:unpack > > > > > - dependency:unpack-dependencies > > > > > > > > > > > > > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > > > > napisał(a): > > > > > > > > > > > Howdy, > > > > > > > > > > > > I'd would be interested in how users and devs are using > > > > > > maven-dependency-plugin: > > > > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > > > > > > > I collected some basic questions I'd like to have answered (but > > feel > > > > free > > > > > > to add more info!): > > > > > > - which goals are "must have" for you > > > > > > - which goals are "I never touched" for you (or, "I really don't > > > need" > > > > or > > > > > > "never used" or "shrug") > > > > > > - what is missing? > > > > > > > > > > > > Thanks > > > > > > T > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sławomir Jaranowski > > > > > > > > > > > > > > >
Re: [DISCUSS] Maven Dependency Plugin
Greg, would like to see such a project, do you have any examples at hand? Am sure there are much simpler/better/more correct ways to do the same thing. T On Thu, Mar 21, 2024 at 9:15 PM Greg Chabala wrote: > My understanding is dependency:go-offline is an effective way to > pre-download plugins and dependencies, for instance if one is making some > layer in a docker build container for later reuse. > > On Thu, Mar 21, 2024 at 2:54 PM Tamás Cservenák > wrote: > > > Howdy, > > > > What is the use case of "go offline"? > > That is yet another goal coming from "Maven2 era" and messes up your > local > > repository (wrt back tracing dependencies, > > https://issues.apache.org/jira/browse/MNG-7619) > > I mean, if you do a build (w/o tests, or skipping most time stealing > > steps), like "dry build", why is that not an option? > > > > T > > > > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz wrote: > > > > > +1 to this list from Slawomir: > > > > > > - dependency:analyze / dependency:analyze-only > > > - dependency:copy > > > - dependency:copy-dependencies > > > - dependency:go-offline > > > - dependency:list > > > - dependency:tree > > > - dependency:unpack > > > - dependency:unpack-dependencies > > > > > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > > > s.jaranow...@gmail.com> > > > wrote: > > > > > > > Hi > > > > I use: > > > > > > > > - dependency:analyze / dependency:analyze-only > > > > - dependency:copy > > > > - dependency:copy-dependencies > > > > - dependency:go-offline > > > > - dependency:list > > > > - dependency:tree > > > > - dependency:unpack > > > > - dependency:unpack-dependencies > > > > > > > > > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > > > napisał(a): > > > > > > > > > Howdy, > > > > > > > > > > I'd would be interested in how users and devs are using > > > > > maven-dependency-plugin: > > > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > > > > > I collected some basic questions I'd like to have answered (but > feel > > > free > > > > > to add more info!): > > > > > - which goals are "must have" for you > > > > > - which goals are "I never touched" for you (or, "I really don't > > need" > > > or > > > > > "never used" or "shrug") > > > > > - what is missing? > > > > > > > > > > Thanks > > > > > T > > > > > > > > > > > > > > > > > -- > > > > Sławomir Jaranowski > > > > > > > > > >
Re: [DISCUSS] Maven Dependency Plugin
My understanding is dependency:go-offline is an effective way to pre-download plugins and dependencies, for instance if one is making some layer in a docker build container for later reuse. On Thu, Mar 21, 2024 at 2:54 PM Tamás Cservenák wrote: > Howdy, > > What is the use case of "go offline"? > That is yet another goal coming from "Maven2 era" and messes up your local > repository (wrt back tracing dependencies, > https://issues.apache.org/jira/browse/MNG-7619) > I mean, if you do a build (w/o tests, or skipping most time stealing > steps), like "dry build", why is that not an option? > > T > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz wrote: > > > +1 to this list from Slawomir: > > > > - dependency:analyze / dependency:analyze-only > > - dependency:copy > > - dependency:copy-dependencies > > - dependency:go-offline > > - dependency:list > > - dependency:tree > > - dependency:unpack > > - dependency:unpack-dependencies > > > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > > s.jaranow...@gmail.com> > > wrote: > > > > > Hi > > > I use: > > > > > > - dependency:analyze / dependency:analyze-only > > > - dependency:copy > > > - dependency:copy-dependencies > > > - dependency:go-offline > > > - dependency:list > > > - dependency:tree > > > - dependency:unpack > > > - dependency:unpack-dependencies > > > > > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > > napisał(a): > > > > > > > Howdy, > > > > > > > > I'd would be interested in how users and devs are using > > > > maven-dependency-plugin: > > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > > > I collected some basic questions I'd like to have answered (but feel > > free > > > > to add more info!): > > > > - which goals are "must have" for you > > > > - which goals are "I never touched" for you (or, "I really don't > need" > > or > > > > "never used" or "shrug") > > > > - what is missing? > > > > > > > > Thanks > > > > T > > > > > > > > > > > > > -- > > > Sławomir Jaranowski > > > > > >
Re: [DISCUSS] Maven Dependency Plugin
So, in Maven2, the local repo was really "just a bunch of files" (totally wild west). With Maven3, and Resolver (yes, this is true from 3.0) the "enhanced" local repository is used, that tries to "track" origin (of cached, not installed) artifacts. In Maven 3.9 the next step is made, which is a "split local repository", where files (as opposed to "enhanced") are physically kept in split locations. All goals and plugins that _assume_ that local repository is "just a bunch of files" are wrong, and should be avoided. (this was the reason for all the plugin warnings in Maven 3.9.x line as well, to make them stand out, and have plugin authors make the step of correcting them, or users abandoning them) A related typical example was https://issues.apache.org/jira/browse/MASSEMBLY-957 where it was "assumed" that "local" and "remote" repository notion is interchangeable. Is not. These (mis)conceptions must go away. T On Thu, Mar 21, 2024 at 8:54 PM Tamás Cservenák wrote: > Howdy, > > What is the use case of "go offline"? > That is yet another goal coming from "Maven2 era" and messes up your local > repository (wrt back tracing dependencies, > https://issues.apache.org/jira/browse/MNG-7619) > I mean, if you do a build (w/o tests, or skipping most time stealing > steps), like "dry build", why is that not an option? > > T > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz wrote: > >> +1 to this list from Slawomir: >> >> - dependency:analyze / dependency:analyze-only >> - dependency:copy >> - dependency:copy-dependencies >> - dependency:go-offline >> - dependency:list >> - dependency:tree >> - dependency:unpack >> - dependency:unpack-dependencies >> >> On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < >> s.jaranow...@gmail.com> >> wrote: >> >> > Hi >> > I use: >> > >> > - dependency:analyze / dependency:analyze-only >> > - dependency:copy >> > - dependency:copy-dependencies >> > - dependency:go-offline >> > - dependency:list >> > - dependency:tree >> > - dependency:unpack >> > - dependency:unpack-dependencies >> > >> > >> > >> > czw., 21 mar 2024 o 17:06 Tamás Cservenák >> > napisał(a): >> > >> > > Howdy, >> > > >> > > I'd would be interested in how users and devs are using >> > > maven-dependency-plugin: >> > > https://maven.apache.org/plugins/maven-dependency-plugin/ >> > > >> > > I collected some basic questions I'd like to have answered (but feel >> free >> > > to add more info!): >> > > - which goals are "must have" for you >> > > - which goals are "I never touched" for you (or, "I really don't >> need" or >> > > "never used" or "shrug") >> > > - what is missing? >> > > >> > > Thanks >> > > T >> > > >> > >> > >> > -- >> > Sławomir Jaranowski >> > >> >
Re: [DISCUSS] Maven Dependency Plugin
Howdy, What is the use case of "go offline"? That is yet another goal coming from "Maven2 era" and messes up your local repository (wrt back tracing dependencies, https://issues.apache.org/jira/browse/MNG-7619) I mean, if you do a build (w/o tests, or skipping most time stealing steps), like "dry build", why is that not an option? T On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz wrote: > +1 to this list from Slawomir: > > - dependency:analyze / dependency:analyze-only > - dependency:copy > - dependency:copy-dependencies > - dependency:go-offline > - dependency:list > - dependency:tree > - dependency:unpack > - dependency:unpack-dependencies > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > s.jaranow...@gmail.com> > wrote: > > > Hi > > I use: > > > > - dependency:analyze / dependency:analyze-only > > - dependency:copy > > - dependency:copy-dependencies > > - dependency:go-offline > > - dependency:list > > - dependency:tree > > - dependency:unpack > > - dependency:unpack-dependencies > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > napisał(a): > > > > > Howdy, > > > > > > I'd would be interested in how users and devs are using > > > maven-dependency-plugin: > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > I collected some basic questions I'd like to have answered (but feel > free > > > to add more info!): > > > - which goals are "must have" for you > > > - which goals are "I never touched" for you (or, "I really don't need" > or > > > "never used" or "shrug") > > > - what is missing? > > > > > > Thanks > > > T > > > > > > > > > -- > > Sławomir Jaranowski > > >
Re: [DISCUSS] Maven Dependency Plugin
+1 to this list from Slawomir: - dependency:analyze / dependency:analyze-only - dependency:copy - dependency:copy-dependencies - dependency:go-offline - dependency:list - dependency:tree - dependency:unpack - dependency:unpack-dependencies On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski wrote: > Hi > I use: > > - dependency:analyze / dependency:analyze-only > - dependency:copy > - dependency:copy-dependencies > - dependency:go-offline > - dependency:list > - dependency:tree > - dependency:unpack > - dependency:unpack-dependencies > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > napisał(a): > > > Howdy, > > > > I'd would be interested in how users and devs are using > > maven-dependency-plugin: > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > I collected some basic questions I'd like to have answered (but feel free > > to add more info!): > > - which goals are "must have" for you > > - which goals are "I never touched" for you (or, "I really don't need" or > > "never used" or "shrug") > > - what is missing? > > > > Thanks > > T > > > > > -- > Sławomir Jaranowski >
Re: [DISCUSS] Maven Dependency Plugin
Like a couple of other folks 90% of my usage is dependency:analyze and dependency:tree. Other goals I barely notice. On Thu, Mar 21, 2024 at 12:06 PM Tamás Cservenák wrote: > > Howdy, > > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? > > Thanks > T -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
Agreed, Use of "purge-local-repository" is a very bad thing (next to "go offline" and related goals). They all come from the "maven2 era", and should never be used with Maven3... T On Thu, Mar 21, 2024 at 7:50 PM Richard Eckart de Castilho wrote: > > > On 21. Mar 2024, at 19:43, Tamás Cservenák wrote: > > > > I mean, I know what those goals do, I am just unsure WHY you needed > those. > > The current Apache UIMA release guidelines still list them as suggested > steps > to perform before a local trial build to ensure locally cached artifacts do > not interfere with the build. > > https://uima.apache.org/release.html > > That said, I personally do not use these goal when I run a release build > and the new guidelines will not list them anymore - at least for the time > being... > > But I'm sure people wise then I have had a reason the include them in the > guidelines back in the day. > > -- Richard > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: [DISCUSS] Maven Dependency Plugin
Hi I use: - dependency:analyze / dependency:analyze-only - dependency:copy - dependency:copy-dependencies - dependency:go-offline - dependency:list - dependency:tree - dependency:unpack - dependency:unpack-dependencies czw., 21 mar 2024 o 17:06 Tamás Cservenák napisał(a): > Howdy, > > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? > > Thanks > T > -- Sławomir Jaranowski
Re: [DISCUSS] Maven Dependency Plugin
> On 21. Mar 2024, at 19:43, Tamás Cservenák wrote: > > I mean, I know what those goals do, I am just unsure WHY you needed those. The current Apache UIMA release guidelines still list them as suggested steps to perform before a local trial build to ensure locally cached artifacts do not interfere with the build. https://uima.apache.org/release.html That said, I personally do not use these goal when I run a release build and the new guidelines will not list them anymore - at least for the time being... But I'm sure people wise then I have had a reason the include them in the guidelines back in the day. -- Richard - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
Howdy, Oliver: all, really? I wonder what you used for goals like "purge-local-repository", "resolve-plugins" etc :) I mean, I know what those goals do, I am just unsure WHY you needed those. T On Thu, Mar 21, 2024 at 6:41 PM Oliver B. Fischer wrote: > Hi, > > over the time I used all of them in different projects and I think all > of them are needed. > > Viele Grüße > > Oliver > > > Am 21.03.24 um 17:04 schrieb Tamás Cservenák: > > Howdy, > > > > I'd would be interested in how users and devs are using > > maven-dependency-plugin: > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > I collected some basic questions I'd like to have answered (but feel free > > to add more info!): > > - which goals are "must have" for you > > - which goals are "I never touched" for you (or, "I really don't need" or > > "never used" or "shrug") > > - what is missing? > > > > Thanks > > T > > > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > E o.b.fisc...@swe-blog.net > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: [DISCUSS] Maven Dependency Plugin
Hi, over the time I used all of them in different projects and I think all of them are needed. Viele Grüße Oliver Am 21.03.24 um 17:04 schrieb Tamás Cservenák: Howdy, I'd would be interested in how users and devs are using maven-dependency-plugin: https://maven.apache.org/plugins/maven-dependency-plugin/ I collected some basic questions I'd like to have answered (but feel free to add more info!): - which goals are "must have" for you - which goals are "I never touched" for you (or, "I really don't need" or "never used" or "shrug") - what is missing? Thanks T -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 E o.b.fisc...@swe-blog.net - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
Hi, I mostly use the "analyze" (mostly the "analyze-only") and "tree" goals, but I have also already used "copy/unpack-dependencies", "sources", "purge-local-repository" and "resolve". IMHO the "versions" plugin has a few functionalities that feel like could also belong to the dependencies plugin, in particular goals related to checking if dependencies are up-to-date or updating dependencies to a later version. Well, I guess these goals are about versions as much as they are about dependencies... What I miss is being able to see where a particular dependency version was originally defined - "tree" only says the resolved dependencies, but e.g. not which properties were used in resolving the version and which dependencyManagement sections in which POMs (best with line numbers) were involved. Fortunately, m2eclipse can be of some help here. Cheers, -- Richard - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
Hi For me it is: * Tree: human work on transitivity * List: pre-resolve for the runtime (dump jar list in a file) * Resolve: CI init phase Le jeu. 21 mars 2024 à 17:54, Christian Stein a écrit : > I use the "resolve" goal like this: > > mvn --batch-mode --no-transfer-progress -DoutputFile=resolved.txt > org.apache.maven.plugins:maven-dependency-plugin:3.6.1:resolve > > ...and parse the output for Java module names and whether they are > "automatic". > > > https://github.com/sormuras/maven-starter-projects/blob/c7839302f3552caa4de42bc97aa151ddabf7bc78/src/GenerateReadme.java#L74 > > On Thu, Mar 21, 2024 at 5:06 PM Tamás Cservenák > wrote: > > > Howdy, > > > > I'd would be interested in how users and devs are using > > maven-dependency-plugin: > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > I collected some basic questions I'd like to have answered (but feel free > > to add more info!): > > - which goals are "must have" for you > > - which goals are "I never touched" for you (or, "I really don't need" or > > "never used" or "shrug") > > - what is missing? > > > > Thanks > > T > > >
Re: [DISCUSS] Maven Dependency Plugin
Hey, mainly tree and analyze (note: we also use enforcer-plugin with some rules for dependencies) Greetings Matthias Am 21.03.2024 um 17:04 schrieb Tamás Cservenák: Howdy, I'd would be interested in how users and devs are using maven-dependency-plugin: https://maven.apache.org/plugins/maven-dependency-plugin/ I collected some basic questions I'd like to have answered (but feel free to add more info!): - which goals are "must have" for you - which goals are "I never touched" for you (or, "I really don't need" or "never used" or "shrug") - what is missing? Thanks T - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
I use the "resolve" goal like this: mvn --batch-mode --no-transfer-progress -DoutputFile=resolved.txt org.apache.maven.plugins:maven-dependency-plugin:3.6.1:resolve ...and parse the output for Java module names and whether they are "automatic". https://github.com/sormuras/maven-starter-projects/blob/c7839302f3552caa4de42bc97aa151ddabf7bc78/src/GenerateReadme.java#L74 On Thu, Mar 21, 2024 at 5:06 PM Tamás Cservenák wrote: > Howdy, > > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? > > Thanks > T >
Re: [DISCUSS] Maven Dependency Plugin
The tree goal is my go to for this plugin. I also like the analyze. A wish I have is to get a more clearer view of the resolved dependencies version with regard to the declared dependencyManagement and/or the shortest path to dependency. For example, when I see the dependency slf4j-api with version 1.7, it would be nice to get the resolution logic maven takes to compute this 1.7 number (direct dependency with a version specified -> dependencyManagement (and when you have multiple, their ordering) -> shortest transitive path). IDE provide these (I love Eclipse dependency view) but it would be nice to have it on the cli as well. Thanks for reaching out! On Thu, Mar 21, 2024 at 12:35 PM Gary Gregory wrote: > The one I use the most from the command line is "tree" ( > https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html) > > I wish I could say "ignore test scope" to help me understand my runtime > dependencies better. > > Gary > > > On Thu, Mar 21, 2024, 12:06 PM Tamás Cservenák > wrote: > > > Howdy, > > > > I'd would be interested in how users and devs are using > > maven-dependency-plugin: > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > I collected some basic questions I'd like to have answered (but feel free > > to add more info!): > > - which goals are "must have" for you > > - which goals are "I never touched" for you (or, "I really don't need" or > > "never used" or "shrug") > > - what is missing? > > > > Thanks > > T > > >
Re: [DISCUSS] Maven Dependency Plugin
The one I use the most from the command line is "tree" ( https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html) I wish I could say "ignore test scope" to help me understand my runtime dependencies better. Gary On Thu, Mar 21, 2024, 12:06 PM Tamás Cservenák wrote: > Howdy, > > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? > > Thanks > T >
Re: [DISCUSS] Maven Dependency Plugin
Most of the time I use copy-dependencies goal to build non fat jar deployments. Meanwhile tree goal helps figure out multimodule dependency clashes by showing resolved ransitive dependencies. As for the rest, i can see where and what could use them, but I haven't used them directly. On Thu, Mar 21, 2024, 18:06 Tamás Cservenák wrote: > Howdy, > > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? > > Thanks > T >
[DISCUSS] Maven Dependency Plugin
Howdy, I'd would be interested in how users and devs are using maven-dependency-plugin: https://maven.apache.org/plugins/maven-dependency-plugin/ I collected some basic questions I'd like to have answered (but feel free to add more info!): - which goals are "must have" for you - which goals are "I never touched" for you (or, "I really don't need" or "never used" or "shrug") - what is missing? Thanks T
[ANN] Release Maven Dependency Plugin 3.6.1 released
The Apache Maven team is pleased to announce the release of the Maven Dependency Plugin version 3.6.1. https://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.6.1 Release Notes - Maven Dependency Plugin - Version 3.6.1 ** Bug * [MDEP-875] - Regression: list-repositories may produce NPE ** Dependency upgrade * [MDEP-868] - maven-shared-utils to 3.4.2 * [MDEP-872] - update commons-io to 2.13.0 * [MDEP-882] - Upgrade plexus-archiver due to CVE-2023-37460 * [MDEP-883] - Upgrade maven-plugin parent to 40 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Release Maven Dependency Plugin 3.6.0 released
The Apache Maven team is pleased to announce the release of the Maven Dependency Plugin version 3.6.0. https://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.6.0 Release Notes - Maven Dependency Plugin - Version 3.6.0 ** Bug * [MDEP-630] - error dependency:list (caused by postgresql dependency) * [MDEP-842] - :list-classes does not skip if skip is set * [MDEP-843] - :list-classes does not use GAV parameters ** Improvement * [MDEP-853] - list-repositories - improvements * [MDEP-862] - warns about depending on plexus-container-default * [MDEP-864] - Replace AnalyzeReportView with a new AnalyzeReportRenderer ** Task * [MDEP-849] - Replace Maven shared StringUtils with Commons Lang3 * [MDEP-855] - Remove unused and ignored parameter - useJvmChmod * [MDEP-857] - Remove custom plexus configuration * [MDEP-859] - Code refactor - UnpackUtil * [MDEP-866] - Refresh download page ** Dependency upgrade * [MDEP-848] - Dependency Analysis does not work under Java 20 * [MDEP-850] - Upgrade Parent to 39 * [MDEP-851] - Bump plexus-archiver from 4.6.2 to 4.7.1 * [MDEP-854] - Bump jsoup from 1.15.3 to 1.16.1 * [MDEP-856] - Upgrade commons-text to 1.10.0 * [MDEP-860] - Bump maven-dependency-analyzer from 1.13.1 to 1.13.2 * [MDEP-867] - Upgrade plugins in ITs Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Some queries regarding maven-dependency plugin
Hi Everyone, I have been using maven-dependency-plugin for resolving artifact path (goal: properties) org.apache.maven.plugins maven-dependency-plugin 3.3.0 getArtifactPath properties And accessing the property ${*groupId:artifactId:jar} . * I am interested in knowing the internal working of how this works. Does the plugin add the properties like below? This isn't the valid property name for xml syntax. path I would like to achieve adding this property on runtime manually because the dependency plugin isn't working with IDE execution. -- Thanks, Kamalpreet
[ANN] Release Maven Dependency Plugin 3.5.0 released
The Apache Maven team is pleased to announce the release of the Maven Dependency Plugin version 3.5.0. https://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.5.0 Release Notes - Maven Dependency Plugin - Version 3.5.0 ** Improvement * [MDEP-831] - Remove not used dependencies / Replace parts ** Task * [MDEP-841] - Explicitly start and end tables with Doxia Sinks in report renderers ** Dependency upgrade * [MDEP-837] - Upgrade Parent to 38 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Release Maven Dependency Plugin 3.4.0 released
The Apache Maven team is pleased to announce the release of the Maven Dependency Plugin version 3.4.0. https://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.4.0 Release Notes - Maven Dependency Plugin - Version 3.4.0 ** Bug * [MDEP-806] - Dependency tree in verbose mode for war is empty * [MDEP-809] - Javadoc was not updated to reflect that :tree's verbose option is now ok ** New Feature * [MDEP-782] - Add a option to unpack goals * [MDEP-804] - Allow auto-ignore of all non-test scoped dependencies used only in test scope ** Improvement * [MDEP-602] - Turn warnings into errors instead of failOnWarning * [MDEP-674] - maven-dependency-plugin should leverage plexus-build-api to support IDEs * [MDEP-716] - TestListClassesMojo logs too much * [MDEP-827] - Use outputDirectory from AbstractMavenReport ** Dependency upgrade * [MDEP-813] - Require Maven 3.2.5 * [MDEP-814] - Bump mrm-maven-plugin from 1.2.0 to 1.4.1 * [MDEP-815] - Upgrade Parent to 37 * [MDEP-817] - Bump maven-common-artifact-filters from 3.2.0 to 3.3.1 * [MDEP-818] - Bump plexus-io from 3.2.0 to 3.4.0 * [MDEP-821] - Bump mockito-core from 4.3.1 to 4.7.0 * [MDEP-822] - Bump maven-dependency-tree from 3.1.0 to 3.2.1 * [MDEP-823] - Bump maven-dependency-analyzer from 1.12.0 to 1.13.0 * [MDEP-824] - Bump plexus-utils from 3.4.1 to 3.5.0 * [MDEP-825] - Bump mockito-core from 4.7.0 to 4.9.0 * [MDEP-826] - Upgrade maven-reporting-impl from 3.1.0 to 3.2.0 * [MDEP-834] - Bump maven-common-artifact-filters from 3.3.1 to 3.3.2 * [MDEP-836] - Bump plexus-archiver from 4.2.2 to 4.6.0 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Please release maven-dependency-plugin 3.3.1
Hi, Thanks for pointing this out. I will check the current code, current open issues and prepare for the next release. I think in the next two, three weeks it should be done. Any help for verifying open issues will be highly appreciated. [1] [1] https://issues.apache.org/jira/projects/MDEP śr., 2 lis 2022 o 17:59 Andreas Sewe napisał(a): > Hi, > > would it be possible to please release the next version of the > maven-dependency-plugin, 3.3.1? > > Besides bug-fix updates to its maven-dependency-analyzer and > maven-dependency-tree dependencies, version 3.3.1 also introduces the > new configuration options which I need in a project of mine. > (FYI, I've built and tested a 3.3.1-SNAPSHOT myself and can confirm that > the option works as advertised. :-) > > Best wishes, > > Andreas Sewe > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Sławomir Jaranowski
Please release maven-dependency-plugin 3.3.1
Hi, would it be possible to please release the next version of the maven-dependency-plugin, 3.3.1? Besides bug-fix updates to its maven-dependency-analyzer and maven-dependency-tree dependencies, version 3.3.1 also introduces the new configuration options which I need in a project of mine. (FYI, I've built and tested a 3.3.1-SNAPSHOT myself and can confirm that the option works as advertised. :-) Best wishes, Andreas Sewe - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Dependency Plugin 3.3.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Dependency Plugin, version 3.3.0 This plugin provides utility goals to work with dependencies like copying, unpacking, analyzing, resolving and many more. https://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.3.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-dependency-plugin/download.cgi Release Notes - Maven Dependency Plugin - Version 3.3.0 ** Bug * [MDEP-679] - mvn dependency:analyze detected wrong transitive dependency * [MDEP-742] - dependency plugin does not work with JDK 16 * [MDEP-752] - skip dependency analyze in ear packaging * [MDEP-753] - Non-test dependency reported as Non-test scoped test only dependency * [MDEP-759] - 'Dependency not found' with 3.2.0 and Java-17 while analyzing * [MDEP-761] - Tree plugin does not terminate with 3.2.0 * [MDEP-769] - Minor improvement - continue * [MDEP-774] - analyze-only failed: PermittedSubclasses requires ASM9 * [MDEP-781] - Broken Link to "Introduction to Dependency Mechanism Page" * [MDEP-783] - TreeMojo docs say scope doesn't work due to MSHARED-4 * [MDEP-786] - Sealed classes not supported ** New Feature * [MDEP-787] - Allow ignoring non-test-scoped dependencies ** Improvement * [MDEP-763] - Minor improvements * [MDEP-768] - GitHub Action build improvement * [MDEP-779] - dependency:analyze should list the classes that cause a used undeclared dependency * [MDEP-789] - Improve documentation of analyze - Non-test scoped ** Task * [MDEP-760] - Java 1.8 as minimum ** Dependency upgrade * [MDEP-766] - Upgrade maven-invoker-plugin to version 3.2.2 * [MDEP-784] - Upgrade maven-dependency-analyzer to 1.12.0 * [MDEP-788] - Upgrade maven-reporting-impl to version 3.1.0 * [MDEP-795] - Update Jetty to 9.4.45.v20220203 * [MDEP-796] - Upgrade Maven Parent to 35 * [MDEP-797] - Update transitive dependency commons-beanutils to 1.9.4 * [MDEP-798] - Upgrade maven-dependency-tree from 3.0.1 to 3.1.0 Enjoy, -The Apache Maven team
Maven Dependency Plugin not working with JDK 17
Hi, Did anyone tried the most recent version of Maven Dependency Plugin 3.2.0 with JDK 17? I'm getting the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.2.0:analyze-only (enforce) on project my-project: Execution enforce of goal org.apache.maven.plugins:maven-dependency-plugin:3.2.0:analyze-only failed: PermittedSubclasses requires ASM9 But it supposedly already brings ASM 9.1, and I event tried to force it but the error continues: org.apache.maven.plugins maven-dependency-plugin 3.2.0 org.ow2.asm asm 9.1
[ANN] Release Maven Dependency Plugin 3.2.0 released
The Apache Maven team is pleased to announce the release of the Maven Dependency Plugin version 3.2.0. https://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.2.0 Release Notes - Maven Dependency Plugin - Version 3.2.0 ** Bug * [MDEP-693] - `dependency:analyze-only` goal fails on OpenJDK 14 * [MDEP-698] - FileWriter and FileReader should be replaced * [MDEP-739] - Dependency Plugin go-offline doesn't respect artifact classifier * [MDEP-740] - analyze-only failed: Unsupported class file major version 60 (Java 16) * [MDEP-747] - analyze-only failed: Unsupported class file major version 61 (Java 17) * [MDEP-749] - copy-dependencies fails when using excludeScope=test ** New Feature * [MDEP-714] - Add analyze parameter "ignoreUnusedRuntime" ** Dependency upgrade * [MDEP-686] - Upgrade maven-artifact-transfer from 0.11.0 to 0.13.1 * [MDEP-720] - Update maven-dependency-analyzer to 1.11.3 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-dependency-plugin 3.1.3?
I have been hunting down old security "vulnerable" versions of struts that have been showing up in my .m2 directory, which is raising flags from my Security people. The dependency seems to be coming from an old doxia-site-renderer. It has been updated to not have a dependency on struts at all with version 1.9.2. Many of the maven plugins have been updated and released using this updated version of doxia-site-renderer. Unfortunately maven-dependency-plugin has not been released with this update. So it is impossible to fully update to that version of doxia-site-renderer, as the version from the maven-dependency-plugin 3.1.2 cannot be updated by specifically overriding the dependency version in pluginManagement before it pulls down struts (chicken and egg issue). Looking at the repo on github, there was a tag created for maven-dependency-plugin 3.1.3 which looks to use the updated doxia-site-renderer back in Oct. 2020, but it has not been released (or at least maven central still only has v3.1.2). Is there a plan for releasing it or a newer version soon? Thanks, Tom
Re: maven-dependency-plugin unpack goal: do not overwrite existing files
See my answer on StackOverflow. I hope it helps. https://stackoverflow.com/a/67158497/1082681 -- Alexander Kriegisch https://scrum-master.de Amedee Van Gasse schrieb am 19.04.2021 14:42 (GMT +07:00): > I do not ever want maven-dependency-plugin:3.1.2:unpack to overwrite existing > files in any circumstances. This is my current pom.xml configuration: > > > maven-dependency-plugin > 3.1.2 > > > unpack-zip-files > generate-test-resources > > unpack > > > > > com.foo > bar > ${foobar.version} > zip > exe-archive > false > > ${project.build.directory}/lib > **/*.exe > > > false > false > false > > > > > > ***Scenario*** > > * Projects foo and bar > * foo has a .exe file as build artifact, inside a ZIP file > * bar runs the .exe file during tests > * In situation X, bar must use the snapshot version of the mainline > development > branch of foo. In that case, the directory target/lib shall be empty before > mvn > install. This is guaranteed by starting from an empty workspace and running > mvn > clean as a separate build step. This question is not about situation X. > * In situation Y, bar must use a custom build of a feature branch of foo. This > is done by unpacking the ZIP file with the .exe to the directory target/lib in > a separate build step between mvn clean and mvn install. > * We are working in situation Y, where the target/lib directory is already > pre-filled with the .exe from the correct feature branch. > > This is the target/lib directory before mvn is run: > > + ls -al fooBar.exe > -rw-rw-r-- 1 ubuntu ubuntu 18368427 Apr 12 21:27 fooBar.exe > + md5sum fooBar.exe > 03acc8b5c3da700c31efcd6635feb56a fooBar.exe > > This is the target/lib directory after mvn is run: > > + ls -al fooBar.exe > -rwxrwxr-x 1 ubuntu ubuntu 18368393 Apr 11 23:10 fooBar.exe > + md5sum fooBar.exe > ab6dd45c5cc4e41534ad2363c5767601 fooBar.exe > The change in md5sum is hard evidence that the existing fooBar.exe was > overwritten by Maven. > > ***Maven command used*** > > mvn --global-settings > /home/jenkins/workspace/bar@tmp/config15592668079584895681tmp \ > -Dmaven.repo.local=/home/jenkins/workspace/bar/.repository \ > install \ > -DgsExec=/usr/bin/gs -DcompareExec=/usr/local/bin/compare \ > -Dtest=RunCucumberTest -Dcucumber.options=--plugin > json:target/cucumber.json > > ***Expected results*** > > * The mvn install command shall not overwrite existing files when overWrite, > overWriteIfNewer, overWriteReleases, overWriteSnapshots are all set to false. > * The md5sum of fooBar.exe shall be the same before and after running mvn > install. > > ***Question*** > > Which magical incantations do I need to add to pom.xml so that existing files > are never overwritten in any circumstances? > > ***Documentation referenced*** > > https://maven.apache.org/plugins/maven-dependency-plugin/usage.html#Overwrite_Rules > https://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html > > Also asked on Stack Overflow, but I didn't get an answer there: > https://stackoverflow.com/questions/67066164/maven-dependency-plugin-unpack-goal-do-not-overwrite-existing-files > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-dependency-plugin unpack goal: do not overwrite existing files
Hi Amedee. Can you post the output of your command again, replacing "install" with "fr.jcgay.maven.plugins:buildplan-maven-plugin:list-phase" Delany On Mon, 19 Apr 2021 at 09:42, Amedee Van Gasse wrote: > I do not ever want maven-dependency-plugin:3.1.2:unpack to overwrite > existing files in any circumstances. This is my current pom.xml > configuration: > > > maven-dependency-plugin > 3.1.2 > > > unpack-zip-files > generate-test-resources > > unpack > > > > > com.foo > bar > ${foobar.version} > zip > exe-archive > false > > ${project.build.directory}/lib > **/*.exe > > > false > false > false > > > > > > ***Scenario*** > > * Projects foo and bar > * foo has a .exe file as build artifact, inside a ZIP file > * bar runs the .exe file during tests > * In situation X, bar must use the snapshot version of the mainline > development branch of foo. In that case, the directory target/lib shall be > empty before mvn install. This is guaranteed by starting from an empty > workspace and running mvn clean as a separate build step. This question is > not about situation X. > * In situation Y, bar must use a custom build of a feature branch of foo. > This is done by unpacking the ZIP file with the .exe to the directory > target/lib in a separate build step between mvn clean and mvn install. > * We are working in situation Y, where the target/lib directory is already > pre-filled with the .exe from the correct feature branch. > > This is the target/lib directory before mvn is run: > > + ls -al fooBar.exe > -rw-rw-r-- 1 ubuntu ubuntu 18368427 Apr 12 21:27 fooBar.exe > + md5sum fooBar.exe > 03acc8b5c3da700c31efcd6635feb56a fooBar.exe > > This is the target/lib directory after mvn is run: > > + ls -al fooBar.exe > -rwxrwxr-x 1 ubuntu ubuntu 18368393 Apr 11 23:10 fooBar.exe > + md5sum fooBar.exe > ab6dd45c5cc4e41534ad2363c5767601 fooBar.exe > The change in md5sum is hard evidence that the existing fooBar.exe was > overwritten by Maven. > > ***Maven command used*** > > mvn --global-settings > /home/jenkins/workspace/bar@tmp/config15592668079584895681tmp > \ > -Dmaven.repo.local=/home/jenkins/workspace/bar/.repository \ > install \ > -DgsExec=/usr/bin/gs -DcompareExec=/usr/local/bin/compare \ > -Dtest=RunCucumberTest -Dcucumber.options=--plugin > json:target/cucumber.json > > ***Expected results*** > > * The mvn install command shall not overwrite existing files when > overWrite, overWriteIfNewer, overWriteReleases, overWriteSnapshots are all > set to false. > * The md5sum of fooBar.exe shall be the same before and after running mvn > install. > > ***Question*** > > Which magical incantations do I need to add to pom.xml so that existing > files are never overwritten in any circumstances? > > ***Documentation referenced*** > > > https://maven.apache.org/plugins/maven-dependency-plugin/usage.html#Overwrite_Rules > https://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html > > Also asked on Stack Overflow, but I didn't get an answer there: > > https://stackoverflow.com/questions/67066164/maven-dependency-plugin-unpack-goal-do-not-overwrite-existing-files > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
maven-dependency-plugin unpack goal: do not overwrite existing files
I do not ever want maven-dependency-plugin:3.1.2:unpack to overwrite existing files in any circumstances. This is my current pom.xml configuration: maven-dependency-plugin 3.1.2 unpack-zip-files generate-test-resources unpack com.foo bar ${foobar.version} zip exe-archive false ${project.build.directory}/lib **/*.exe false false false ***Scenario*** * Projects foo and bar * foo has a .exe file as build artifact, inside a ZIP file * bar runs the .exe file during tests * In situation X, bar must use the snapshot version of the mainline development branch of foo. In that case, the directory target/lib shall be empty before mvn install. This is guaranteed by starting from an empty workspace and running mvn clean as a separate build step. This question is not about situation X. * In situation Y, bar must use a custom build of a feature branch of foo. This is done by unpacking the ZIP file with the .exe to the directory target/lib in a separate build step between mvn clean and mvn install. * We are working in situation Y, where the target/lib directory is already pre-filled with the .exe from the correct feature branch. This is the target/lib directory before mvn is run: + ls -al fooBar.exe -rw-rw-r-- 1 ubuntu ubuntu 18368427 Apr 12 21:27 fooBar.exe + md5sum fooBar.exe 03acc8b5c3da700c31efcd6635feb56a fooBar.exe This is the target/lib directory after mvn is run: + ls -al fooBar.exe -rwxrwxr-x 1 ubuntu ubuntu 18368393 Apr 11 23:10 fooBar.exe + md5sum fooBar.exe ab6dd45c5cc4e41534ad2363c5767601 fooBar.exe The change in md5sum is hard evidence that the existing fooBar.exe was overwritten by Maven. ***Maven command used*** mvn --global-settings /home/jenkins/workspace/bar@tmp/config15592668079584895681tmp \ -Dmaven.repo.local=/home/jenkins/workspace/bar/.repository \ install \ -DgsExec=/usr/bin/gs -DcompareExec=/usr/local/bin/compare \ -Dtest=RunCucumberTest -Dcucumber.options=--plugin json:target/cucumber.json ***Expected results*** * The mvn install command shall not overwrite existing files when overWrite, overWriteIfNewer, overWriteReleases, overWriteSnapshots are all set to false. * The md5sum of fooBar.exe shall be the same before and after running mvn install. ***Question*** Which magical incantations do I need to add to pom.xml so that existing files are never overwritten in any circumstances? ***Documentation referenced*** https://maven.apache.org/plugins/maven-dependency-plugin/usage.html#Overwrite_Rules https://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html Also asked on Stack Overflow, but I didn't get an answer there: https://stackoverflow.com/questions/67066164/maven-dependency-plugin-unpack-goal-do-not-overwrite-existing-files - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency plugin unpack plugin dependencies
Hi Alexander, this is an old thread, but no one has replied yet. While I think this is possible – what are you trying to achieve? Or in other words: WHY do you need the dependencies unpacked? What do you do with them? Regards, Ben On 2020/08/19 18:23:06, Alexander Broekhuis wrote: > Hi all, > > I currently have a setup in which I have some custom artifacts that I use > as dependencies and unpack using unpack-dependencies. > This all works great, but now I also have a custom plugin which needs one > of the custom artifacts as dependency. I don't see those dependencies being > unpacked. Is this correct, or am I doing something wrong? > > I know I can add the dependency as "regular" dependency as workaround, but > I'd like to be able to define the plugin in a parent's pluginManagement > with it's dependencies so that dependant project can enable the plugin when > needed without having to define the dependency, or always have it being > unpacked even if not needed. > > Basically my pom looks like this (meta): > > // Those are unpacked as expected > > > > > // Those dependencies are not unpacked > > > > > > > > > -- > Met vriendelijke groet, > > Alexander Broekhuis > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Dependency Plugin
I'm out of the loop regarding the 3.7.0 release schedule so can't answer that myself, you'll need to ask the developers mailing list. The email about maven-wrapper-plugin v3.0.1 is this one from the developers mailing list https://lists.apache.org/thread.html/r7cb5dd04726af22f3c69092a7057e2674383deab09caf3fe80bef98e%40%3Cdev.maven.apache.org%3E There are a few other emails about maven-wrapper-plugin and was an issue with v3.0.0 which is why v3.0.1 was released. I'm 99.999% sure it was only intended to work with v3.7.0 and newer versions only, so feel free to raise a pr. John On Mon, 26 Oct 2020 at 11:33, Markus Karg wrote: > > Thank you for this information. It is a bit misleading that the line says "as > introduced" (past tense) for a release that actually does not exist yet. > Would it be OK if I file a PR to clarify that? What is the anticipated > release date of Maven 3.7.0 that I could announce there? > -Markus > > > -Ursprüngliche Nachricht- > Von: John Patrick > Gesendet: Montag, 26. Oktober 2020 12:07 > An: Maven Users List > Betreff: Re: Maven Dependency Plugin > > If you read the opening line it talks about Maven 3.7.0, which is not yet > released. > > If you want to use a maven wrapper before v3.7.0, then use this > https://github.com/takari/maven-wrapper. The upgrade from takari to maven is > easy but does allow you to change your documentation, process and ci process > instead of waiting until v3.7.0. > > I did test the maven-wrapper-plugin a few months ago and I had to add a > staging repo of something like this before it worked > https://repository.apache.org/service/local/repositories/maven-XXX/content/. > But can't remember what XXX it was as I've got ~10 in my settings.xml > commented out. > > John > > On Mon, 26 Oct 2020 at 10:53, Markus Karg wrote: > > > > When I am using this plugin > > https://maven.apache.org/plugins/maven-wrapper-plugin/ then Maven fails > > because it apparently cannot find needed runtime files on Maven Central. > > This limitation is not told on that page. Is that a bug or am I doing > > something wrong? > > -Markus > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: Maven Dependency Plugin
Thank you for this information. It is a bit misleading that the line says "as introduced" (past tense) for a release that actually does not exist yet. Would it be OK if I file a PR to clarify that? What is the anticipated release date of Maven 3.7.0 that I could announce there? -Markus -Ursprüngliche Nachricht- Von: John Patrick Gesendet: Montag, 26. Oktober 2020 12:07 An: Maven Users List Betreff: Re: Maven Dependency Plugin If you read the opening line it talks about Maven 3.7.0, which is not yet released. If you want to use a maven wrapper before v3.7.0, then use this https://github.com/takari/maven-wrapper. The upgrade from takari to maven is easy but does allow you to change your documentation, process and ci process instead of waiting until v3.7.0. I did test the maven-wrapper-plugin a few months ago and I had to add a staging repo of something like this before it worked https://repository.apache.org/service/local/repositories/maven-XXX/content/. But can't remember what XXX it was as I've got ~10 in my settings.xml commented out. John On Mon, 26 Oct 2020 at 10:53, Markus Karg wrote: > > When I am using this plugin > https://maven.apache.org/plugins/maven-wrapper-plugin/ then Maven fails > because it apparently cannot find needed runtime files on Maven Central. This > limitation is not told on that page. Is that a bug or am I doing something > wrong? > -Markus > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Dependency Plugin
If you read the opening line it talks about Maven 3.7.0, which is not yet released. If you want to use a maven wrapper before v3.7.0, then use this https://github.com/takari/maven-wrapper. The upgrade from takari to maven is easy but does allow you to change your documentation, process and ci process instead of waiting until v3.7.0. I did test the maven-wrapper-plugin a few months ago and I had to add a staging repo of something like this before it worked https://repository.apache.org/service/local/repositories/maven-XXX/content/. But can't remember what XXX it was as I've got ~10 in my settings.xml commented out. John On Mon, 26 Oct 2020 at 10:53, Markus Karg wrote: > > When I am using this plugin > https://maven.apache.org/plugins/maven-wrapper-plugin/ then Maven fails > because it apparently cannot find needed runtime files on Maven Central. This > limitation is not told on that page. Is that a bug or am I doing something > wrong? > -Markus > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven Dependency Plugin
When I am using this plugin https://maven.apache.org/plugins/maven-wrapper-plugin/ then Maven fails because it apparently cannot find needed runtime files on Maven Central. This limitation is not told on that page. Is that a bug or am I doing something wrong? -Markus
Re: [Maven Dependency Plugin] usedDependency vs. ignoredUnusedDeclaredDependencies
FYI, I have just answered your SO question: https://stackoverflow.com/a/63894653/1082681 -- Alexander Kriegisch https://scrum-master.de Shelley Baker schrieb am 14.09.2020 20:54 (GMT +07:00): > I've also posted this question on Stack Overflow: > > https://stackoverflow.com/questions/63885408/maven-dependency-plugin-useddependency-vs-ignoredunuseddeclareddependencies > > On 2020/09/02 15:09:43, Shelley wrote: >> What is the difference between the maven-dependency-plugin's >> *ignoredUnusedDeclaredDependencies* [1] and *usedDependencies *[2]? >> >> I have several runtime/test-runtime dependencies that are flagged by the >> plugin as unused and declared and would like to ignore them. Both of these >> parameters seem to accomplish this, so I'd like some clarification as to >> what the difference is between them, and which to use when. >> >> [1] >> https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredUnusedDeclaredDependencies >> [2] >> https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#usedDependencies - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Maven Dependency Plugin] usedDependency vs. ignoredUnusedDeclaredDependencies
I've also posted this question on Stack Overflow: https://stackoverflow.com/questions/63885408/maven-dependency-plugin-useddependency-vs-ignoredunuseddeclareddependencies On 2020/09/02 15:09:43, Shelley wrote: > What is the difference between the maven-dependency-plugin's > *ignoredUnusedDeclaredDependencies* [1] and *usedDependencies *[2]? > > I have several runtime/test-runtime dependencies that are flagged by the > plugin as unused and declared and would like to ignore them. Both of these > parameters seem to accomplish this, so I'd like some clarification as to > what the difference is between them, and which to use when. > > [1] > https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredUnusedDeclaredDependencies > [2] > https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#usedDependencies > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[Maven Dependency Plugin] usedDependency vs. ignoredUnusedDeclaredDependencies
What is the difference between the maven-dependency-plugin's *ignoredUnusedDeclaredDependencies* [1] and *usedDependencies *[2]? I have several runtime/test-runtime dependencies that are flagged by the plugin as unused and declared and would like to ignore them. Both of these parameters seem to accomplish this, so I'd like some clarification as to what the difference is between them, and which to use when. [1] https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredUnusedDeclaredDependencies [2] https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#usedDependencies
Dependency plugin unpack plugin dependencies
Hi all, I currently have a setup in which I have some custom artifacts that I use as dependencies and unpack using unpack-dependencies. This all works great, but now I also have a custom plugin which needs one of the custom artifacts as dependency. I don't see those dependencies being unpacked. Is this correct, or am I doing something wrong? I know I can add the dependency as "regular" dependency as workaround, but I'd like to be able to define the plugin in a parent's pluginManagement with it's dependencies so that dependant project can enable the plugin when needed without having to define the dependency, or always have it being unpacked even if not needed. Basically my pom looks like this (meta): // Those are unpacked as expected // Those dependencies are not unpacked -- Met vriendelijke groet, Alexander Broekhuis
Re: maven-dependency-plugin:3.1.2:unpack not invoked, then does not unpack specified dependencies
reopening the bash made it work, didn't understand why - thanks anyway all the best, -Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Jul 14, 2020 at 2:14 PM Simone Tripodi wrote: > > Hi all mates, > I configured maven-dependency-plugin in my pom.xml in order to unpack > an artifact, the issue is that the plugin is not hit in any way; > follows below my pom snippet: > > > > > org.apache.maven.plugins > maven-dependency-plugin > 3.1.2 > > > unpack > package > > unpack > > > > > > org.monkeyvoice > monkey-tables > 2.5.0-SNAPSHOT > jar > true > > ${project.build.directory}/monkey-tables > **/*.hbm.xml > > > ${project.build.directory}/unpacked-dependencies > true > > > ... > > then follow below the list of invoked plugins: > > [INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @ > MonkeyVoiceRESTfulWS --- > [INFO] --- buildnumber-maven-plugin:1.4:create (default) @ > MonkeyVoiceRESTfulWS --- > [INFO] --- maven-resources-plugin:3.1.0:resources (default-resources) > @ MonkeyVoiceRESTfulWS --- > [INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ > MonkeyVoiceRESTfulWS -- > [INFO] --- animal-sniffer-maven-plugin:1.18:check (animal-sniffer) @ > MonkeyVoiceRESTfulWS --- > [INFO] --- maven-resources-plugin:3.1.0:testResources > (default-testResources) @ MonkeyVoiceRESTfulWS --- > [INFO] --- maven-compiler-plugin:3.8.1:testCompile > (default-testCompile) @ MonkeyVoiceRESTfulWS --- > [INFO] --- maven-surefire-plugin:2.22.2:test (default-test) @ > MonkeyVoiceRESTfulWS --- > [INFO] --- maven-war-plugin:3.2.3:war (default-war) @ MonkeyVoiceRESTfulWS --- > [INFO] --- maven-source-plugin:3.2.1:jar-no-fork (attach-sources) @ > MonkeyVoiceRESTfulWS --- > [INFO] --- maven-javadoc-plugin:3.2.0:jar (attach-javadocs) @ > MonkeyVoiceRESTfulWS --- > > As you can see, there's no maven-dependency-plugin invocation, this is > my development env: > > $ mvn --version > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: /usr/lib/maven/apache-maven-3.6.3 > Java version: 13.0.2, vendor: Oracle Corporation, runtime: > /usr/lib/jvm/jdk-13.0.2 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "5.3.0-59-generic", arch: "amd64", family: "unix" > > What I am doing wrong? > Many thanks in advance and all the best! > -Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-dependency-plugin:3.1.2:unpack not invoked, then does not unpack specified dependencies
Hi all mates, I configured maven-dependency-plugin in my pom.xml in order to unpack an artifact, the issue is that the plugin is not hit in any way; follows below my pom snippet: org.apache.maven.plugins maven-dependency-plugin 3.1.2 unpack package unpack org.monkeyvoice monkey-tables 2.5.0-SNAPSHOT jar true ${project.build.directory}/monkey-tables **/*.hbm.xml ${project.build.directory}/unpacked-dependencies true ... then follow below the list of invoked plugins: [INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @ MonkeyVoiceRESTfulWS --- [INFO] --- buildnumber-maven-plugin:1.4:create (default) @ MonkeyVoiceRESTfulWS --- [INFO] --- maven-resources-plugin:3.1.0:resources (default-resources) @ MonkeyVoiceRESTfulWS --- [INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ MonkeyVoiceRESTfulWS -- [INFO] --- animal-sniffer-maven-plugin:1.18:check (animal-sniffer) @ MonkeyVoiceRESTfulWS --- [INFO] --- maven-resources-plugin:3.1.0:testResources (default-testResources) @ MonkeyVoiceRESTfulWS --- [INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ MonkeyVoiceRESTfulWS --- [INFO] --- maven-surefire-plugin:2.22.2:test (default-test) @ MonkeyVoiceRESTfulWS --- [INFO] --- maven-war-plugin:3.2.3:war (default-war) @ MonkeyVoiceRESTfulWS --- [INFO] --- maven-source-plugin:3.2.1:jar-no-fork (attach-sources) @ MonkeyVoiceRESTfulWS --- [INFO] --- maven-javadoc-plugin:3.2.0:jar (attach-javadocs) @ MonkeyVoiceRESTfulWS --- As you can see, there's no maven-dependency-plugin invocation, this is my development env: $ mvn --version Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: /usr/lib/maven/apache-maven-3.6.3 Java version: 13.0.2, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-13.0.2 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.3.0-59-generic", arch: "amd64", family: "unix" What I am doing wrong? Many thanks in advance and all the best! -Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Javadoc aggregate fails with MDEP-187 with dependency plugin
Thanks i'll give it a shot. if it doesn't work, I'll comes up with an example project and share it on githubl On Tue, Jun 2, 2020 at 10:39 PM Olivier Lamy wrote: > Hi > what are the prepareGoals/goals of the release plugin? > maybe you could use package javadoc:aggregate-jar deploy > I know this will trigger few times the same lifecycle/goals and will add > few times the same jar to the artifacts to deploy but it should work. > > On Mon, 1 Jun 2020 at 22:33, Alex O'Ree wrote: > > > I'm attempting to, with a release profile, build javadoc jars for all > > modules in my project and generate a single aggregate javadoc jar for the > > whole project, preferable with just running 'mvn -PmyReleaseProfile > > install'. Is this possible? > > > > In my case i have a few modules that use the dependency plugin to copy > > dependencies to a specific location. This seems to interfer with the > > javadoc aggregate setup.I've attempted this a few times and keep getting > > the MDEP-187 error message. Removing the aggregate javadoc jar setup > > resolves the issue. > > > > Any suggestions on how to resolve this? > > > > using maven-dependency-plugin 3.0.0 and maven-javadoc-plugin 3.2.0 > > > > > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy >
Re: Javadoc aggregate fails with MDEP-187 with dependency plugin
Hi what are the prepareGoals/goals of the release plugin? maybe you could use package javadoc:aggregate-jar deploy I know this will trigger few times the same lifecycle/goals and will add few times the same jar to the artifacts to deploy but it should work. On Mon, 1 Jun 2020 at 22:33, Alex O'Ree wrote: > I'm attempting to, with a release profile, build javadoc jars for all > modules in my project and generate a single aggregate javadoc jar for the > whole project, preferable with just running 'mvn -PmyReleaseProfile > install'. Is this possible? > > In my case i have a few modules that use the dependency plugin to copy > dependencies to a specific location. This seems to interfer with the > javadoc aggregate setup.I've attempted this a few times and keep getting > the MDEP-187 error message. Removing the aggregate javadoc jar setup > resolves the issue. > > Any suggestions on how to resolve this? > > using maven-dependency-plugin 3.0.0 and maven-javadoc-plugin 3.2.0 > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Javadoc aggregate fails with MDEP-187 with dependency plugin
I'm attempting to, with a release profile, build javadoc jars for all modules in my project and generate a single aggregate javadoc jar for the whole project, preferable with just running 'mvn -PmyReleaseProfile install'. Is this possible? In my case i have a few modules that use the dependency plugin to copy dependencies to a specific location. This seems to interfer with the javadoc aggregate setup.I've attempted this a few times and keep getting the MDEP-187 error message. Removing the aggregate javadoc jar setup resolves the issue. Any suggestions on how to resolve this? using maven-dependency-plugin 3.0.0 and maven-javadoc-plugin 3.2.0
mvn site vs an unusual maven-dependency-plugin configuration
I've been struggling with this problem on and off for a while and have been unable to resolve this. Hopefully someone can provide some guidance. This is a multi-module project. I have a jar project that needs some native libraries in a specific path during the unit tests. To make this happen, I declare the dependency (it's a zip file in central), then use the maven-dependency-plugin (unpack-dependencies goal) to copy the dependencies to the target folder using the phase "compile". I've tried other phases but this is the only one that i tried whereby this works. Then 'copy-dependencies' goal, again with the compile phase. Next i call the maven-resources-plugin with the phase "generate-test-resources" to shuffle some of the files around (from the target/dependency folder to the target folder). I also call maven-ant-plugin with the "compile" phase to unzip the zip file and move some other files around. All of this works correctly, unit tests fire off without an issue. Enter maven site (currently running 3.6 but i can try other versions if needed). When running mvn site from the parent project directory, it always fails (references MDEP-187) with this configuration. The specific message is: Failed to get report for maven-javadoc-plugin: failed to execute goal ...maven-dependency-plugin:3.0.0:copy-dependencies on project...artifact has not been packaged yet. When used on a reactor artifact, copy should be executed after packaging. see MDEP-187 If I change the phases for copy-dependencies to the "prepare-package" phase. While this resolves the maven site issue, this causes the regular build with tests to fail. However this is only when building mvn site from the parent pom. When running mvn site in the directory for this specific module works fine. I tried adding both the site and javadoc plugin to the module's pom with skip=true, however this problem still comes up when running mvn site from the parent module. I'm out of ideas, can anyone help?
Problems with dependency-plugin + Mockito + Java 11
Hi, I'm wondering if anyone else has found a solution to this problem. I use the maven-dependency-plugin's analyze-only goal to look issues in my dependency tree. https://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html When I started using Java 11, I had to override the plugin's ASM dependency so that it would continue to work: org.ow2.asm asm 7.0 And everything did work, until I started using Mockito in my unit tests. As soon as I add calls to Mockito, I get the following error message: Execution dependency-plugin of goal org.apache.maven.plugins:maven-dependency-plugin:3.1.1:analyze-only failed: This feature requires ASM7 Of course, I'm already using ASM7. I've tried setting true to see if I can skip analysis of the test classes, but this doesn't seem to work. Thanks, Andrew Todd
Re: Repository authentication when directly invoking dependency plugin
Hello. Right, somebody answered my SO as well, suggesting that. However, I am not even using pom.xml, I am providing the repository definition directly into the plugin, as a property (from the command line), and there is no "current" pom.xml file. Is there a reason why the authentication settings are not applied to repositories defined in "remoteRepositories" property passed to the plugin? Also, you can have repositories defined in pom.xml, using top-level tag, aren't they used for downloading? The publishing ones are inside , AFAIU, that's different. Thank you. On Tue, Nov 20, 2018 at 3:37 PM Neeraj Mahajan wrote: > > Hi Pawel, > > The repositories defined in pom.xml is used for uploading artifacts. > However in order to download artifacts from the same repository you need to > add the repository to the profile section of settings.xml. > > Hope this helps. > > Kind Regards, > Neeraj Mahajan > > On Tue, Nov 20, 2018 at 12:59 PM Pawel Veselov > wrote: > > > Hello. > > > > I have a private Maven repository. It's defined in pom.xml of the project > > > > > > some.id > > https://some.host/artifactory/some.id > > > > > > In my ~/.m2/settings.xml, I have a proper authentication block: > > > > > > some.id > > pawel.vese...@domain.com > > {some-fancy-password-hash-goes-here} > > > > > > When building the project, Maven is able to access the repository > > without any problems, as it's supposed to be. In debugging output, I > > can see it applying the credentials. > > > > But when I try to download an artifact directly, it doesn't look like > > Maven is even considering the settings file. > > > > mvn org.apache.maven.plugins:maven-dependency-plugin:3.1.1:get \ > > -DremoteRepositories=some.idhttps://some.host/artifactory/some.id \ > > -Dartifact=groupId:artifactId:1.1.1 > > > > The username is not transmitted. I can see in the debug output, that > > the BasicRepositoryConnector is invoked without username/password > > combination. > > > > So the question goes - can a plugin be invoked so that whatever > > process makes Maven consider using the authentication stated in its > > settings file is executed? Am I missing something, is there a bug, or > > this is the intended behavior? > > > > (Note, this was posted as https://stackoverflow.com/q/53384757/622266) > > > > Thank you! > > -- Pawel. > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > -- With best of best regards Pawel S. Veselov - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Repository authentication when directly invoking dependency plugin
Hi Pawel, The repositories defined in pom.xml is used for uploading artifacts. However in order to download artifacts from the same repository you need to add the repository to the profile section of settings.xml. Hope this helps. Kind Regards, Neeraj Mahajan On Tue, Nov 20, 2018 at 12:59 PM Pawel Veselov wrote: > Hello. > > I have a private Maven repository. It's defined in pom.xml of the project > > > some.id > https://some.host/artifactory/some.id > > > In my ~/.m2/settings.xml, I have a proper authentication block: > > > some.id > pawel.vese...@domain.com > {some-fancy-password-hash-goes-here} > > > When building the project, Maven is able to access the repository > without any problems, as it's supposed to be. In debugging output, I > can see it applying the credentials. > > But when I try to download an artifact directly, it doesn't look like > Maven is even considering the settings file. > > mvn org.apache.maven.plugins:maven-dependency-plugin:3.1.1:get \ > -DremoteRepositories=some.idhttps://some.host/artifactory/some.id \ > -Dartifact=groupId:artifactId:1.1.1 > > The username is not transmitted. I can see in the debug output, that > the BasicRepositoryConnector is invoked without username/password > combination. > > So the question goes - can a plugin be invoked so that whatever > process makes Maven consider using the authentication stated in its > settings file is executed? Am I missing something, is there a bug, or > this is the intended behavior? > > (Note, this was posted as https://stackoverflow.com/q/53384757/622266) > > Thank you! > -- Pawel. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Repository authentication when directly invoking dependency plugin
Hello. I have a private Maven repository. It's defined in pom.xml of the project some.id https://some.host/artifactory/some.id In my ~/.m2/settings.xml, I have a proper authentication block: some.id pawel.vese...@domain.com {some-fancy-password-hash-goes-here} When building the project, Maven is able to access the repository without any problems, as it's supposed to be. In debugging output, I can see it applying the credentials. But when I try to download an artifact directly, it doesn't look like Maven is even considering the settings file. mvn org.apache.maven.plugins:maven-dependency-plugin:3.1.1:get \ -DremoteRepositories=some.idhttps://some.host/artifactory/some.id \ -Dartifact=groupId:artifactId:1.1.1 The username is not transmitted. I can see in the debug output, that the BasicRepositoryConnector is invoked without username/password combination. So the question goes - can a plugin be invoked so that whatever process makes Maven consider using the authentication stated in its settings file is executed? Am I missing something, is there a bug, or this is the intended behavior? (Note, this was posted as https://stackoverflow.com/q/53384757/622266) Thank you! -- Pawel. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Dependency Plugin Version 3.1.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Dependency Plugin Version 3.1.1 https://maven.apache.org/plugins/maven-dependency-plugin/ Important Note since 3.1.1: * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.1.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-dependency-plugin/download.cgi Release Notes Maven Dependency Plugin 3.1.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227&version=12343248 Bug: * [MDEP-607] - maven-dependency-plugin:3.1.0:analyze failed.: NullPointerException Dependency upgrades: * [MDEP-611] - Upgrade plexus-archiver to 3.6.0 * [MDEP-612] - Upgrade maven-dependency-analyzer to 1.10 * [MDEP-614] - Upgrade file-management to 3.0.0 Many thanks to all reporters/contributors/testers of this release. Reporters: * MDEP-607: Filipe Sousa Enjos, - The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Dependency Plugin Version 3.1.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Dependency Plugin Version 3.1.0 https://maven.apache.org/plugins/maven-dependency-plugin/ Important Note since 3.1.0: * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.1.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-dependency-plugin/download.cgi Release Notes Maven Dependency Plugin 3.1.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227&version=12341595 Bugs: * [MDEP-559] - Java 9 bytecode cannot be parsed * [MDEP-603] - dependency:analyze fails on JDK 9 / JDK 10 Improvement: * [MDEP-605] - Add documentation information for GitHub Dependency upgrades: * [MDEP-584] - Upgrade plexus-utils to version 3.1.0 * [MDEP-585] - Upgrade plexus-archiver to 3.5. * [MDEP-599] - Upgrade parent to 31 Many thanks to all reporters/contributors/testers of this release. Reporters: * MDEP-559: Ben Alex Testers: * Mark Raynsford Enjos, - The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Maven Dependency Plugin] Inheriting transitive dependencies whilst defining an artifact output directory
Hi Jörg, This is excellent and worked a treat. Thank you so much, for future reference, once the dependencies are declared with a , here is the correct plugin configuration solution org.apache.maven.plugins maven-dependency-plugin copy prepare-package copy-dependencies provided ${output.directory} Really clean and very useful. Thank you Lewis On 2018/02/23 23:05:42, Jörg Schaible wrote: > Hi, > > if you use the copy goal, you don't have to add them to your list of > dependencies. Personally I would use the > copy-dependencies goal and copy only the ones with scope provided (i.e. you > don't have to specify each one > again). > > Cheers, > Jörg > > > Am Fri, 23 Feb 2018 09:58:09 -0800 schrieb lewis john mcgibbney: > > > I should also say, that the workaround is to list each and every > > transitive dependency in the dependency declaration with scope > > 'provided', such that they are NOT on the normal runtime classpath but > > ARE correctly copied into the target directory defined within the > > maven-dependency-plugin configuration as shown above. > > The only issue with this workaround is that it is extremely messy, > > bloats my POM and is difficult to maintain as I have now introduced > > around 50 or so additional dependencies which all have versions, etc. > > Thanks again for any hints. > > Lewis > > > > On Fri, Feb 23, 2018 at 9:55 AM, lewis john mcgibbney > > wrote: > > > >> Hello users@, > >> I am looking to dynamically load JAR's during a program execution based > >> upon a users input and therefore using the maven-dependency-plugin to > >> do this. > >> Specifically, the plugin configuration looks as follows > >> > >> > >> org.apache.maven.plugins > >> maven-dependency-plugin > >> > >> > >> copy prepare-package > >> > >> copy > >> > >> > >> > >> > >> org.apache.any23.plugins > >> apache-any23-openie > >> ${project.version} > >> ${output.directory} > >> > >> ... > >> This works fine, however I have an issue with regards to these specific > >> JARs being present on the classpath during the build and runtime > >> depending on the I assign to them within the dependency > >> definition. > >> If I mark the scope as 'runtime', the dependencies are added to the > >> normal classpath which I do not want, as the purpose here is dynamic > >> classloading via user input. > >> On the other hand, if I define the dependency scope as 'provided' then > >> no transitive dependencies are acquired hence I encounter > >> java.lang.NoClassDefFoundError as although the primary dependency is > >> present, it's own dependencies are not. > >> > >> Does anyone have a way to get around this. Ideally I am looking for a > >> solution to define a specific location I was dependencies (and the > >> transitive dependencies) to reside such that I can load them > >> dynamically at runtime. > >> Thank you kindly in advance, > >> Lewis > >> > >> -- > >> http://home.apache.org/~lewismc/ > >> http://people.apache.org/keys/committer/lewismc > >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Maven Dependency Plugin] Inheriting transitive dependencies whilst defining an artifact output directory
Hi, if you use the copy goal, you don't have to add them to your list of dependencies. Personally I would use the copy-dependencies goal and copy only the ones with scope provided (i.e. you don't have to specify each one again). Cheers, Jörg Am Fri, 23 Feb 2018 09:58:09 -0800 schrieb lewis john mcgibbney: > I should also say, that the workaround is to list each and every > transitive dependency in the dependency declaration with scope > 'provided', such that they are NOT on the normal runtime classpath but > ARE correctly copied into the target directory defined within the > maven-dependency-plugin configuration as shown above. > The only issue with this workaround is that it is extremely messy, > bloats my POM and is difficult to maintain as I have now introduced > around 50 or so additional dependencies which all have versions, etc. > Thanks again for any hints. > Lewis > > On Fri, Feb 23, 2018 at 9:55 AM, lewis john mcgibbney > wrote: > >> Hello users@, >> I am looking to dynamically load JAR's during a program execution based >> upon a users input and therefore using the maven-dependency-plugin to >> do this. >> Specifically, the plugin configuration looks as follows >> >> >> org.apache.maven.plugins >> maven-dependency-plugin >> >> >> copy prepare-package >> >> copy >> >> >> >> >> org.apache.any23.plugins >> apache-any23-openie >> ${project.version} >> ${output.directory} >> >> ... >> This works fine, however I have an issue with regards to these specific >> JARs being present on the classpath during the build and runtime >> depending on the I assign to them within the dependency >> definition. >> If I mark the scope as 'runtime', the dependencies are added to the >> normal classpath which I do not want, as the purpose here is dynamic >> classloading via user input. >> On the other hand, if I define the dependency scope as 'provided' then >> no transitive dependencies are acquired hence I encounter >> java.lang.NoClassDefFoundError as although the primary dependency is >> present, it's own dependencies are not. >> >> Does anyone have a way to get around this. Ideally I am looking for a >> solution to define a specific location I was dependencies (and the >> transitive dependencies) to reside such that I can load them >> dynamically at runtime. >> Thank you kindly in advance, >> Lewis >> >> -- >> http://home.apache.org/~lewismc/ >> http://people.apache.org/keys/committer/lewismc >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Maven Dependency Plugin] Inheriting transitive dependencies whilst defining an artifact output directory
I should also say, that the workaround is to list each and every transitive dependency in the dependency declaration with scope 'provided', such that they are NOT on the normal runtime classpath but ARE correctly copied into the target directory defined within the maven-dependency-plugin configuration as shown above. The only issue with this workaround is that it is extremely messy, bloats my POM and is difficult to maintain as I have now introduced around 50 or so additional dependencies which all have versions, etc. Thanks again for any hints. Lewis On Fri, Feb 23, 2018 at 9:55 AM, lewis john mcgibbney wrote: > Hello users@, > I am looking to dynamically load JAR's during a program execution based > upon a users input and therefore using the maven-dependency-plugin to do > this. > Specifically, the plugin configuration looks as follows > > > org.apache.maven.plugins > maven-dependency-plugin > > > copy > prepare-package > > copy > > > > > org.apache.any23.plugins > apache-any23-openie > ${project.version} > ${output.directory} > > ... > This works fine, however I have an issue with regards to these specific > JARs being present on the classpath during the build and runtime depending > on the I assign to them within the dependency definition. > If I mark the scope as 'runtime', the dependencies are added to the normal > classpath which I do not want, as the purpose here is dynamic classloading > via user input. > On the other hand, if I define the dependency scope as 'provided' then no > transitive dependencies are acquired hence I encounter > java.lang.NoClassDefFoundError as although the primary dependency is > present, it's own dependencies are not. > > Does anyone have a way to get around this. Ideally I am looking for a > solution to define a specific location I was dependencies (and the > transitive dependencies) to reside such that I can load them dynamically at > runtime. > Thank you kindly in advance, > Lewis > > -- > http://home.apache.org/~lewismc/ > http://people.apache.org/keys/committer/lewismc > -- http://home.apache.org/~lewismc/ http://people.apache.org/keys/committer/lewismc
[Maven Dependency Plugin] Inheriting transitive dependencies whilst defining an artifact output directory
Hello users@, I am looking to dynamically load JAR's during a program execution based upon a users input and therefore using the maven-dependency-plugin to do this. Specifically, the plugin configuration looks as follows org.apache.maven.plugins maven-dependency-plugin copy prepare-package copy org.apache.any23.plugins apache-any23-openie ${project.version} ${output.directory} ... This works fine, however I have an issue with regards to these specific JARs being present on the classpath during the build and runtime depending on the I assign to them within the dependency definition. If I mark the scope as 'runtime', the dependencies are added to the normal classpath which I do not want, as the purpose here is dynamic classloading via user input. On the other hand, if I define the dependency scope as 'provided' then no transitive dependencies are acquired hence I encounter java.lang.NoClassDefFoundError as although the primary dependency is present, it's own dependencies are not. Does anyone have a way to get around this. Ideally I am looking for a solution to define a specific location I was dependencies (and the transitive dependencies) to reside such that I can load them dynamically at runtime. Thank you kindly in advance, Lewis -- http://home.apache.org/~lewismc/ http://people.apache.org/keys/committer/lewismc
[ANN] Apache Maven Dependency Plugin Version 3.0.2 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Dependency Plugin Version 3.0.2. https://maven.apache.org/plugins/maven-dependency-plugin/ Important Note since 3.0.0: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.0.2 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-dependency-plugin/download.cgi Release Notes Maven Dependency Plugin 3.0.2 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227&version=12338874 Bugs: * [MDEP-571] - JDK9: Issue with list goal fails with java.lang.NoSuchMethodException * [MDEP-573] - "purge-local-repository -Dinclude" does not work as described * [MDEP-577] - dependency:list doesn't show module name * [MDEP-583] - Failed to create release on JDK 8 based on JavaDoc issues Improvements: * [MDEP-578] - Add message in case module name cannot be extracted from jar. * [MDEP-580] - Recognize source of name for automatic modules Task: * [MDEP-581] - Downgrade maven-artifact-transfer to release version instead of SNAPSHOT Many thanks to all reporters/contributors/testers of this release. Enjos, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Dependency Plugin Version 3.0.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Dependency Plugin Version 3.0.1. https://maven.apache.org/plugins/maven-dependency-plugin/ Important Note since 3.0.0: * Maven 3.X only * JDK 6 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-dependency-plugin 3.0.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-dependency-plugin/download.cgi Release Notes Maven Dependency Plugin 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227&version=12338874 Bugs: * [MDEP-409] - dependency:tree fails for a multi-module project where one module depends on another and "mvn install" has not been run yet * [MDEP-419] - dependency:list, dependency:build-classpath and dependency:tree result with the different dependencies order * [MDEP-428] - Unpack goal does not fail build when destination could not be created and unpacks to current working directory instead * [MDEP-471] - Java 8 Method references are not detected * [MDEP-548] - The get Mojo doesn't resolve the artifact when setting transitive to false * [MDEP-565] - Upgrade maven-artifact-transfer to version 0.9.1 Documentation: * [MDEP-534] - Document format of mojo parameter 'artifact' Improvements: * [MDEP-482] - Can't use both outputProperty and outputFile in build-classpath mojo * [MDEP-563] - Print dependency:resolve-plugins output just like other goal output * [MDEP-566] - Upgrade maven-common-artifact-filter to version 3.0.1 * [MDEP-567] - Upgrade to maven-dependency-tree to 3.0.1 New Feature: * [MDEP-500] - Print GAV information in console output during dependency:resolve-plugins execution Task: * [MDEP-547] - Remove some old (404) links from site Reporters of this Release: * Elias Elmqvist Wulcan [MDEP-534] * Andrew Wright [MDEP-500] * Dagan Sandler [MDEP-482] * Ben Hardy [MDEP-471] * Dave Moten [MDEP-428] * Julien Boulay [MDEP-419] * Eric Pabst [MDEP-409] Many thanks to all reporters/contributors/testers of this release. Enjos, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-dependency-plugin skips unpack goal
I have another update on this...note I can't be 100% sure of my conclusions as it's somewhat random but here goes. clean install - succeeds -PciBuild clean install - fails -X -PciBuild clean install - succeeds at least some times However if I remove the aggregate-jar goal from ciBuild profile then it works. So what this tells me is that the usage of aggregate-jar goal breaks the maven-dependency-plugin in the sense that it no longer can know about all (it does know about some) project artifacts that were previously created by the reactor build via the maven-assembly-plugin. I think there are other triggers of the breakage too but aggregate-jar is the one that I can identify and is the most repeatable. Here are the versions I'm using: maven -> 3.3.9 maven-source-plugin -> 3.0.1 maven-javadoc-plugin -> 2.10.4 maven-assembly-plugin -> 2.6 or 3.0.0 maven-dependency-plugin -> 2.10 or 3.0.0 where ciBuild is defined as adding the following to the top level pom build configuration: org.apache.maven.plugins maven-source-plugin attach-sources jar org.apache.maven.plugins maven-javadoc-plugin attach-javadocs package ${jdk.version} false -Xdoclint:none jar attach-aggregate-jar package ${jdk.version} false -Xdoclint:none aggregate-jar This is a major bug that I'm hoping the Maven developers can quickly resolve. One expects to be able to combine various normal plugin usages and not have race conditions but here is a case that causes failures with no clue to the cause. Since I apparently can't use the aggregate-jar goal at all in this build is there a different way to get an aggregate javadoc jar? If I had a way to collect all the separate javadoc artifacts and put in zip that would probably suffice for now. -Dave On Mon, Jan 23, 2017 at 7:37 AM, David Hoffer wrote: > Regarding the reactor build order/issue okay/yes that is what we expected > that it builds each to the final phase. However if I step back and > describe what I see in the build behavior...I see that although each module > does build to final stage (e.g. expected generated artifacts are in target > folder) there is some race condition where the dependency plugin does not > think/know that an artifact was previously created. That explains what we > see in practice. And I say race condition because it sometimes works (e.g. > added -X and it worked once at least). I do think this is somehow related > to the use of the generate sources and/or javadocs which is specified at > the top level pom. You mentioned this causes it to fork I don't really > understand why that is. The forking sounds suspicious to me in that maybe > it is causing the race condition? Is there a way to turn forking off? > > It would be a major pain but I could move the generate sources and javadoc > jars configuration to each module but since over a hundred this is very > undesirable. Also how can I generate an aggregated javadoc anyway but at > the top level? If I had the aggregated one I might be able to do away with > the individual ones. I'm surprised generating sources and javadoc jars is > so problematic as it's standard to expect those will be generated for each > java binary jar. Can the specification of this generation be done in the > top level pluginManagment section instead of plugins to clearly indicate > our intent is for all child plugins to execute these goals not the parent? > (Except for the aggregated one...don't know how to do that except at the > top level...in plugins section. However maybe there is a different/better > way?) > > Back to your suggestions...it turns out I can't use package only...not > because of any build/reactor issue but because we have an OSGi installer > section in this build that uses a plugin to collect up all the OSGi > features.xml files. Those files are collected from the .m2 repo so install > has to be run. This is not where any problem is as this has been used for > at least 6 years this way with no issues. But unless I comment out these > parts I can't build with just package. I might also note we do use a > verify plugin that does guarantee that our build has no incorrect/missing > dependencies. > > -Dave > > > On Mon, Jan 23, 2017 at 12:02 AM, Karl Heinz Marbaise > wrote: > >> Hi David, >> >> On 23/01/17 00:54, David Hoffer wrote: >> >>> I will try all of
Re: maven-dependency-plugin skips unpack goal
Regarding the reactor build order/issue okay/yes that is what we expected that it builds each to the final phase. However if I step back and describe what I see in the build behavior...I see that although each module does build to final stage (e.g. expected generated artifacts are in target folder) there is some race condition where the dependency plugin does not think/know that an artifact was previously created. That explains what we see in practice. And I say race condition because it sometimes works (e.g. added -X and it worked once at least). I do think this is somehow related to the use of the generate sources and/or javadocs which is specified at the top level pom. You mentioned this causes it to fork I don't really understand why that is. The forking sounds suspicious to me in that maybe it is causing the race condition? Is there a way to turn forking off? It would be a major pain but I could move the generate sources and javadoc jars configuration to each module but since over a hundred this is very undesirable. Also how can I generate an aggregated javadoc anyway but at the top level? If I had the aggregated one I might be able to do away with the individual ones. I'm surprised generating sources and javadoc jars is so problematic as it's standard to expect those will be generated for each java binary jar. Can the specification of this generation be done in the top level pluginManagment section instead of plugins to clearly indicate our intent is for all child plugins to execute these goals not the parent? (Except for the aggregated one...don't know how to do that except at the top level...in plugins section. However maybe there is a different/better way?) Back to your suggestions...it turns out I can't use package only...not because of any build/reactor issue but because we have an OSGi installer section in this build that uses a plugin to collect up all the OSGi features.xml files. Those files are collected from the .m2 repo so install has to be run. This is not where any problem is as this has been used for at least 6 years this way with no issues. But unless I comment out these parts I can't build with just package. I might also note we do use a verify plugin that does guarantee that our build has no incorrect/missing dependencies. -Dave On Mon, Jan 23, 2017 at 12:02 AM, Karl Heinz Marbaise wrote: > Hi David, > > On 23/01/17 00:54, David Hoffer wrote: > >> I will try all of these things the best I can, see my comments inline >> below. >> >> In addition to my comments below I have a question about how Maven >> handles plugin phases in a multi module build. Once the reactor module >> build order is established does it build each module all the way to the >> final phase specified by the command line before it moves on to the next >> module? (E.g. is this guaranteed behavior?) Or does it build the same >> phase across all modules before it moves to the next phase? Or does it >> use some combination in some fashion? >> > > it must build every module to the final phase...and go them with the next > module... > > > >> -Dave >> >> On Sun, Jan 22, 2017 at 11:15 AM, Karl Heinz Marbaise > <mailto:khmarba...@gmx.de>> wrote: >> >> Hi David, >> >> the first thing I strongly recommend to make a build of your project >> where you first clean the local cache ($HOME/.m2/repository) >> completely and just run your build via: >> >> mvn package -DskipTests=true >> >> >> [dh] I don't trust package w/o also a clean so plan to add that is >> well. W/o the clean any prior partial build would remain in the target >> folder. Ultimately what needs to work is deploy as that is what the CI >> system will run after a fresh checkout in a clean working area. >> > > This was not a general hint to go with it was just a single task to see if > everything is right with your build...Of course you can add a clean call in > this case ... > > The intention here is to check if the reactor builds correct and if all > dependencies between the modules are correct... > > I know that you finally need to get working deploy...but first we should > see if something else is wrong... > > > > >> >> >> (No usage of install!).. >> >> >> [dh] I'm curious as to why no install? Wen we do our dev builds the >> standard practice is to run clean install. >> > > see my previous comments to check the dependencies between your modules... > > Just for a test build...you can do that just locally do a fresh checkout > and remove the content of your cache and then > try to run: mvn clean package -Dski
Re: maven-dependency-plugin skips unpack goal
true What comes to my mind is that if you generate sources packages this should be done in the appropriate package them selfs and not into a parent (but this depends sometimes)... [dh] That would seem to be unmanageable as you want all modules to have source/javadocs generated but don't want to have to repeat that in every module. So this is specified at the parent pom. However since a pom type it has no source so it doesn't generate anything for itself just its children. The only exception to this is we now also do generate aggregated javadoc jar for the entire project via the maven-javadoc-plugin aggregate-jar goal so this does run at the top level. I don't know of any other way to generate aggregated javadocs The problem with that is that the parent pom will run first before and child has been finished and furthermore the javadoc will fork the life cycle...(identified by "<<<" and ">>>" in the output... Furthermore I would suggest to test it several times without influence of Teamcity (cause it seemed to be having some kind of watcher running)..I had such issues in Jenkins a while ago (with the evil Mavne Job Type)... Can you run that build several times without the ciBuild profile ? [dh] Yes I can do this. In my prior experience it will happen less without the ciBuild and have no idea why. However we do need sources and javadocs so have to figure out how to build with those somehow. Yes I know but we need to drill down to the problem first... Furthermore it might be worth to check using the maven-remote-resources plugin for the parts which you are unpackaging into the appropriate packages...if it's only related to single files etc. ? But I'm not sure... [dh] I'm not familiar with that plugin. I just took a quick look. It seems we do the same/similar thing using the maven-assembly-plugin. E.g. our standard practice is to generate artifacts for later consumption using the maven-assembly-plugin and then consume with maven-dependency-plugin. Is this not a valid way to handle this? The assembly is one option...the remote resources plugin packs things and will be executed in the generate-resources phase by default and put the files you need into appropriate directories...which is sometimes less configureation...but first we should drill down to your problem before we change anything... Just some thoughts about...without really seeing the build and the complete poms etc. Kind regards Karl Heinz Marbaise On 22/01/17 17:58, David Hoffer wrote: Any input on this? This is killing us right now...we don't have a way to get past this and builds are failing. We have no idea what to try to fix this. Any input is greatly appreciated. -Dave On Sat, Jan 21, 2017 at 7:18 AM, David Hoffer mailto:dhoff...@gmail.com>> wrote: Maven home: C:\Programs\Apache\Maven\apache-maven-3.3.9 Java version: 1.8.0_102, vendor: Oracle Corporation Java home: C:\Programs\Java\jdk1.8.0_102\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" Command line: mvn clean install -PciBuild -DskipTests=true We are not using the -T option. The JMS: Parent (POM) is the top level pom and it is a regular pom, the reason that it took 22 minutes is that the ciBuild profile was enabled. This profile just turns on generating sources and javadoc jars for the project, it also creates an uber javadoc jar using the aggregate-jar goal. As I previously mentioned it does seem that generating the sources and javadoc jars aggravates this issue so it occurs more often and right now its failing almost all the time. If I remove the source and javadoc jar generation it will fail the same way but generally not as often. -Dave On Sat, Jan 21, 2017 at 3:38 AM, Karl Heinz Marbaise mailto:khmarba...@gmx.de>> wrote: Hi, how is Maven called ? Which Maven Version do you use? Are you using "-T" option? What looks a little bit strnage to me is that a parent: "[00:34:50] : [Step 2/3] [INFO] JMS: Parent (POM) .. SUCCESS [22:08 min]" shows a time of 22 minutes ? Is this really a pom or is the .. saying something different than the pom
Re: maven-dependency-plugin skips unpack goal
ning)..I had > such issues in Jenkins a while ago (with the evil Mavne Job Type)... > > Can you run that build several times without the ciBuild profile ? > [dh] Yes I can do this. In my prior experience it will happen less without the ciBuild and have no idea why. However we do need sources and javadocs so have to figure out how to build with those somehow. > > > > Furthermore it might be worth to check using the maven-remote-resources > plugin for the parts which you are unpackaging into the appropriate > packages...if it's only related to single files etc. ? But I'm not sure... > [dh] I'm not familiar with that plugin. I just took a quick look. It seems we do the same/similar thing using the maven-assembly-plugin. E.g. our standard practice is to generate artifacts for later consumption using the maven-assembly-plugin and then consume with maven-dependency-plugin. Is this not a valid way to handle this? > > Just some thoughts about...without really seeing the build and the > complete poms etc. > > Kind regards > Karl Heinz Marbaise > > On 22/01/17 17:58, David Hoffer wrote: > >> Any input on this? This is killing us right now...we don't have a way to >> get past this and builds are failing. We have no idea what to try to fix >> this. >> >> Any input is greatly appreciated. >> >> -Dave >> >> On Sat, Jan 21, 2017 at 7:18 AM, David Hoffer wrote: >> >> Maven home: C:\Programs\Apache\Maven\apache-maven-3.3.9 >>> Java version: 1.8.0_102, vendor: Oracle Corporation >>> Java home: C:\Programs\Java\jdk1.8.0_102\jre >>> Default locale: en_US, platform encoding: Cp1252 >>> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >>> >>> Command line: mvn clean install -PciBuild -DskipTests=true >>> >>> We are not using the -T option. >>> >>> The JMS: Parent (POM) is the top level pom and it is a regular pom, the >>> reason that it took 22 minutes is that the ciBuild profile was enabled. >>> This profile just turns on generating sources and javadoc jars for the >>> project, it also creates an uber javadoc jar using the aggregate-jar >>> goal. >>> As I previously mentioned it does seem that generating the sources and >>> javadoc jars aggravates this issue so it occurs more often and right now >>> its failing almost all the time. If I remove the source and javadoc jar >>> generation it will fail the same way but generally not as often. >>> >>> -Dave >>> >>> >>> On Sat, Jan 21, 2017 at 3:38 AM, Karl Heinz Marbaise >>> wrote: >>> >>> Hi, >>>> >>>> how is Maven called ? Which Maven Version do you use? Are you using "-T" >>>> option? >>>> >>>> What looks a little bit strnage to me is that a parent: >>>> >>>> "[00:34:50] : [Step 2/3] [INFO] JMS: Parent (POM) >>>> .. SUCCESS [22:08 min]" >>>> >>>> shows a time of 22 minutes ? Is this really a pom or is the >>>> .. saying something different than the pom itself (so >>>> packaging different than pom?): >>>> >>>> >>>> Kind regards >>>> Karl Heinz >>>> >>>> >>>> On 20/01/17 17:46, David Hoffer wrote: >>>> >>>> Here is some build and log messages when run in normal mode...I will get >>>>> debug logs. Note it's the unpack-JMS-WS-Eventing step that is skipped >>>>> below...so the expected file is not found. >>>>> >>>>> [00:34:49] :[Step 2/3] [INFO] >>>>> >>>>> [00:34:49] :[Step 2/3] [INFO] >>>>> >>>>> >>>>> [00:34:49] :[Step 2/3] [INFO] Building JMS JAX-WS: Bullpen JAX-WS (JAR) >>>>> 11.x-SNAPSHOT >>>>> [00:34:49] :[Step 2/3] [INFO] >>>>> >>>>> >>>>> [00:34:49] :[Step 2/3] [Maven Watcher] project started: >>>>> com.issinc.jms.jax.ws.resources:bullpen-jax-ws:jar:11.x-SNAPSHOT >>>>> [00:34:49] :[Step 2/3] [Maven Watcher] >>>>> [00:34:49]i:[Step 2/3] ##teamcity[projectStarted tc:tags='tc:internal' >>>>> projectId='com.issinc.jms.jax.ws.resources:bullpen-jax-ws:ja >>>>> r:11.x-SNAPSHOT' >>
Re: maven-dependency-plugin skips unpack goal
s-resources/b ullpen-jax-ws/target/surefire-reports'] [00:34:49]E:[Step 2/3] com.issinc.jms.jax.ws.resources:bullpen-jax-ws [00:34:49]i:[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] ##teamcity[importData tc:tags='tc:internal' type='surefire' path='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax- ws/target/failsafe-reports/TEST-*.xml' whenNoDataPublished='nothing' logAsInternal='true'] [00:34:49]i:[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] ##teamcity[importData tc:tags='tc:internal' type='surefire' path='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax- ws/target/surefire-reports/TEST-*.xml' whenNoDataPublished='nothing' logAsInternal='true'] [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing data from 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/ta rget/failsafe-reports/TEST-*.xml' (not existing file) with 'surefire' processor [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing data from 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/ta rget/surefire-reports/TEST-*.xml' (not existing file) with 'surefire' processor [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- properties-maven-plugin:1.0-alpha-2:set-system-properties (set-additional-system-properties) @ bullpen-jax-ws --- [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Set 3 system properties [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-dependency-plugin:3.0.0:unpack-dependencies (unpack-bullpen-msg) @ bullpen-jax-ws --- [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-dependency-plugin:3.0.0:unpack-dependencies (unpack-JMS-WS-Eventing) @ bullpen-jax-ws --- [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-replacer-plugin:1.4.1:replace (replace-elements-import) @ bullpen-jax-ws --- [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Surefire report watcher [00:34:50] :[Surefire report watcher] Watching paths: [00:34:50] :[Surefire report watcher] F:\work\5c4a237177bf7a76\jax-ws-resources\bullpen-jax-ws\tar get\failsafe-reports\TEST-*.xml [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Surefire report watcher [00:34:50] :[Surefire report watcher] Watching paths: [00:34:50] :[Surefire report watcher] F:\work\5c4a237177bf7a76\jax-ws-resources\bullpen-jax-ws\tar get\surefire-reports\TEST-*.xml [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Ignoring missing file [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Replacement run on 0 file. [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-replacer-plugin:1.4.1:replace (replace-elements-namespace) @ bullpen-jax-ws --- [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Ignoring missing file [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Replacement run on 0 file. [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-replacer-plugin:1.4.1:replace (replace-types-namespace) @ bullpen-jax-ws --- [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Ignoring missing file [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Replacement run on 0 file. [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- jaxws-maven-plugin:2.3:wsimport (bullpen-jax-ws-wsimport) @ bullpen-jax-ws --- [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [Maven Watcher] [00:34:50]E:[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Failed to execute goal org.jvnet.jax-ws-commons:jaxws-maven-plugin:2.3:wsimport (bullpen-jax-ws-wsimport) on project bullpen-jax-ws: 'F:\work\5c4a237177bf7a76\jax-ws-resources\bullpen-jax-ws\ta rget/wsdl/JMS-WS-Eventing/NotificationService.wsdl' not found. [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [Maven Watcher] [00:34:50]i:[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] ##teamcity[projectFinished tc:tags='tc:internal' projectId='com.issinc.jms.jax.ws.resources:bullpen-jax-ws:ja r:11.x-SNAPSHOT'] [00:34:50] :[Step 2/3] [INFO] [00:34:50] :[Step 2/3] [INFO] Reactor Summary: [00:34:50] :[Step 2/3] [INFO] [00:34:50] :[Step 2/3] [INFO] JMS: Parent (POM) ...
Re: maven-dependency-plugin skips unpack goal
Any input on this? This is killing us right now...we don't have a way to get past this and builds are failing. We have no idea what to try to fix this. Any input is greatly appreciated. -Dave On Sat, Jan 21, 2017 at 7:18 AM, David Hoffer wrote: > Maven home: C:\Programs\Apache\Maven\apache-maven-3.3.9 > Java version: 1.8.0_102, vendor: Oracle Corporation > Java home: C:\Programs\Java\jdk1.8.0_102\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" > > Command line: mvn clean install -PciBuild -DskipTests=true > > We are not using the -T option. > > The JMS: Parent (POM) is the top level pom and it is a regular pom, the > reason that it took 22 minutes is that the ciBuild profile was enabled. > This profile just turns on generating sources and javadoc jars for the > project, it also creates an uber javadoc jar using the aggregate-jar goal. > As I previously mentioned it does seem that generating the sources and > javadoc jars aggravates this issue so it occurs more often and right now > its failing almost all the time. If I remove the source and javadoc jar > generation it will fail the same way but generally not as often. > > -Dave > > > On Sat, Jan 21, 2017 at 3:38 AM, Karl Heinz Marbaise > wrote: > >> Hi, >> >> how is Maven called ? Which Maven Version do you use? Are you using "-T" >> option? >> >> What looks a little bit strnage to me is that a parent: >> >> "[00:34:50] : [Step 2/3] [INFO] JMS: Parent (POM) >> .. SUCCESS [22:08 min]" >> >> shows a time of 22 minutes ? Is this really a pom or is the >> .. saying something different than the pom itself (so >> packaging different than pom?): >> >> >> Kind regards >> Karl Heinz >> >> >> On 20/01/17 17:46, David Hoffer wrote: >> >>> Here is some build and log messages when run in normal mode...I will get >>> debug logs. Note it's the unpack-JMS-WS-Eventing step that is skipped >>> below...so the expected file is not found. >>> >>> [00:34:49] :[Step 2/3] [INFO] >>> >>> [00:34:49] :[Step 2/3] [INFO] >>> >>> [00:34:49] :[Step 2/3] [INFO] Building JMS JAX-WS: Bullpen JAX-WS (JAR) >>> 11.x-SNAPSHOT >>> [00:34:49] :[Step 2/3] [INFO] >>> >>> [00:34:49] :[Step 2/3] [Maven Watcher] project started: >>> com.issinc.jms.jax.ws.resources:bullpen-jax-ws:jar:11.x-SNAPSHOT >>> [00:34:49] :[Step 2/3] [Maven Watcher] >>> [00:34:49]i:[Step 2/3] ##teamcity[projectStarted tc:tags='tc:internal' >>> projectId='com.issinc.jms.jax.ws.resources:bullpen-jax-ws:ja >>> r:11.x-SNAPSHOT' >>> groupId='com.issinc.jms.jax.ws.resources' artifactId='bullpen-jax-ws' >>> testReportsDir0='F:/work/5c4a237177bf7a76/jax-ws-resources/b >>> ullpen-jax-ws/target/failsafe-reports' >>> testReportsDir1='F:/work/5c4a237177bf7a76/jax-ws-resources/b >>> ullpen-jax-ws/target/surefire-reports'] >>> [00:34:49]E:[Step 2/3] com.issinc.jms.jax.ws.resources:bullpen-jax-ws >>> [00:34:49]i:[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] >>> ##teamcity[importData tc:tags='tc:internal' type='surefire' >>> path='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax- >>> ws/target/failsafe-reports/TEST-*.xml' >>> whenNoDataPublished='nothing' logAsInternal='true'] >>> [00:34:49]i:[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] >>> ##teamcity[importData tc:tags='tc:internal' type='surefire' >>> path='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax- >>> ws/target/surefire-reports/TEST-*.xml' >>> whenNoDataPublished='nothing' logAsInternal='true'] >>> [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing >>> data from >>> 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/ta >>> rget/failsafe-reports/TEST-*.xml' >>> (not existing file) with 'surefire' processor >>> [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing >>> data from >>> 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/ta >>> rget/surefire-reports/TEST-*.xml' >>> (not existing file) with 'suref
Re: maven-dependency-plugin skips unpack goal
Maven home: C:\Programs\Apache\Maven\apache-maven-3.3.9 Java version: 1.8.0_102, vendor: Oracle Corporation Java home: C:\Programs\Java\jdk1.8.0_102\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" Command line: mvn clean install -PciBuild -DskipTests=true We are not using the -T option. The JMS: Parent (POM) is the top level pom and it is a regular pom, the reason that it took 22 minutes is that the ciBuild profile was enabled. This profile just turns on generating sources and javadoc jars for the project, it also creates an uber javadoc jar using the aggregate-jar goal. As I previously mentioned it does seem that generating the sources and javadoc jars aggravates this issue so it occurs more often and right now its failing almost all the time. If I remove the source and javadoc jar generation it will fail the same way but generally not as often. -Dave On Sat, Jan 21, 2017 at 3:38 AM, Karl Heinz Marbaise wrote: > Hi, > > how is Maven called ? Which Maven Version do you use? Are you using "-T" > option? > > What looks a little bit strnage to me is that a parent: > > "[00:34:50] : [Step 2/3] [INFO] JMS: Parent (POM) > .. SUCCESS [22:08 min]" > > shows a time of 22 minutes ? Is this really a pom or is the > .. saying something different than the pom itself (so > packaging different than pom?): > > > Kind regards > Karl Heinz > > > On 20/01/17 17:46, David Hoffer wrote: > >> Here is some build and log messages when run in normal mode...I will get >> debug logs. Note it's the unpack-JMS-WS-Eventing step that is skipped >> below...so the expected file is not found. >> >> [00:34:49] :[Step 2/3] [INFO] >> >> [00:34:49] :[Step 2/3] [INFO] >> >> [00:34:49] :[Step 2/3] [INFO] Building JMS JAX-WS: Bullpen JAX-WS (JAR) >> 11.x-SNAPSHOT >> [00:34:49] :[Step 2/3] [INFO] >> >> [00:34:49] :[Step 2/3] [Maven Watcher] project started: >> com.issinc.jms.jax.ws.resources:bullpen-jax-ws:jar:11.x-SNAPSHOT >> [00:34:49] :[Step 2/3] [Maven Watcher] >> [00:34:49]i:[Step 2/3] ##teamcity[projectStarted tc:tags='tc:internal' >> projectId='com.issinc.jms.jax.ws.resources:bullpen-jax-ws:ja >> r:11.x-SNAPSHOT' >> groupId='com.issinc.jms.jax.ws.resources' artifactId='bullpen-jax-ws' >> testReportsDir0='F:/work/5c4a237177bf7a76/jax-ws-resources/ >> bullpen-jax-ws/target/failsafe-reports' >> testReportsDir1='F:/work/5c4a237177bf7a76/jax-ws-resources/ >> bullpen-jax-ws/target/surefire-reports'] >> [00:34:49]E:[Step 2/3] com.issinc.jms.jax.ws.resources:bullpen-jax-ws >> [00:34:49]i:[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] >> ##teamcity[importData tc:tags='tc:internal' type='surefire' >> path='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax- >> ws/target/failsafe-reports/TEST-*.xml' >> whenNoDataPublished='nothing' logAsInternal='true'] >> [00:34:49]i:[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] >> ##teamcity[importData tc:tags='tc:internal' type='surefire' >> path='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax- >> ws/target/surefire-reports/TEST-*.xml' >> whenNoDataPublished='nothing' logAsInternal='true'] >> [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing >> data from >> 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/ta >> rget/failsafe-reports/TEST-*.xml' >> (not existing file) with 'surefire' processor >> [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing >> data from >> 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/ta >> rget/surefire-reports/TEST-*.xml' >> (not existing file) with 'surefire' processor >> [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] >> [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- >> properties-maven-plugin:1.0-alpha-2:set-system-properties >> (set-additional-system-properties) @ bullpen-jax-ws --- >> [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Set >> 3 system properties >> [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] >> [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- >> maven-dependency-plugin:3.0.0:unpack-dependenci
Re: maven-dependency-plugin skips unpack goal
Hi, how is Maven called ? Which Maven Version do you use? Are you using "-T" option? What looks a little bit strnage to me is that a parent: "[00:34:50] : [Step 2/3] [INFO] JMS: Parent (POM) .. SUCCESS [22:08 min]" shows a time of 22 minutes ? Is this really a pom or is the .. saying something different than the pom itself (so packaging different than pom?): Kind regards Karl Heinz On 20/01/17 17:46, David Hoffer wrote: Here is some build and log messages when run in normal mode...I will get debug logs. Note it's the unpack-JMS-WS-Eventing step that is skipped below...so the expected file is not found. [00:34:49] :[Step 2/3] [INFO] [00:34:49] :[Step 2/3] [INFO] [00:34:49] :[Step 2/3] [INFO] Building JMS JAX-WS: Bullpen JAX-WS (JAR) 11.x-SNAPSHOT [00:34:49] :[Step 2/3] [INFO] [00:34:49] :[Step 2/3] [Maven Watcher] project started: com.issinc.jms.jax.ws.resources:bullpen-jax-ws:jar:11.x-SNAPSHOT [00:34:49] :[Step 2/3] [Maven Watcher] [00:34:49]i:[Step 2/3] ##teamcity[projectStarted tc:tags='tc:internal' projectId='com.issinc.jms.jax.ws.resources:bullpen-jax-ws:jar:11.x-SNAPSHOT' groupId='com.issinc.jms.jax.ws.resources' artifactId='bullpen-jax-ws' testReportsDir0='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/target/failsafe-reports' testReportsDir1='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/target/surefire-reports'] [00:34:49]E:[Step 2/3] com.issinc.jms.jax.ws.resources:bullpen-jax-ws [00:34:49]i:[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] ##teamcity[importData tc:tags='tc:internal' type='surefire' path='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/target/failsafe-reports/TEST-*.xml' whenNoDataPublished='nothing' logAsInternal='true'] [00:34:49]i:[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] ##teamcity[importData tc:tags='tc:internal' type='surefire' path='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/target/surefire-reports/TEST-*.xml' whenNoDataPublished='nothing' logAsInternal='true'] [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing data from 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/target/failsafe-reports/TEST-*.xml' (not existing file) with 'surefire' processor [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing data from 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/target/surefire-reports/TEST-*.xml' (not existing file) with 'surefire' processor [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- properties-maven-plugin:1.0-alpha-2:set-system-properties (set-additional-system-properties) @ bullpen-jax-ws --- [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Set 3 system properties [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-dependency-plugin:3.0.0:unpack-dependencies (unpack-bullpen-msg) @ bullpen-jax-ws --- [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-dependency-plugin:3.0.0:unpack-dependencies (unpack-JMS-WS-Eventing) @ bullpen-jax-ws --- [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-replacer-plugin:1.4.1:replace (replace-elements-import) @ bullpen-jax-ws --- [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Surefire report watcher [00:34:50] :[Surefire report watcher] Watching paths: [00:34:50] :[Surefire report watcher] F:\work\5c4a237177bf7a76\jax-ws-resources\bullpen-jax-ws\target\failsafe-reports\TEST-*.xml [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Surefire report watcher [00:34:50] :[Surefire report watcher] Watching paths: [00:34:50] :[Surefire report watcher] F:\work\5c4a237177bf7a76\jax-ws-resources\bullpen-jax-ws\target\surefire-reports\TEST-*.xml [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Ignoring missing file [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Replacement run on 0 file. [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-replacer-plugin:1.4.1:replace (replace-elements-namespace) @ bullpen-jax-ws --- [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Ignoring missing file [00:34:50] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Replacement r
Re: maven-dependency-plugin skips unpack goal
Okay I finally have debug build log information. Note this is for the two unpack-dependencies. The first finds and unpacks, the second does not. Note there are no errors here as the error is later when the missing file is referenced. Let me know if any other debug log info is needed. [INFO] --- maven-dependency-plugin:3.0.0:unpack-dependencies (unpack-bullpen-msg) @ bullpen-jax-ws --- [DEBUG] Configuring mojo org.apache.maven.plugins:maven-dependency-plugin:3.0.0:unpack-dependencies from plugin realm ClassRealm[plugin>org.apache.maven.plugins:maven-dependency-plugin:3.0.0, parent: sun.misc.Launcher$AppClassLoader@42a57993] [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-dependency-plugin:3.0.0:unpack-dependencies' with basic configurator --> [DEBUG] (f) excludeTransitive = true [DEBUG] (s) failOnMissingClassifierArtifact = false [DEBUG] (f) ignorePermissions = false [DEBUG] (f) includeArtifactIds = bullpen-msg [DEBUG] (f) includeClassifiers = wsdl [DEBUG] (f) includeGroupIds = com.issinc.jms.bullpen [DEBUG] (f) includeTypes = zip [DEBUG] (s) markersDirectory = C:\svn\SPACEOPS\JMS\trunk\jax-ws-resources\bullpen-jax-ws\target\dependency-maven-plugin-markers [DEBUG] (f) outputAbsoluteArtifactFilename = false [DEBUG] (s) outputDirectory = C:\svn\SPACEOPS\JMS\trunk\jax-ws-resources\bullpen-jax-ws\target [DEBUG] (f) overWriteIfNewer = true [DEBUG] (f) overWriteReleases = true [DEBUG] (f) overWriteSnapshots = true [DEBUG] (s) prependGroupId = false [DEBUG] (f) project = MavenProject: com.issinc.jms.jax.ws.resources:bullpen-jax-ws:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\jax-ws-resources\bullpen-jax-ws\pom.xml [DEBUG] (f) reactorProjects = [MavenProject: com.issinc.jms:jms-parent:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\pom.xml, MavenProject: com.issinc.jms.external:third-party:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\third-party\pom.xml, MavenProject: com.issinc.jms.exchange:exchange-parent:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\third-party\exchange\pom.xml, MavenProject: com.issinc.jms.exchange:ews-java-api:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\third-party\exchange\ews-java-api-master\pom.xml, MavenProject: com.issinc.jms.exchange:jms-ews:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\third-party\exchange\jms-ews\pom.xml, MavenProject: com.issinc.jms.external:asw:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\third-party\asw\pom.xml, MavenProject: com.issinc.jms.external:third-party-jax-ws-model:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\third-party\third-party-jax-ws-model\pom.xml, MavenProject: com.issinc.jms.external:jmsedm-v3.3.0:11.x-SNAPSHOT @C:\svn\SPACEOPS\JMS\trunk\third-party\jmsedm-v3.3.0\pom.xml, MavenProject: com.issinc.jms.external:third-party-enterprise-messaging-parent:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\third-party\third-party-enterprise-messaging\pom.xml, MavenProject: com.issinc.jms.external:enterprise-messaging-wsdl:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\third-party\third-party-enterprise-messaging\enterprise-messaging-wsdl\pom.xml, MavenProject: com.issinc.jms.external:enterprise-messaging-sei-parent:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\third-party\third-party-enterprise-messaging\enterprise-messaging-sei\pom.xml, MavenProject: com.issinc.jms.external:em-notification-consumer-sei:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\third-party\third-party-enterprise-messaging\enterprise-messaging-sei\em-notification-consumer\pom.xml, MavenProject: com.issinc.jms.external:em-notification-producer-sei:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\third-party\third-party-enterprise-messaging\enterprise-messaging-sei\em-notification-producer\pom.xml, MavenProject: com.issinc.jms.external:em-subscription-manager-sei:11.x-SNAPSHOT @C:\svn\SPACEOPS\JMS\trunk\third-party\third-party-enterprise-messaging\enterprise-messaging-sei\em-subscription-manager\pom.xml, MavenProject: com.issinc.jms.external:em-wsn-admin-sei:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\third-party\third-party-enterprise-messaging\enterprise-messaging-sei\em-wsn-admin\pom.xml, MavenProject: com.issinc.jms.external:third-party-ccsds:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\third-party\third-party-ccsds\pom.xml, MavenProject: com.issinc.jms.common:common-parent:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\common-parent\pom.xml, MavenProject: com.issinc.jms.common:common-stack:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\common-parent\common-stack\pom.xml, MavenProject: com.issinc.jms.common:common-core:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\common-core\pom.xml, MavenProject: com.issinc.jms.common:common-domain-model:11.x-SNAPSHOT @C:\svn\SPACEOPS\JMS\trunk\common-domain-model\pom.xml, MavenProject: com.issinc.jms.common:common-dao:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\common-dao\pom.xml, MavenProject: com.issinc.jms.common:common-crypto:11.x-SNAPSHOT @ C:\svn\SPACEOPS\JMS\trunk\common-crypto\pom.xml, MavenProject: com.issinc.jms.common:common-config:11.x-SNAPSHOT @ C:\
Re: maven-dependency-plugin skips unpack goal
With -X added to the command line it succeeded. I will try it again. That is how this problem has been going...sometimes it works but mostly it does not. At times I make a small change and it works thinking that maybe the issue is fixed but only to find that subsequent builds fail. Can you tell anything from the non-debug log? Our build parameters are Maven 3.3.9, JDK8 on Windows. -Dave On Fri, Jan 20, 2017 at 9:46 AM, David Hoffer wrote: > Here is some build and log messages when run in normal mode...I will get > debug logs. Note it's the unpack-JMS-WS-Eventing step that is skipped > below...so the expected file is not found. > > [00:34:49] : [Step 2/3] [INFO] > > [00:34:49] : [Step 2/3] [INFO] -- > -- > [00:34:49] : [Step 2/3] [INFO] Building JMS JAX-WS: Bullpen JAX-WS (JAR) > 11.x-SNAPSHOT > [00:34:49] : [Step 2/3] [INFO] -- > -- > [00:34:49] : [Step 2/3] [Maven Watcher] project started: > com.issinc.jms.jax.ws.resources:bullpen-jax-ws:jar:11.x-SNAPSHOT > [00:34:49] : [Step 2/3] [Maven Watcher] > [00:34:49]i: [Step 2/3] ##teamcity[projectStarted tc:tags='tc:internal' > projectId='com.issinc.jms.jax.ws.resources:bullpen-jax-ws:jar:11.x-SNAPSHOT' > groupId='com.issinc.jms.jax.ws.resources' artifactId='bullpen-jax-ws' > testReportsDir0='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/target/failsafe-reports' > testReportsDir1='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/ > target/surefire-reports'] > [00:34:49]E: [Step 2/3] com.issinc.jms.jax.ws.resources:bullpen-jax-ws > [00:34:49]i: [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] > ##teamcity[importData tc:tags='tc:internal' type='surefire' path='F:/work/ > 5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/ > target/failsafe-reports/TEST-*.xml' whenNoDataPublished='nothing' > logAsInternal='true'] > [00:34:49]i: [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] > ##teamcity[importData tc:tags='tc:internal' type='surefire' path='F:/work/ > 5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/ > target/surefire-reports/TEST-*.xml' whenNoDataPublished='nothing' > logAsInternal='true'] > [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing > data from 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/ > target/failsafe-reports/TEST-*.xml' (not existing file) with 'surefire' > processor > [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing > data from 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/ > target/surefire-reports/TEST-*.xml' (not existing file) with 'surefire' > processor > [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] > [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- > properties-maven-plugin:1.0-alpha-2:set-system-properties > (set-additional-system-properties) @ bullpen-jax-ws --- > [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Set > 3 system properties > [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] > [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- > maven-dependency-plugin:3.0.0:unpack-dependencies (unpack-bullpen-msg) @ > bullpen-jax-ws --- > [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] > [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- > maven-dependency-plugin:3.0.0:unpack-dependencies > (unpack-JMS-WS-Eventing) @ bullpen-jax-ws --- > [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] > [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- > maven-replacer-plugin:1.4.1:replace (replace-elements-import) @ > bullpen-jax-ws --- > [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Surefire > report watcher > [00:34:50] : [Surefire report watcher] Watching paths: > [00:34:50] : [Surefire report watcher] F:\work\5c4a237177bf7a76\jax- > ws-resources\bullpen-jax-ws\target\failsafe-reports\TEST-*.xml > [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Surefire > report watcher > [00:34:50] : [Surefire report watcher] Watching paths: > [00:34:50] : [Surefire report watcher] F:\work\5c4a237177bf7a76\jax- > ws-resources\bullpen-jax-ws\target\surefire-reports\TEST-*.xml > [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] > Ignoring missing file > [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] > Replacement run on 0 file. > [00:34:50] : [co
Re: maven-dependency-plugin skips unpack goal
Here is some build and log messages when run in normal mode...I will get debug logs. Note it's the unpack-JMS-WS-Eventing step that is skipped below...so the expected file is not found. [00:34:49] : [Step 2/3] [INFO] [00:34:49] : [Step 2/3] [INFO] [00:34:49] : [Step 2/3] [INFO] Building JMS JAX-WS: Bullpen JAX-WS (JAR) 11.x-SNAPSHOT [00:34:49] : [Step 2/3] [INFO] [00:34:49] : [Step 2/3] [Maven Watcher] project started: com.issinc.jms.jax.ws.resources:bullpen-jax-ws:jar:11.x-SNAPSHOT [00:34:49] : [Step 2/3] [Maven Watcher] [00:34:49]i: [Step 2/3] ##teamcity[projectStarted tc:tags='tc:internal' projectId='com.issinc.jms.jax.ws.resources:bullpen-jax-ws:jar:11.x-SNAPSHOT' groupId='com.issinc.jms.jax.ws.resources' artifactId='bullpen-jax-ws' testReportsDir0='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/target/failsafe-reports' testReportsDir1='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/target/surefire-reports'] [00:34:49]E: [Step 2/3] com.issinc.jms.jax.ws.resources:bullpen-jax-ws [00:34:49]i: [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] ##teamcity[importData tc:tags='tc:internal' type='surefire' path='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/target/failsafe-reports/TEST-*.xml' whenNoDataPublished='nothing' logAsInternal='true'] [00:34:49]i: [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] ##teamcity[importData tc:tags='tc:internal' type='surefire' path='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/target/surefire-reports/TEST-*.xml' whenNoDataPublished='nothing' logAsInternal='true'] [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing data from 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/target/failsafe-reports/TEST-*.xml' (not existing file) with 'surefire' processor [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing data from 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/target/surefire-reports/TEST-*.xml' (not existing file) with 'surefire' processor [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- properties-maven-plugin:1.0-alpha-2:set-system-properties (set-additional-system-properties) @ bullpen-jax-ws --- [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Set 3 system properties [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-dependency-plugin:3.0.0:unpack-dependencies (unpack-bullpen-msg) @ bullpen-jax-ws --- [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-dependency-plugin:3.0.0:unpack-dependencies (unpack-JMS-WS-Eventing) @ bullpen-jax-ws --- [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:49] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-replacer-plugin:1.4.1:replace (replace-elements-import) @ bullpen-jax-ws --- [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Surefire report watcher [00:34:50] : [Surefire report watcher] Watching paths: [00:34:50] : [Surefire report watcher] F:\work\5c4a237177bf7a76\jax-ws-resources\bullpen-jax-ws\target\failsafe-reports\TEST-*.xml [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Surefire report watcher [00:34:50] : [Surefire report watcher] Watching paths: [00:34:50] : [Surefire report watcher] F:\work\5c4a237177bf7a76\jax-ws-resources\bullpen-jax-ws\target\surefire-reports\TEST-*.xml [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Ignoring missing file [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Replacement run on 0 file. [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-replacer-plugin:1.4.1:replace (replace-elements-namespace) @ bullpen-jax-ws --- [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Ignoring missing file [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Replacement run on 0 file. [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] --- maven-replacer-plugin:1.4.1:replace (replace-types-namespace) @ bullpen-jax-ws --- [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Ignoring missing file [00:34:50] : [com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO] Replacement run on 0 file. [00:34:50] : [com.issinc.