Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Karl Heinz Marbaise]

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)

[Robert Turner]

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="-Dmaven.repo.local=.

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Robert Turner]

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 security tooling (which of course complains that it is
> > ancient and

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Robert Turner]

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)

[Tamás Cservenák]

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...
>
>
> Kind regard

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Karl Heinz Marbaise]

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-dependencies goal

[INFO] --- dependency:3.7.1:copy-dependencies (default) @
dependency-f

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Nils Breunese]

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)

[Robert Turner]

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
> 
> copy-dependencies
> 
> 
&g

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Robert Turner]

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:
https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia/1.12.0/do

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Karl Heinz Marbaise]

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
destination.
09

maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Robert Turner]

(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:28.043 [I

[ANN] Apache Maven Dependency Plugin 3.7.1 released

[Slawomir Jaranowski]

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

[Michael Osipov]

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

[Tamás Cservenák]

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 

Re: [DISCUSS] Maven Dependency Plugin

[Tamás Cservenák]

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

[Tamás Cservenák]

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

[Francois Marot]

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

[Tamás Cservenák]

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

[Tamás Cservenák]

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

[Greg Chabala]

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

[Tamás Cservenák]

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

[Oliver B. Fischer]

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

[Alexander Kriegisch]

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

[Michael Osipov]

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

[Slawomir Jaranowski]

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

[Francois Marot]

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

[Tamás Cservenák]

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

[Greg Chabala]

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

[Tamás Cservenák]

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 Chabala]

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

[Tamás Cservenák]

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

[Tamás Cservenák]

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

[Scott Kurz]

+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

[Elliotte Rusty Harold]

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

[Tamás Cservenák]

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

[Slawomir Jaranowski]

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

[Richard Eckart de Castilho]

> 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

[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
> 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

[Oliver B. Fischer]

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

[Richard Eckart de Castilho]

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

[Romain Manni-Bucau]

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

[Matthias Bünger]

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

[Christian Stein]

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

[jebeaudet]

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

[Gary Gregory]

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

[Mantas Gridinas]

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

[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

[ANN] Release Maven Dependency Plugin 3.6.1 released

[Michael Osipov]

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

[Michael Osipov]

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

[Kamalpreet Kaur]

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

[Michael Osipov]

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

[Michael Osipov]

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

[Slawomir Jaranowski]

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

[Andreas Sewe]

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

[Slawomir Jaranowski]

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

[João Fernandes]

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

[Michael Osipov]

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?

[Tom VanDeGrift]

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

[Alexander Kriegisch]

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

[Delany]

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

[Amedee Van Gasse]

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: Maven Dependency Plugin

[John Patrick]

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

[Markus Karg]

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

[John Patrick]

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

[Markus Karg]

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

[Alexander Kriegisch]

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

[Shelley Baker]

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

[Shelley]

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

Re: maven-dependency-plugin:3.1.2:unpack not invoked, then does not unpack specified dependencies

[Simone Tripodi]

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

[Simone Tripodi]

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

mvn site vs an unusual maven-dependency-plugin configuration

[Alex O'Ree]

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?

[ANN] Apache Maven Dependency Plugin Version 3.1.1 Released

[Karl Heinz Marbaise]

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=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

[Karl Heinz Marbaise]

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=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

[Lewis John McGibbney]

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 <joerg.schai...@gmx.de> 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
> > <lewi...@apache.org> 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

[Jörg Schaible]

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
> <lewi...@apache.org> 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

[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 <lewi...@apache.org>
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

[lewis john mcgibbney]

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

[Karl Heinz Marbaise]

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=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

[Karl Heinz Marbaise]

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=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

[David Hoffer]

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 <dhoff...@gmail.com> 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 <khmarba...@gmx.de>
> wrote:
>
>> Hi David,
>>
>> On 23/01/17 00:54, David Hoffer wrote:
>>
>>> I will try all of t

Re: maven-dependency-plugin skips unpack goal

[David Hoffer]

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
>> <http://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
>> <http://com.issinc.jms.jax.ws>.resources'
>> artifactId='bullpen-jax-ws'
>> testReportsDir0='F:/work/5c4a2
>> 37177bf7a76/jax-ws-resources/b
>> ullpen-jax-ws/target/failsafe-reports'
>> testReportsDir1='F:/work/5c4a2
>> 37177bf7a76/jax-ws-resources/b
>> ullpen-jax-ws/target/surefire-reports']
>> [00:34:49]E:[Step 2/3] com.issinc.jms.jax.ws
>> <http://com.issinc.jms.jax.ws>
>> .resources:bullpen-jax-ws
>> [00:34:49]i:[com.issinc.jms.ja
>> x.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.ja
>> x.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
>> <http://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
>> <http://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
>> <http://com.issinc.jms.jax.ws>
>> .resources:bullpen-jax-ws]
>> [INFO]
>> [00:34:49] :[com.issinc.jms.jax.ws
>> <http://com.issinc.jms.jax.ws>
>> .resources:bullpen-jax-ws]
>> [INFO] ---
>> properties-maven-plugin:1.0-al
>> pha-2:set-system-properties
>> (set-additional-system-properties) @ bullpen-jax-ws
>> ---
>> [00:34:49] :[com.issinc.jms.jax.ws
>> <http://com.issinc.jms.jax.ws>

Re: maven-dependency-plugin skips unpack goal

[Karl Heinz Marbaise]

ue
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
<dhoff...@gmail.com <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
<khmarba...@gmx.de <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

Re: maven-dependency-plugin skips unpack goal

[David Hoffer]

uch 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 <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 <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 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'
>>>>> group

Re: maven-dependency-plugin skips unpack goal

[Karl Heinz Marbaise]

esources/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)
.. SUCCESS [22:08 min]
[00:34:50] :[Step 2/3] [INFO] Third Party (POM)
.. SUCCESS [ 15.097 s]
[00:34:50] :[Step 2/3] [INFO] JMS Exchange (POM)
..

Re: maven-dependency-plugin skips unpack goal

[David Hoffer]

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 <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 <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 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 'surefire' processor
>>> [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] [INFO]
>>> [00:34:49] :[com.issinc.jms.jax.ws.resource

Re: maven-dependency-plugin skips unpack goal

[David Hoffer]

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 <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 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-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

Re: maven-dependency-plugin skips unpack goal

[Karl Heinz Marbaise]

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 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-

Re: maven-dependency-plugin skips unpack goal

[David Hoffer]

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:\svn\SPACEO

Re: maven-dependency-plugin skips unpack goal

[David Hoffer]

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 <dhoff...@gmail.com> 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-namesp

Re: maven-dependency-plugin skips unpack goal

[David Hoffer]

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.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

Re: maven-dependency-plugin skips unpack goal

[Karl Heinz Marbaise]

Hi,

On 20/01/17 17:07, Bernd Eckenfels wrote:

Any logs (on debug level)?


yes and a concrete error message and of course (as Bernd already 
mentioned log output)...


Just a note: Have you correctly defined a dependency to the module which 
creates the zip/tar/jar from your module which uses 
maven-dependency-plugin:unpack ?


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 skips unpack goal

[David Hoffer]

I'll run that right now...

-Dave

On Fri, Jan 20, 2017 at 9:07 AM, Bernd Eckenfels 
wrote:

> Any logs (on debug level)?
>
> Am Fri, 20 Jan 2017 08:55:44 -0700
> schrieb David Hoffer :
>
> > We have a large multi-module build where occasionally (often) the
> > maven-dependency-plugin's unpack and unpack-dependencies goal will
> > skip their work.  E.g. The specified artifact is not unzipped.
>
> -
> 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

[Bernd Eckenfels]

Any logs (on debug level)?

Am Fri, 20 Jan 2017 08:55:44 -0700
schrieb David Hoffer :

> We have a large multi-module build where occasionally (often) the
> maven-dependency-plugin's unpack and unpack-dependencies goal will
> skip their work.  E.g. The specified artifact is not unzipped.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

maven-dependency-plugin skips unpack goal

[David Hoffer]

We have a large multi-module build where occasionally (often) the
maven-dependency-plugin's unpack and unpack-dependencies goal will skip
their work.  E.g. The specified artifact is not unzipped.

I have not been able to get a handle on what is causing this failure.  This
has been an ongoing issue for some time and we just have to fire off the
build again and generally it will succeed with a few tries and no build
changes.

Now for some background.  Our build has several modules/artifacts that are
just resources, e.g. a collection of wsdl & schema files that we then
reference in various parts of the build and unzip (usually with file
filtering) so that the consuming module can perform some operation on the
file(s), e.g. wsimport goal.

Note that in all/most cases we use maven-dependency-plugin to unpack more
than one artifact.  In the one that is failing now, it unpacks two and the
second one fails.

The module that creates the resource zips uses the maven-assembly-plugin
single goal using a descriptor file for each one.  That module creates a
few different zip artifacts this way each with a classifier.

What might be causing these random failures?

I did update the maven-dependency-plugin version from 2.10 to 3.0.0 and
that did not help.  We have been using version 2.6 of the
maven-assembly-plugin and I'm upgrading now to 3.0.0 to see if that helps.

Also to make things more confusing this error occurs more when we have
profile enabled that generates the sources and javadocs jars for each
module.  E.g. when the jar goal of maven-source-plugin &
maven-javadoc-plugin is enabled this error is more repeatable then when not
enabled.

Any suggestions on what is going on?  I can post poms if helpful.

-Dave

[ANN] Apache Maven Dependency Plugin 3.0.0 Released

[Robert Scholte]

The Apache Maven team is pleased to announce the release of the Apache
Maven Dependency Plugin, version 3.0.0

The dependency plugin provides the capability to manipulate artifacts. It
can copy and/or unpack artifacts from local or remote repositories to a
specified location.

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.0.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.0.0

** Bug
  * [MDEP-410] - Add dependency:collect goal which prints the  
dependency

list by resolving the POMs only
  * [MDEP-436] - German umlauts in outputDirectory and destFileName
getting garbled
  * [MDEP-478] - dependency:copy-dependencies always overwrites if
 is true
  * [MDEP-483] - NullPointerException when using classifier and markers
  * [MDEP-486] - Upgrade plexus-utils to 3.0.22
  * [MDEP-506] - NPE in AnalyzeDepMgt.getMismatch
  * [MDEP-531] - MDP 2.10 depends on a known insecure library
commons-collections:3.2.1
  * [MDEP-543] - Remove link to non-existing Codehaus wiki

** Documentation
  * [MDEP-546] - Update project information on plugin site

** Improvement
  * [MDEP-487] - Documentation cleanup
  * [MDEP-493] - Change Maven prerequisite and JDK requirement
  * [MDEP-494] - Remove/replace Maven2 specific code
  * [MDEP-495] - Remove deprecated parameters
  * [MDEP-511] - Upgrade maven-common-artifact-filters to 3.0.0
  * [MDEP-512] - Removed unused dependency to maven-invoker component.
  * [MDEP-517] - Upgrade plexus-archiver from 2.9 to 3.0.3
  * [MDEP-527] - Upgrade of 'plexus-archiver' to version 3.3.
  * [MDEP-530] - Upgrade mrm to 1.0.0
  * [MDEP-537] - Goal purge-local-repository requires a Maven project,
even with manualIncludes
  * [MDEP-538] - Display moduleName
  * [MDEP-539] - Upgrade maven-shared-components parent to version 30

** New Feature
  * [MDEP-509] - dependency:tree and :list should reveal 'optional'
  * [MDEP-514] - Add support for tar.snappy compression

** Task
  * [MDEP-529] - Upgrade of plexus-archiver to 3.4.
  * [MDEP-544] - Upgrade of plexus-interpolation to 1.24.

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: Artefact jars, copied by maven-dependency-plugin, are unrecognisable.

[Gintautas Sulskus]

To add, the corresponding Postgresql jar in local repo (.m2) works just
fine.

Best Wishes,
Gintautas Sulskus

On Fri, Dec 2, 2016 at 5:52 PM, Gintautas Sulskus <
gintautas.suls...@gmail.com> wrote:

> Hi,
>
> I am trying to copy a few maven artefacts to the project's build directory.
> For this purpose, I am using maven-dependency-plugin [1]. The code to copy
> a PostgreSQL artefact to project sub-dir "lib" looks as in [2].
>
> The jar is copied to the specified location (./lib) as expected. However,
> the jar cannot be opened and is unusable.
> Am I misusing the plug-in or have I missed something?
>
> Thanks,
> Gin
>
> References:
> [1] http://maven.apache.org/plugins/maven-dependency-plugin/usage.html
> [2] http://pastebin.com/Y2rSKLt3
>
>

Artefact jars, copied by maven-dependency-plugin, are unrecognisable.

[Gintautas Sulskus]

Hi,

I am trying to copy a few maven artefacts to the project's build directory.
For this purpose, I am using maven-dependency-plugin [1]. The code to copy
a PostgreSQL artefact to project sub-dir "lib" looks as in [2].

The jar is copied to the specified location (./lib) as expected. However,
the jar cannot be opened and is unusable.
Am I misusing the plug-in or have I missed something?

Thanks,
Gin

References:
[1] http://maven.apache.org/plugins/maven-dependency-plugin/usage.html
[2] http://pastebin.com/Y2rSKLt3

Re: maven dependency plugin - build-classpath goal

[Dagan Sandler]

Hi,

Can you show your pom and what's the result you're getting?
I have just tested with a sample project and it looks fine:



junit
junit
4.11
sources






org.apache.maven.plugins
maven-dependency-plugin
2.10





Command line: mvn dependency:build-classpath -Dmdep.stripClassifier=true
-Dmdep.prefix=foo
Output:

[INFO] Dependencies classpath:

foo\junit-4.11.jar;foo\hamcrest-core-1.3.jar



On Thu, Nov 3, 2016 at 10:49 AM, LEBOULANGER Aurélien <
aurelien.leboulan...@3ds.com> wrote:

> Hello,
>
> I’m trying to use the maven-dependency plugin (2.10) with the
> build-classpath goal.
> I want to strip the classifier but it’s not work:
>
> mvn dependency:build-classpath -Dmdep.stripClassifier=true
>
> I also add the option -Dmdep.prefix="foo" (needed regarding the
> documentation) but it’s not works too.
>
> Thanks for your help,
>
> --
> Cordialement / Best regards,
> Aurélien
>
> This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential and/or
> privileged.
>
> If you are not one of the named recipients or have received this email in
> error,
>
> (i) you should not read, disclose, or copy it,
>
> (ii) please notify sender of your receipt by reply email and delete this
> email and all attachments,
>
> (iii) Dassault Systemes does not accept or assume any liability or
> responsibility for any use of or reliance on this email.
>
> For other languages, go to http://www.3ds.com/terms/email-disclaimer
>

maven dependency plugin - build-classpath goal

[LEBOULANGER Aurélien]

Hello,

I’m trying to use the maven-dependency plugin (2.10) with the build-classpath 
goal.
I want to strip the classifier but it’s not work:

mvn dependency:build-classpath -Dmdep.stripClassifier=true

I also add the option -Dmdep.prefix="foo" (needed regarding the documentation) 
but it’s not works too.

Thanks for your help,

--
Cordialement / Best regards,
Aurélien

This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systemes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.

For other languages, go to http://www.3ds.com/terms/email-disclaimer

About goal analyze-duplicate of maven-dependency-plugin

[Grammer]

My bom-project use importing other poms in dependencyManagement section to
accumulate dependency versions in one, and it seems that analyze-duplicate
goal of maven-dependency-plugin is not detect duplication, if same
dependency presence in importing pom and bom pom. For reproduce lets create
two projects: some-framework-bom and my-bom: 

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/xsd/maven-4.0.0.xsd;>
4.0.0
some.framework
bom
1
pom



org.slf4j
slf4j-api
1.7.13






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/xsd/maven-4.0.0.xsd;>
4.0.0
my
bom
1
pom



some.framework
bom
1
pom
import


org.slf4j
slf4j-api
1.7.13





Run "mvn install" for some.framework:bom:1 and then run "mvn
dependency:analyze-duplicate" against my:bom:1. Goal dont show any
duplicates. So if, it is a bug, please help to register it in jira.



--
View this message in context: 
http://maven.40175.n5.nabble.com/About-goal-analyze-duplicate-of-maven-dependency-plugin-tp5879988.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org