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

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

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

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-fetching-issue ---
Downloading from central:

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

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/doxia-1.12.0.pom
(18 kB at 248 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-logging-api/1.12.0/doxia-logging-api-1.12.0.pom

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:27:28.043 [INFO] com.fasterxml.jackson.core:jackson-databind:jar:2.15.2
already 

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

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

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

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

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

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  wrote: 
> Hi,
> 
> if you use the copy goal, you don't have to add them to your list of 
> dependencies. Personally I would use the 
> copy-dependencies goal and copy only the ones with scope provided (i.e. you 
> don't have to specify each one 
> again).
> 
> Cheers,
> Jörg
> 
> 
> Am Fri, 23 Feb 2018 09:58:09 -0800 schrieb lewis john mcgibbney:
> 
> > I should also say, that the workaround is to list each and every
> > transitive dependency in the dependency declaration with scope
> > 'provided', such that they are NOT on the normal runtime classpath but
> > ARE correctly copied into the target directory defined within the
> > maven-dependency-plugin configuration as shown above.
> > The only issue with this workaround is that it is extremely messy,
> > bloats my POM and is difficult to maintain as I have now introduced
> > around 50 or so additional dependencies which all have versions, etc.
> > Thanks again for any hints.
> > Lewis
> > 
> > On Fri, Feb 23, 2018 at 9:55 AM, lewis john mcgibbney
> >  wrote:
> > 
> >> Hello users@,
> >> I am looking to dynamically load JAR's during a program execution based
> >> upon a users input and therefore using the maven-dependency-plugin to
> >> do this.
> >> Specifically, the plugin configuration looks as follows
> >>
> >>   
> >> org.apache.maven.plugins
> >> maven-dependency-plugin
> >> 
> >>   
> >> copy prepare-package
> >> 
> >>   copy
> >> 
> >> 
> >>   
> >> 
> >>   org.apache.any23.plugins
> >>   apache-any23-openie
> >>   ${project.version}
> >>   ${output.directory}
> >> 
> >> ...
> >> This works fine, however I have an issue with regards to these specific
> >> JARs being present on the classpath during the build and runtime
> >> depending on the  I assign to them within the dependency
> >> definition.
> >> If I mark the scope as 'runtime', the dependencies are added to the
> >> normal classpath which I do not want, as the purpose here is dynamic
> >> classloading via user input.
> >> On the other hand, if I define the dependency scope as 'provided' then
> >> no transitive dependencies are acquired hence I encounter
> >> java.lang.NoClassDefFoundError as although the primary dependency is
> >> present, it's own dependencies are not.
> >>
> >> Does anyone have a way to get around this. Ideally I am looking for a
> >> solution to define a specific location I was dependencies (and the
> >> transitive dependencies) to reside such that I can load them
> >> dynamically at runtime.
> >> Thank you kindly in advance,
> >> Lewis
> >>
> >> --
> >> http://home.apache.org/~lewismc/
> >> http://people.apache.org/keys/committer/lewismc
> >>
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

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

Re: [Maven Dependency Plugin] Inheriting transitive dependencies whilst defining an artifact output directory

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

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

> Regarding the reactor build order/issue okay/yes that is what we expected
> that it builds each to the final phase.  However if I step back and
> describe what I see in the build behavior...I see that although each module
> does build to final stage (e.g. expected generated artifacts are in target
> folder) there is some race condition where the dependency plugin does not
> think/know that an artifact was previously created.  That explains what we
> see in practice.  And I say race condition because it sometimes works (e.g.
> added -X and it worked once at least).  I do think this is somehow related
> to the use of the generate sources and/or javadocs which is specified at
> the top level pom.  You mentioned this causes it to fork I don't really
> understand why that is.  The forking sounds suspicious to me in that maybe
> it is causing the race condition?  Is there a way to turn forking off?
>
> It would be a major pain but I could move the generate sources and javadoc
> jars configuration to each module but since over a hundred this is very
> undesirable.  Also how can I generate an aggregated javadoc anyway but at
> the top level?  If I had the aggregated one I might be able to do away with
> the individual ones.  I'm surprised generating sources and javadoc jars is
> so problematic as it's standard to expect those will be generated for each
> java binary jar.  Can the specification of this generation be done in the
> top level pluginManagment section instead of plugins to clearly indicate
> our intent is for all child plugins to execute these goals not the parent?
>  (Except for the aggregated one...don't know how to do that except at the
> top level...in plugins section.  However maybe there is a different/better
> way?)
>
> Back to your suggestions...it turns out I can't use package only...not
> because of any build/reactor issue but because we have an OSGi installer
> section in this build that uses a plugin to collect up all the OSGi
> features.xml files.  Those files are collected from the .m2 repo so install
> has to be run.  This is not where any problem is as this has been used for
> at least 6 years this way with no issues.  But unless I comment out these
> parts I can't build with just package.  I might also note we do use a
> verify plugin that does guarantee that our build has no incorrect/missing
> dependencies.
>
> -Dave
>
>
> On Mon, Jan 23, 2017 at 12:02 AM, Karl Heinz Marbaise 
> wrote:
>
>> Hi David,
>>
>> On 23/01/17 00:54, David Hoffer wrote:
>>
>>> I will try all of these things the best I can, see my comments inline
>>> below.
>>>
>>> In addition to my comments below I have a question about how Maven
>>> handles plugin phases in a multi module build.  

Re: maven-dependency-plugin skips unpack goal

[David Hoffer]

Regarding the reactor build order/issue okay/yes that is what we expected
that it builds each to the final phase.  However if I step back and
describe what I see in the build behavior...I see that although each module
does build to final stage (e.g. expected generated artifacts are in target
folder) there is some race condition where the dependency plugin does not
think/know that an artifact was previously created.  That explains what we
see in practice.  And I say race condition because it sometimes works (e.g.
added -X and it worked once at least).  I do think this is somehow related
to the use of the generate sources and/or javadocs which is specified at
the top level pom.  You mentioned this causes it to fork I don't really
understand why that is.  The forking sounds suspicious to me in that maybe
it is causing the race condition?  Is there a way to turn forking off?

It would be a major pain but I could move the generate sources and javadoc
jars configuration to each module but since over a hundred this is very
undesirable.  Also how can I generate an aggregated javadoc anyway but at
the top level?  If I had the aggregated one I might be able to do away with
the individual ones.  I'm surprised generating sources and javadoc jars is
so problematic as it's standard to expect those will be generated for each
java binary jar.  Can the specification of this generation be done in the
top level pluginManagment section instead of plugins to clearly indicate
our intent is for all child plugins to execute these goals not the parent?
 (Except for the aggregated one...don't know how to do that except at the
top level...in plugins section.  However maybe there is a different/better
way?)

Back to your suggestions...it turns out I can't use package only...not
because of any build/reactor issue but because we have an OSGi installer
section in this build that uses a plugin to collect up all the OSGi
features.xml files.  Those files are collected from the .m2 repo so install
has to be run.  This is not where any problem is as this has been used for
at least 6 years this way with no issues.  But unless I comment out these
parts I can't build with just package.  I might also note we do use a
verify plugin that does guarantee that our build has no incorrect/missing
dependencies.

-Dave


On Mon, Jan 23, 2017 at 12:02 AM, Karl Heinz Marbaise 
wrote:

> Hi David,
>
> On 23/01/17 00:54, David Hoffer wrote:
>
>> I will try all of these things the best I can, see my comments inline
>> below.
>>
>> In addition to my comments below I have a question about how Maven
>> handles plugin phases in a multi module build.  Once the reactor module
>> build order is established does it build each module all the way to the
>> final phase specified by the command line before it moves on to the next
>> module?  (E.g. is this guaranteed behavior?)  Or does it build the same
>> phase across all modules before it moves to the next phase?  Or does it
>> use some combination in some fashion?
>>
>
> it must build every module to the final phase...and go them with the next
> module...
>
>
>
>> -Dave
>>
>> On Sun, Jan 22, 2017 at 11:15 AM, Karl Heinz Marbaise > > wrote:
>>
>> Hi David,
>>
>> the first thing I strongly recommend to make a build of your project
>> where you first clean the local cache ($HOME/.m2/repository)
>> completely and just run your build via:
>>
>> mvn package -DskipTests=true
>>
>>
>> [dh] I don't trust package w/o also a clean so plan to add that is
>> well.  W/o the clean any prior partial build would remain in the target
>> folder.  Ultimately what needs to work is deploy as that is what the CI
>> system will run after a fresh checkout in a clean working area.
>>
>
> This was not a general hint to go with it was just a single task to see if
> everything is right with your build...Of course you can add a clean call in
> this case ...
>
> The intention here is to check if the reactor builds correct and if all
> dependencies between the modules are correct...
>
> I know that you finally need to get working deploy...but first we should
> see if something else is wrong...
>
>
>
>
>>
>>
>> (No usage of install!)..
>>
>>
>> [dh] I'm curious as to why no install?  Wen we do our dev builds the
>> standard practice is to run clean install.
>>
>
> see my previous comments to check the dependencies between your modules...
>
> Just for a test build...you can do that just locally do a fresh checkout
> and remove the content of your cache and then
> try to run: mvn clean package -DskipTests=true
>
> (the clean after a fresh checkout is not needed)..
>
>
>
>
>
>>
>> This should work without any issue...If it does not than the problem
>> is located somewhere else...
>>
>> Maybe you can try to use maven-dependency-plugin:unpack instead of
>> unpack-dependencies like this:
>> For this you only a single execution of the plugin:
>>
>>  

Re: maven-dependency-plugin skips unpack goal

[Karl Heinz Marbaise]

Hi David,

On 23/01/17 00:54, David Hoffer wrote:

I will try all of these things the best I can, see my comments inline below.

In addition to my comments below I have a question about how Maven
handles plugin phases in a multi module build.  Once the reactor module
build order is established does it build each module all the way to the
final phase specified by the command line before it moves on to the next
module?  (E.g. is this guaranteed behavior?)  Or does it build the same
phase across all modules before it moves to the next phase?  Or does it
use some combination in some fashion?


it must build every module to the final phase...and go them with the 
next module...





-Dave

On Sun, Jan 22, 2017 at 11:15 AM, Karl Heinz Marbaise > wrote:

Hi David,

the first thing I strongly recommend to make a build of your project
where you first clean the local cache ($HOME/.m2/repository)
completely and just run your build via:

mvn package -DskipTests=true


[dh] I don't trust package w/o also a clean so plan to add that is
well.  W/o the clean any prior partial build would remain in the target
folder.  Ultimately what needs to work is deploy as that is what the CI
system will run after a fresh checkout in a clean working area.


This was not a general hint to go with it was just a single task to see 
if everything is right with your build...Of course you can add a clean 
call in this case ...


The intention here is to check if the reactor builds correct and if all 
dependencies between the modules are correct...


I know that you finally need to get working deploy...but first we should 
see if something else is wrong...








(No usage of install!)..


[dh] I'm curious as to why no install?  Wen we do our dev builds the
standard practice is to run clean install.


see my previous comments to check the dependencies between your modules...

Just for a test build...you can do that just locally do a fresh checkout 
and remove the content of your cache and then

try to run: mvn clean package -DskipTests=true

(the clean after a fresh checkout is not needed)..







This should work without any issue...If it does not than the problem
is located somewhere else...

Maybe you can try to use maven-dependency-plugin:unpack instead of
unpack-dependencies like this:
For this you only a single execution of the plugin:

   
   
 
   
   artifactId
   ${project.version}
   zip
   wsdl
   true
   **/*.class,**/*.xml
   **/*test.class
 
 
another one...
 
   

${project.build.directory}
   true
   true
 


[dh] I'm always wondering about the virtues of unpack vs.
unpack-dependencies.  Since what I am unpacking is part of the current
reactor build I have always felt it is better to use unpack-dependencies
so I can be certain the build is using the artifact generated by the
current build and not a prior build downloaded from Nexus.


>  My

understanding is unpack will get it from Nexus if it has a later
timestamp on the snapshot.  However unpack-dependencies will never
attempt to download and always get from current build so better in cases
where its the current build's results you want.  We would often need
multiple executions anyway as the outputDirectory is often different.







One thing you might consider is why have you separated the WSDL from
generating the code ? Can you combine the WSDL and the code
generation into a single module ? (Might this an option?)


[dh] No this isn't possible as we have large quantities of WSDL/Schemas
that are shared with our partners so we have one module that acts as
sort of the repository and publisher of the wsdl/schemas then our build
uses parts of that larger set of wsdl/schemas.  So we either make zips
of those smaller parts of wsdl/schemas that we can consume in the
appropriate source generation modules or we extract part of the zip to
do the same.


OK just fine it was just a question...





BTW: I would try to remove the scope in your project where you do
the unpack...


[dh] We don't specify the scope where we do the unpack...here is any
example pom.  (I assume this is where you were referring to scope?)



In the dependencies of the module where you do the unpack you have 
defined provided...







unpack-JMS-WS-Eventing
generate-sources

unpack-dependencies


${project.build.directory}
com.issinc.jms.layer7.deployment
layer7-static-resources
wsdl-JMS-WS-Eventing
zip
true
true
true
true
true

Re: maven-dependency-plugin skips unpack goal

[David Hoffer]

I will try all of these things the best I can, see my comments inline below.

In addition to my comments below I have a question about how Maven handles
plugin phases in a multi module build.  Once the reactor module build order
is established does it build each module all the way to the final phase
specified by the command line before it moves on to the next module?  (E.g.
is this guaranteed behavior?)  Or does it build the same phase across all
modules before it moves to the next phase?  Or does it use some combination
in some fashion?

-Dave

On Sun, Jan 22, 2017 at 11:15 AM, Karl Heinz Marbaise 
wrote:

> Hi David,
>
> the first thing I strongly recommend to make a build of your project where
> you first clean the local cache ($HOME/.m2/repository) completely and just
> run your build via:
>
> mvn package -DskipTests=true
>

[dh] I don't trust package w/o also a clean so plan to add that is well.
W/o the clean any prior partial build would remain in the target folder.
Ultimately what needs to work is deploy as that is what the CI system will
run after a fresh checkout in a clean working area.


>
> (No usage of install!)..
>

[dh] I'm curious as to why no install?  Wen we do our dev builds the
standard practice is to run clean install.

>
> This should work without any issue...If it does not than the problem is
> located somewhere else...
>
> Maybe you can try to use maven-dependency-plugin:unpack instead of
> unpack-dependencies like this:
> For this you only a single execution of the plugin:
>
>
>
>  
>
>artifactId
>${project.version}
>zip
>wsdl
>true
>**/*.class,**/*.xml
>**/*test.class
>  
>  
> another one...
>  
>
>
> ${project.build.directory}
>true
>true
>  
>

[dh] I'm always wondering about the virtues of unpack vs.
unpack-dependencies.  Since what I am unpacking is part of the current
reactor build I have always felt it is better to use unpack-dependencies so
I can be certain the build is using the artifact generated by the current
build and not a prior build downloaded from Nexus.  My understanding is
unpack will get it from Nexus if it has a later timestamp on the snapshot.
However unpack-dependencies will never attempt to download and always get
from current build so better in cases where its the current build's results
you want.  We would often need multiple executions anyway as the
outputDirectory is often different.

>
> One thing you might consider is why have you separated the WSDL from
> generating the code ? Can you combine the WSDL and the code generation into
> a single module ? (Might this an option?)
>

[dh] No this isn't possible as we have large quantities of WSDL/Schemas
that are shared with our partners so we have one module that acts as sort
of the repository and publisher of the wsdl/schemas then our build uses
parts of that larger set of wsdl/schemas.  So we either make zips of those
smaller parts of wsdl/schemas that we can consume in the appropriate source
generation modules or we extract part of the zip to do the same.

>
>
> BTW: I would try to remove the scope in your project where you do the
> unpack...
>

[dh] We don't specify the scope where we do the unpack...here is any
example pom.  (I assume this is where you were referring to scope?)


unpack-JMS-WS-Eventing
generate-sources

unpack-dependencies


${project.build.directory}
com.issinc.jms.layer7.deployment
layer7-static-resources
wsdl-JMS-WS-Eventing
zip
true
true
true
true
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



> 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 

Re: maven-dependency-plugin skips unpack goal

[Karl Heinz Marbaise]

Hi David,

the first thing I strongly recommend to make a build of your project 
where you first clean the local cache ($HOME/.m2/repository) completely 
and just run your build via:


mvn package -DskipTests=true

(No usage of install!)..

This should work without any issue...If it does not than the problem is 
located somewhere else...


Maybe you can try to use maven-dependency-plugin:unpack instead of 
unpack-dependencies like this:

For this you only a single execution of the plugin:

   
   
 
   
   artifactId
   ${project.version}
   zip
   wsdl
   true
   **/*.class,**/*.xml
   **/*test.class
 
 
another one...
 
   

${project.build.directory}
   true
   true
 

One thing you might consider is why have you separated the WSDL from 
generating the code ? Can you combine the WSDL and the code generation 
into a single module ? (Might this an option?)



BTW: I would try to remove the scope in your project where you do the 
unpack...



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


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 ?



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


Just some thoughts about...without really seeing the build and the 
complete poms etc.


Kind regards
Karl Heinz Marbaise

On 22/01/17 17:58, David Hoffer wrote:

Any input on this?  This is killing us right now...we don't have a way to
get past this and builds are failing.  We have no idea what to try to fix
this.

Any input is greatly appreciated.

-Dave

On Sat, Jan 21, 2017 at 7:18 AM, David Hoffer  wrote:


Maven home: C:\Programs\Apache\Maven\apache-maven-3.3.9
Java version: 1.8.0_102, vendor: Oracle Corporation
Java home: C:\Programs\Java\jdk1.8.0_102\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"

Command line: mvn clean install -PciBuild -DskipTests=true

We are not using the -T option.

The JMS: Parent (POM) is the top level pom and it is a regular pom, the
reason that it took 22 minutes is that the ciBuild profile was enabled.
This profile just turns on generating sources and javadoc jars for the
project, it also creates an uber javadoc jar using the aggregate-jar goal.
As I previously mentioned it does seem that generating the sources and
javadoc jars aggravates this issue so it occurs more often and right now
its failing almost all the time.  If I remove the source and javadoc jar
generation it will fail the same way but generally not as often.

-Dave


On Sat, Jan 21, 2017 at 3:38 AM, Karl Heinz Marbaise 
wrote:


Hi,

how is Maven called ? Which Maven Version do you use? Are you using "-T"
option?

What looks a little bit strnage to me is that a parent:

"[00:34:50] :   [Step 2/3] [INFO] JMS: Parent (POM)
.. SUCCESS [22:08 min]"

shows a time of 22 minutes ? Is this really a pom or is the
.. saying something different than the pom itself (so
packaging different than pom?):


Kind regards
Karl Heinz


On 20/01/17 17:46, David Hoffer wrote:


Here is some build and log messages when run in normal mode...I will get
debug logs.  Note it's the unpack-JMS-WS-Eventing step that is skipped
below...so the expected file is not found.

[00:34:49] :[Step 2/3] [INFO]

[00:34:49] :[Step 2/3] [INFO]

[00:34:49] :[Step 2/3] [INFO] Building JMS JAX-WS: Bullpen JAX-WS (JAR)
11.x-SNAPSHOT
[00:34:49] :[Step 2/3] [INFO]

[00:34:49] :[Step 2/3] [Maven Watcher] project started:
com.issinc.jms.jax.ws.resources:bullpen-jax-ws:jar:11.x-SNAPSHOT
[00:34:49] :[Step 2/3] [Maven Watcher]
[00:34:49]i:[Step 2/3] ##teamcity[projectStarted tc:tags='tc:internal'
projectId='com.issinc.jms.jax.ws.resources:bullpen-jax-ws:ja
r:11.x-SNAPSHOT'
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] 

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

> Maven home: C:\Programs\Apache\Maven\apache-maven-3.3.9
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Programs\Java\jdk1.8.0_102\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>
> Command line: mvn clean install -PciBuild -DskipTests=true
>
> We are not using the -T option.
>
> The JMS: Parent (POM) is the top level pom and it is a regular pom, the
> reason that it took 22 minutes is that the ciBuild profile was enabled.
> This profile just turns on generating sources and javadoc jars for the
> project, it also creates an uber javadoc jar using the aggregate-jar goal.
> As I previously mentioned it does seem that generating the sources and
> javadoc jars aggravates this issue so it occurs more often and right now
> its failing almost all the time.  If I remove the source and javadoc jar
> generation it will fail the same way but generally not as often.
>
> -Dave
>
>
> On Sat, Jan 21, 2017 at 3:38 AM, Karl Heinz Marbaise 
> wrote:
>
>> Hi,
>>
>> how is Maven called ? Which Maven Version do you use? Are you using "-T"
>> option?
>>
>> What looks a little bit strnage to me is that a parent:
>>
>> "[00:34:50] :   [Step 2/3] [INFO] JMS: Parent (POM)
>> .. SUCCESS [22:08 min]"
>>
>> shows a time of 22 minutes ? Is this really a pom or is the
>> .. saying something different than the pom itself (so
>> packaging different than pom?):
>>
>>
>> Kind regards
>> Karl Heinz
>>
>>
>> On 20/01/17 17:46, David Hoffer wrote:
>>
>>> Here is some build and log messages when run in normal mode...I will get
>>> debug logs.  Note it's the unpack-JMS-WS-Eventing step that is skipped
>>> below...so the expected file is not found.
>>>
>>> [00:34:49] :[Step 2/3] [INFO]
>>>
>>> [00:34:49] :[Step 2/3] [INFO]
>>> 
>>> [00:34:49] :[Step 2/3] [INFO] Building JMS JAX-WS: Bullpen JAX-WS (JAR)
>>> 11.x-SNAPSHOT
>>> [00:34:49] :[Step 2/3] [INFO]
>>> 
>>> [00:34:49] :[Step 2/3] [Maven Watcher] project started:
>>> com.issinc.jms.jax.ws.resources:bullpen-jax-ws:jar:11.x-SNAPSHOT
>>> [00:34:49] :[Step 2/3] [Maven Watcher]
>>> [00:34:49]i:[Step 2/3] ##teamcity[projectStarted tc:tags='tc:internal'
>>> projectId='com.issinc.jms.jax.ws.resources:bullpen-jax-ws:ja
>>> r:11.x-SNAPSHOT'
>>> groupId='com.issinc.jms.jax.ws.resources' artifactId='bullpen-jax-ws'
>>> testReportsDir0='F:/work/5c4a237177bf7a76/jax-ws-resources/b
>>> ullpen-jax-ws/target/failsafe-reports'
>>> testReportsDir1='F:/work/5c4a237177bf7a76/jax-ws-resources/b
>>> ullpen-jax-ws/target/surefire-reports']
>>> [00:34:49]E:[Step 2/3] com.issinc.jms.jax.ws.resources:bullpen-jax-ws
>>> [00:34:49]i:[com.issinc.jms.jax.ws.resources:bullpen-jax-ws]
>>> ##teamcity[importData tc:tags='tc:internal' type='surefire'
>>> path='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-
>>> ws/target/failsafe-reports/TEST-*.xml'
>>> whenNoDataPublished='nothing' logAsInternal='true']
>>> [00:34:49]i:[com.issinc.jms.jax.ws.resources:bullpen-jax-ws]
>>> ##teamcity[importData tc:tags='tc:internal' type='surefire'
>>> path='F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-
>>> ws/target/surefire-reports/TEST-*.xml'
>>> whenNoDataPublished='nothing' logAsInternal='true']
>>> [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing
>>> data from
>>> 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/ta
>>> rget/failsafe-reports/TEST-*.xml'
>>> (not existing file) with 'surefire' processor
>>> [00:34:49] :[com.issinc.jms.jax.ws.resources:bullpen-jax-ws] Importing
>>> data from
>>> 'F:/work/5c4a237177bf7a76/jax-ws-resources/bullpen-jax-ws/ta
>>> rget/surefire-reports/TEST-*.xml'
>>> (not existing file) with '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] ---
>>> 

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

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-namespace) @

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 @

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

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

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
>

Re: Maven Dependency Plugin Default life cycle phase not executed

[Anton Tanasenko]

That's the point. You don't have to specify an execution phase if a default
one is set.
But you do have to express your intent to execute the mojo during build by
specifying an execution itself.

In case of dependency:unpack, its
plugin
   ...
   executions
  execution
 id../id
 goalsgoalunpack/goal/goals
 configuration.../configuration
  /execution
   /executions
/plugin

See, no phase.

2015-06-02 20:16 GMT+03:00 Thomas Meyer tho...@m3y3r.de:


 Am 02.06.2015 6:58 nachm. schrieb Anton Tanasenko atg.sleepl...@gmail.com
 :
 
  Hi, you probably missed the previous section:
 

 Oops :-)

 Okay, I understand now.

 But one more question: what use has the assigned default life cycle of the
 resp Mojo class when you need to explicitly specify the execution phase in
 the pom?

  If you intend to configure this mojo for execution on the command line
  using:
  mvn dependency:copy
 
  you must not put the configuration inside the executions tag. Your
  configuration should look like this:
  ...
 
  2015-06-02 19:36 GMT+03:00 Thomas Meyer tho...@m3y3r.de:
 
   Hi,
  
   I've a question regarding the maven dependency plugin:
  
   In the usage description (
   https://maven.apache.org/plugins/maven-dependency-plugin/usage.html )
 in
   section The dependency:unpack mojo it's written that:
  
   you must not put the configuration inside the executions tag. Your
   configuration should look like this:
  
   But this doesn't seem to be true as the plugin seems not get executed
 at
   all, at least for a project with package type war.
  
   So what am I missing here?
   Any ideas?
  
   My expectation was that the plugin gets executed in the generated
 sources
   phase.
  
   Here an excerpt of my pom file:
  
  build
   [...]
 plugins
plugin
  artifactIdmaven-dependency-plugin/artifactId
  version2.10/version
  configuration
   artifactItems
 artifactItem
   [...]
  /artifactItem
/artifactItems
  /configuration
/plugin
plugin
   groupIdorg.bsc.maven/groupId
   artifactIdmaven-processor-plugin/artifactId
   version2.2.4/version
   executions
   execution
   idprocess/id
   phasegenerate-sources/phase
   goals
   goalprocess/goal
   /goals
   /execution
   /executions
   configuration
   defaultOutputDirectory
   ${project.build.directory}/generated-sources
   /defaultOutputDirectory
   processors
   processororg.mapstruct.ap.MappingProcessor/
   processor
   /processors
   /configuration
   dependencies
   dependency
   groupIdorg.mapstruct/groupId
   artifactIdmapstruct-processor/artifactId
   version${version.mapstruct}/version
   /dependency
   /dependencies
/plugin
  
   I'm using maven 3.3.1.
  
   With kind regards
   Thomas
 
 
 
 
  --
  Regards,
  Anton.

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




-- 
Regards,
Anton.

Re: Maven Dependency Plugin Default life cycle phase not executed

[Thomas Meyer]

Am 02.06.2015 8:28 nachm. schrieb Anton Tanasenko atg.sleepl...@gmail.com:

 That's the point. You don't have to specify an execution phase if a default 
 one is set. 
 But you do have to express your intent to execute the mojo during build by 
 specifying an execution itself. 

Okay, I see! Thanks for your support!


 In case of dependency:unpack, its 
 plugin 
    ... 
    executions 
   execution 
  id../id 
  goalsgoalunpack/goal/goals 
  configuration.../configuration 
   /execution 
    /executions 
 /plugin 

 See, no phase. 

 2015-06-02 20:16 GMT+03:00 Thomas Meyer tho...@m3y3r.de: 

  
  Am 02.06.2015 6:58 nachm. schrieb Anton Tanasenko atg.sleepl...@gmail.com 
  : 
   
   Hi, you probably missed the previous section: 
   
  
  Oops :-) 
  
  Okay, I understand now. 
  
  But one more question: what use has the assigned default life cycle of the 
  resp Mojo class when you need to explicitly specify the execution phase in 
  the pom? 
  
   If you intend to configure this mojo for execution on the command line 
   using: 
   mvn dependency:copy 
   
   you must not put the configuration inside the executions tag. Your 
   configuration should look like this: 
   ... 
   
   2015-06-02 19:36 GMT+03:00 Thomas Meyer tho...@m3y3r.de: 
   
Hi, 

I've a question regarding the maven dependency plugin: 

In the usage description ( 
https://maven.apache.org/plugins/maven-dependency-plugin/usage.html ) 
  in 
section The dependency:unpack mojo it's written that: 

you must not put the configuration inside the executions tag. Your 
configuration should look like this: 

But this doesn't seem to be true as the plugin seems not get executed 
  at 
all, at least for a project with package type war. 

So what am I missing here? 
Any ideas? 

My expectation was that the plugin gets executed in the generated 
  sources 
phase. 

Here an excerpt of my pom file: 

       build 
[...] 
      plugins 
     plugin 
       artifactIdmaven-dependency-plugin/artifactId 
       version2.10/version 
       configuration 
    artifactItems 
      artifactItem 
[...] 
       /artifactItem 
     /artifactItems 
       /configuration 
     /plugin 
     plugin 
    groupIdorg.bsc.maven/groupId 
    artifactIdmaven-processor-plugin/artifactId 
    version2.2.4/version 
    executions 
    execution 
    idprocess/id 
    phasegenerate-sources/phase 
    goals 
    goalprocess/goal 
    /goals 
    /execution 
    /executions 
    configuration 
    defaultOutputDirectory 
    ${project.build.directory}/generated-sources 
    /defaultOutputDirectory 
    processors 
    processororg.mapstruct.ap.MappingProcessor/ 
processor 
    /processors 
    /configuration 
    dependencies 
    dependency 
    groupIdorg.mapstruct/groupId 
    artifactIdmapstruct-processor/artifactId 
    version${version.mapstruct}/version 
    /dependency 
    /dependencies 
     /plugin 

I'm using maven 3.3.1. 

With kind regards 
Thomas 
   
   
   
   
   -- 
   Regards, 
   Anton. 
  
  - 
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org 
  For additional commands, e-mail: users-h...@maven.apache.org 
  



 -- 
 Regards, 
 Anton. 

Re: Maven Dependency Plugin Default life cycle phase not executed

[Anton Tanasenko]

Hi, you probably missed the previous section:

If you intend to configure this mojo for execution on the command line
using:
mvn dependency:copy

you must not put the configuration inside the executions tag. Your
configuration should look like this:
...

2015-06-02 19:36 GMT+03:00 Thomas Meyer tho...@m3y3r.de:

 Hi,

 I've a question regarding the maven dependency plugin:

 In the usage description (
 https://maven.apache.org/plugins/maven-dependency-plugin/usage.html ) in
 section The dependency:unpack mojo it's written that:

 you must not put the configuration inside the executions tag. Your
 configuration should look like this:

 But this doesn't seem to be true as the plugin seems not get executed at
 all, at least for a project with package type war.

 So what am I missing here?
 Any ideas?

 My expectation was that the plugin gets executed in the generated sources
 phase.

 Here an excerpt of my pom file:

build
 [...]
   plugins
  plugin
artifactIdmaven-dependency-plugin/artifactId
version2.10/version
configuration
 artifactItems
   artifactItem
 [...]
/artifactItem
  /artifactItems
/configuration
  /plugin
  plugin
 groupIdorg.bsc.maven/groupId
 artifactIdmaven-processor-plugin/artifactId
 version2.2.4/version
 executions
 execution
 idprocess/id
 phasegenerate-sources/phase
 goals
 goalprocess/goal
 /goals
 /execution
 /executions
 configuration
 defaultOutputDirectory
 ${project.build.directory}/generated-sources
 /defaultOutputDirectory
 processors
 processororg.mapstruct.ap.MappingProcessor/
 processor
 /processors
 /configuration
 dependencies
 dependency
 groupIdorg.mapstruct/groupId
 artifactIdmapstruct-processor/artifactId
 version${version.mapstruct}/version
 /dependency
 /dependencies
  /plugin

 I'm using maven 3.3.1.

 With kind regards
 Thomas




-- 
Regards,
Anton.

Re: Maven Dependency Plugin Default life cycle phase not executed

[Thomas Meyer]

Am 02.06.2015 6:58 nachm. schrieb Anton Tanasenko atg.sleepl...@gmail.com:

 Hi, you probably missed the previous section: 


Oops :-)

Okay, I understand now.

But one more question: what use has the assigned default life cycle of the resp 
Mojo class when you need to explicitly specify the execution phase in the pom? 

 If you intend to configure this mojo for execution on the command line 
 using: 
 mvn dependency:copy 

 you must not put the configuration inside the executions tag. Your 
 configuration should look like this: 
 ... 

 2015-06-02 19:36 GMT+03:00 Thomas Meyer tho...@m3y3r.de: 

  Hi, 
  
  I've a question regarding the maven dependency plugin: 
  
  In the usage description ( 
  https://maven.apache.org/plugins/maven-dependency-plugin/usage.html ) in 
  section The dependency:unpack mojo it's written that: 
  
  you must not put the configuration inside the executions tag. Your 
  configuration should look like this: 
  
  But this doesn't seem to be true as the plugin seems not get executed at 
  all, at least for a project with package type war. 
  
  So what am I missing here? 
  Any ideas? 
  
  My expectation was that the plugin gets executed in the generated sources 
  phase. 
  
  Here an excerpt of my pom file: 
  
     build 
  [...] 
    plugins 
   plugin 
     artifactIdmaven-dependency-plugin/artifactId 
     version2.10/version 
     configuration 
  artifactItems 
    artifactItem 
  [...] 
     /artifactItem 
   /artifactItems 
     /configuration 
   /plugin 
   plugin 
  groupIdorg.bsc.maven/groupId 
  artifactIdmaven-processor-plugin/artifactId 
  version2.2.4/version 
  executions 
  execution 
  idprocess/id 
  phasegenerate-sources/phase 
  goals 
  goalprocess/goal 
  /goals 
  /execution 
  /executions 
  configuration 
  defaultOutputDirectory 
  ${project.build.directory}/generated-sources 
  /defaultOutputDirectory 
  processors 
  processororg.mapstruct.ap.MappingProcessor/ 
  processor 
  /processors 
  /configuration 
  dependencies 
  dependency 
  groupIdorg.mapstruct/groupId 
  artifactIdmapstruct-processor/artifactId 
  version${version.mapstruct}/version 
  /dependency 
  /dependencies 
   /plugin 
  
  I'm using maven 3.3.1. 
  
  With kind regards 
  Thomas 




 -- 
 Regards, 
 Anton. 

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

Re: maven-dependency-plugin unpacking aar format?

[Jörg Hohwiller]

Hi there,

just my few cents...
An artifact type is something quite central. IMHO it is not the best way 
to force all artifacts to keep the information how to unpack it in their 
POMs and then magically fiddle it out from there.


If I type mvn foo and there is a maven-foo-plugin or foo-maven-plugin 
in the right groupId, then maven will automatically figure it out. So I 
would expect something similar here.

packagingaar/packaging
could trigger that some aar-maven-plugin is responsible for packaging. 
There could be a convenience goal for unpacking.


If you want to have some proprietary packaging in some other namespace 
(and not available in central) there could be some hint configured in 
settings.xml.


Cheers
  Jörg

Am 22.07.2014 19:41, schrieb Robert Scholte:

Hi,

to be able to unpack/unarchive Maven must know which Unarchiver should 
be used for this type. 'aar' is not one of the few default supported 
types, hence the exception.
The plugin responsible for packaging the aar-file should also have 
configured how to unarchive the aar-file.
In case of dependency:unpack it is quite simple: I would expect that 
the packaging plugin is configured in the pom.xml with a 
extensiontrue/extension. This way Maven can find such information.


However, I can imagine that in case of unpack-dependencies the 
aar-project.pom isn't used to detect the corresponding Unarchiver. 
Sounds like an improvement to me.


thanks,
Robert

ps. this is also an interesting usecase for the consumer-pom or the 
flatten-maven-plugin




Op Mon, 21 Jul 2014 22:40:18 +0200 schreef David Hoffer 
dhoff...@gmail.com:



I'm getting the following error trying to unpack some files from an aar.
 Is this not supported?  Is there any way to do this?

Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack-dependencies
(unpack-service) on project service: Unknown archiver type: No such
archiver: 'aar'. - [Help 1]

-Dave


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





smime.p7s
Description: S/MIME Cryptographic Signature

Re: maven-dependency-plugin unpacking aar format?

[David Hoffer]

) {
  WSDL11ToAxisServiceBuilder wsdl2AxisServiceBuilder =
  new WSDL11ToAxisServiceBuilder(wsdlStream,
  null, null);
  File file = Utils.toFile(servicesURL);
  if (file != null  file.exists()) {
  wsdl2AxisServiceBuilder.setCustomWSDLResolver(
  new AARBasedWSDLLocator(wsdlLocation,
  file, wsdlStream));
  wsdl2AxisServiceBuilder.setCustomResolver(
  new AARFileBasedURIResolver(file));
  }
  if (wsdlURL != null) {
 
  wsdl2AxisServiceBuilder.setDocumentBaseUri(wsdlURL.toString());
  }
  axisService =
  wsdl2AxisServiceBuilder.populateService();
  axisService.setWsdlFound(true);
  axisService.setCustomWsdl(true);
  axisService.setName(serviceName);
  }
  if (axisService == null) {
  axisService = new AxisService(serviceName);
  }
 
  axisService.setParent(serviceGroup);
  axisService.setClassLoader(serviceClassLoader);
 
  ServiceBuilder serviceBuilder = new
  ServiceBuilder(configContext, axisService);
  AxisService service =
  serviceBuilder.populateService(rootElement);
 
  ArrayList serviceList = new ArrayList();
  serviceList.add(service);
  return serviceList;
  } else if (TAG_SERVICE_GROUP.equals(elementName)) {
  ServiceGroupBuilder groupBuilder = new
  ServiceGroupBuilder(rootElement, servicesMap,
  configContext);
  ArrayList servicList =
  groupBuilder.populateServiceGroup(serviceGroup);
  Iterator serviceIterator = servicList.iterator();
  while (serviceIterator.hasNext()) {
  AxisService axisService = (AxisService)
  serviceIterator.next();
  String wsdlLocation = META-INF/service.wsdl;
  InputStream wsdlStream =
 
  serviceClassLoader.getResourceAsStream(wsdlLocation);
  URL wsdlURL =
  serviceClassLoader.getResource(wsdlLocation);
  if (wsdlStream == null) {
  wsdlLocation = META-INF/ + serviceName +
 .wsdl;
  wsdlStream = serviceClassLoader
  .getResourceAsStream(wsdlLocation);
  wsdlURL =
 
  serviceClassLoader.getResource(wsdlLocation);
  }
  if (wsdlStream != null) {
  WSDL11ToAxisServiceBuilder
 wsdl2AxisServiceBuilder
  =
  new
 WSDL11ToAxisServiceBuilder(wsdlStream,
  axisService);
  File file = Utils.toFile(servicesURL);
  if (file != null  file.exists()) {
 
 wsdl2AxisServiceBuilder.setCustomWSDLResolver(
  new AARBasedWSDLLocator(wsdlLocation,
  file, wsdlStream));
  wsdl2AxisServiceBuilder.setCustomResolver(
  new AARFileBasedURIResolver(file));
  }
  if (wsdlURL != null) {
 
  wsdl2AxisServiceBuilder.setDocumentBaseUri(wsdlURL.toString());
  }
  axisService =
  wsdl2AxisServiceBuilder.populateService();
  axisService.setWsdlFound(true);
  axisService.setCustomWsdl(true);
  // Set the default message receiver for the
  operations that were
  // not listed in the services.xml
  Iterator operations =
 axisService.getOperations();
  while (operations.hasNext()) {
  AxisOperation operation = (AxisOperation)
  operations.next();
  if (operation.getMessageReceiver() == null) {
 
  operation.setMessageReceiver(loadDefaultMessageReceiver(
 
  operation.getMessageExchangePattern(), axisService));
  }
  }
  }
  }
  return servicList;
  }
  } catch (IOException e) {
  throw new DeploymentException(e);
  } catch (XMLStreamException e) {
  throw new DeploymentException(e);
  }
  return null;
  }
 
  does this answer your question?
  Martin
  __
 
 
   Date: Tue, 22 Jul 2014 07:56:55 +1000
   Subject: Re: maven-dependency-plugin unpacking aar format?
   From: william.fergu...@xandar.com.au
   To: users@maven.apache.org
  
   David, what the use case for unpacking the AAR?
  
  
   William
  
  
   On Tue, Jul 22

Re: maven-dependency-plugin unpacking aar format?

[William Ferguson]

);
   } catch (XMLStreamException e) {
   throw new DeploymentException(e);
   }
   return null;
   }
  
   does this answer your question?
   Martin
   __
  
  
Date: Tue, 22 Jul 2014 07:56:55 +1000
Subject: Re: maven-dependency-plugin unpacking aar format?
From: william.fergu...@xandar.com.au
To: users@maven.apache.org
   
David, what the use case for unpacking the AAR?
   
   
William
   
   
On Tue, Jul 22, 2014 at 7:27 AM, David Hoffer dhoff...@gmail.com
   wrote:
   
 Here is a simplified project showing my use-case, I hope this
 helps.
Note
 I'm using unpack-dependencies as the aar is a module in the same
   project;
 however I assume the same problem exists with unpack, if that's the
   case
 that would make the test project even simpler.

 ?xml version=1.0 encoding=UTF-8?

 project xmlns=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;

 modelVersion4.0.0/modelVersion

 groupIdcom.company.project/groupId
 artifactIdservice/artifactId
 version1.0-SNAPSHOT/version

 packagingpom/packaging

 dependencies
 !--note: maven-dependency-plug fails reporting that aar is
  not
 supported--
 dependency
 groupIdcom.company.project/groupId
 artifactIdaxis-service/artifactId
 typeaar/type
 version1.0-SNAPSHOT/version
 /dependency
 !--note: I assume it will have the same problem unpacking
 a
   public
 artifact such as this--
 dependency
 groupIdcom.helpshift/groupId
 artifactIdandroid-aar/artifactId
 version3.4.2/version
 typeaar/type
 /dependency
 /dependencies

 build
 plugins
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 executions
 execution
 idunpack-axis-service/id
 phasegenerate-resources/phase
 goals
 goalunpack-dependencies/goal
 /goals
 configuration

 includeArtifactIdsaxis-service/includeArtifactIds



  
 
 outputDirectory${project.build.directory}/generated-resources/axis/outputDirectory

  overWriteReleasestrue/overWriteReleases

   overWriteSnapshotstrue/overWriteSnapshots

 includesMETA-INF/*.wsdl,META-INF/schema/**/*.xsd/includes
 /configuration
 /execution
 /executions
 /plugin
 /plugins
 /build

 /project



 On Mon, Jul 21, 2014 at 3:05 PM, Karl Heinz Marbaise 
   khmarba...@gmx.de
 wrote:

  HI David,
 
 
 
   I'm getting the following error trying to unpack some files
 from
  an
 aar.
 
Is this not supported?  Is there any way to do this?
 
  Failed to execute goal
 
  
 org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack-dependencies
  (unpack-service) on project service: Unknown archiver type: No
  such
  archiver: 'aar'. - [Help 1]
 
 
  Could you please prepare a example project which reproduces the
  problem..so i can create a JIRA issue for this...
 
  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 unpacking aar format?

[David Hoffer]

(
   
operation.getMessageExchangePattern(), axisService));
}
}
}
}
return servicList;
}
} catch (IOException e) {
throw new DeploymentException(e);
} catch (XMLStreamException e) {
throw new DeploymentException(e);
}
return null;
}
   
does this answer your question?
Martin
__
   
   
 Date: Tue, 22 Jul 2014 07:56:55 +1000
 Subject: Re: maven-dependency-plugin unpacking aar format?
 From: william.fergu...@xandar.com.au
 To: users@maven.apache.org

 David, what the use case for unpacking the AAR?


 William


 On Tue, Jul 22, 2014 at 7:27 AM, David Hoffer dhoff...@gmail.com
wrote:

  Here is a simplified project showing my use-case, I hope this
  helps.
 Note
  I'm using unpack-dependencies as the aar is a module in the same
project;
  however I assume the same problem exists with unpack, if that's
 the
case
  that would make the test project even simpler.
 
  ?xml version=1.0 encoding=UTF-8?
 
  project xmlns=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;
 
  modelVersion4.0.0/modelVersion
 
  groupIdcom.company.project/groupId
  artifactIdservice/artifactId
  version1.0-SNAPSHOT/version
 
  packagingpom/packaging
 
  dependencies
  !--note: maven-dependency-plug fails reporting that aar
 is
   not
  supported--
  dependency
  groupIdcom.company.project/groupId
  artifactIdaxis-service/artifactId
  typeaar/type
  version1.0-SNAPSHOT/version
  /dependency
  !--note: I assume it will have the same problem
 unpacking
  a
public
  artifact such as this--
  dependency
  groupIdcom.helpshift/groupId
  artifactIdandroid-aar/artifactId
  version3.4.2/version
  typeaar/type
  /dependency
  /dependencies
 
  build
  plugins
  plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-dependency-plugin/artifactId
  executions
  execution
  idunpack-axis-service/id
  phasegenerate-resources/phase
  goals
  goalunpack-dependencies/goal
  /goals
  configuration
 
  includeArtifactIdsaxis-service/includeArtifactIds
 
 
 
   
  
 
 outputDirectory${project.build.directory}/generated-resources/axis/outputDirectory
 
   overWriteReleasestrue/overWriteReleases
 
overWriteSnapshotstrue/overWriteSnapshots
 
  includesMETA-INF/*.wsdl,META-INF/schema/**/*.xsd/includes
  /configuration
  /execution
  /executions
  /plugin
  /plugins
  /build
 
  /project
 
 
 
  On Mon, Jul 21, 2014 at 3:05 PM, Karl Heinz Marbaise 
khmarba...@gmx.de
  wrote:
 
   HI David,
  
  
  
I'm getting the following error trying to unpack some files
  from
   an
  aar.
  
 Is this not supported?  Is there any way to do this?
  
   Failed to execute goal
  
   
  org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack-dependencies
   (unpack-service) on project service: Unknown archiver type: No
   such
   archiver: 'aar'. - [Help 1]
  
  
   Could you please prepare a example project which reproduces the
   problem..so i can create a JIRA issue for this...
  
   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 unpacking aar format?

[domi]

 = META-INF/ + serviceName + .wsdl;
wsdlStream = serviceClassLoader
.getResourceAsStream(wsdlLocation);
wsdlURL =
 serviceClassLoader.getResource(wsdlLocation);
}
if (wsdlStream != null) {
WSDL11ToAxisServiceBuilder wsdl2AxisServiceBuilder
 =
new WSDL11ToAxisServiceBuilder(wsdlStream,
 null, null);
File file = Utils.toFile(servicesURL);
if (file != null  file.exists()) {
wsdl2AxisServiceBuilder.setCustomWSDLResolver(
new AARBasedWSDLLocator(wsdlLocation,
 file, wsdlStream));
wsdl2AxisServiceBuilder.setCustomResolver(
new AARFileBasedURIResolver(file));
}
if (wsdlURL != null) {
 
 wsdl2AxisServiceBuilder.setDocumentBaseUri(wsdlURL.toString());
}
axisService =
 wsdl2AxisServiceBuilder.populateService();
axisService.setWsdlFound(true);
axisService.setCustomWsdl(true);
axisService.setName(serviceName);
}
if (axisService == null) {
axisService = new AxisService(serviceName);
}
 
axisService.setParent(serviceGroup);
axisService.setClassLoader(serviceClassLoader);
 
ServiceBuilder serviceBuilder = new
 ServiceBuilder(configContext, axisService);
AxisService service =
 serviceBuilder.populateService(rootElement);
 
ArrayList serviceList = new ArrayList();
serviceList.add(service);
return serviceList;
} else if (TAG_SERVICE_GROUP.equals(elementName)) {
ServiceGroupBuilder groupBuilder = new
 ServiceGroupBuilder(rootElement, servicesMap,
configContext);
ArrayList servicList =
 groupBuilder.populateServiceGroup(serviceGroup);
Iterator serviceIterator = servicList.iterator();
while (serviceIterator.hasNext()) {
AxisService axisService = (AxisService)
 serviceIterator.next();
String wsdlLocation = META-INF/service.wsdl;
InputStream wsdlStream =
 
 serviceClassLoader.getResourceAsStream(wsdlLocation);
URL wsdlURL =
 serviceClassLoader.getResource(wsdlLocation);
if (wsdlStream == null) {
wsdlLocation = META-INF/ + serviceName +
 .wsdl;
wsdlStream = serviceClassLoader
.getResourceAsStream(wsdlLocation);
wsdlURL =
 
 serviceClassLoader.getResource(wsdlLocation);
}
if (wsdlStream != null) {
WSDL11ToAxisServiceBuilder
 wsdl2AxisServiceBuilder
 =
new
 WSDL11ToAxisServiceBuilder(wsdlStream,
 axisService);
File file = Utils.toFile(servicesURL);
if (file != null  file.exists()) {
 
 wsdl2AxisServiceBuilder.setCustomWSDLResolver(
new
 AARBasedWSDLLocator(wsdlLocation,
 file, wsdlStream));
wsdl2AxisServiceBuilder.setCustomResolver(
new AARFileBasedURIResolver(file));
}
if (wsdlURL != null) {
 
 wsdl2AxisServiceBuilder.setDocumentBaseUri(wsdlURL.toString());
}
axisService =
 wsdl2AxisServiceBuilder.populateService();
axisService.setWsdlFound(true);
axisService.setCustomWsdl(true);
// Set the default message receiver for the
 operations that were
// not listed in the services.xml
Iterator operations =
 axisService.getOperations();
while (operations.hasNext()) {
AxisOperation operation = (AxisOperation)
 operations.next();
if (operation.getMessageReceiver() ==
 null) {
 
 operation.setMessageReceiver(loadDefaultMessageReceiver(
 
 operation.getMessageExchangePattern(), axisService));
}
}
}
}
return servicList;
}
} catch (IOException e) {
throw new DeploymentException(e);
} catch (XMLStreamException e) {
throw new DeploymentException(e);
}
return null;
}
 
 does this answer your question?
 Martin
 __
 
 
 Date: Tue, 22 Jul 2014 07:56:55 +1000
 Subject: Re: maven-dependency-plugin unpacking aar format?
 From

Re: maven-dependency-plugin unpacking aar format?

[William Ferguson]

));
 }
 }
 }
 }
 return servicList;
 }
 } catch (IOException e) {
 throw new DeploymentException(e);
 } catch (XMLStreamException e) {
 throw new DeploymentException(e);
 }
 return null;
 }
 
  does this answer your question?
  Martin
  __
 
 
  Date: Tue, 22 Jul 2014 07:56:55 +1000
  Subject: Re: maven-dependency-plugin unpacking aar format?
  From: william.fergu...@xandar.com.au
  To: users@maven.apache.org
 
  David, what the use case for unpacking the AAR?
 
 
  William
 
 
  On Tue, Jul 22, 2014 at 7:27 AM, David Hoffer dhoff...@gmail.com
  wrote:
 
  Here is a simplified project showing my use-case, I hope this
  helps.
  Note
  I'm using unpack-dependencies as the aar is a module in the same
  project;
  however I assume the same problem exists with unpack, if that's the
  case
  that would make the test project even simpler.
 
  ?xml version=1.0 encoding=UTF-8?
 
  project xmlns=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;
 
 modelVersion4.0.0/modelVersion
 
 groupIdcom.company.project/groupId
 artifactIdservice/artifactId
 version1.0-SNAPSHOT/version
 
 packagingpom/packaging
 
 dependencies
 !--note: maven-dependency-plug fails reporting that aar is
  not
  supported--
 dependency
 groupIdcom.company.project/groupId
 artifactIdaxis-service/artifactId
 typeaar/type
 version1.0-SNAPSHOT/version
 /dependency
 !--note: I assume it will have the same problem unpacking
  a
  public
  artifact such as this--
 dependency
 groupIdcom.helpshift/groupId
 artifactIdandroid-aar/artifactId
 version3.4.2/version
 typeaar/type
 /dependency
 /dependencies
 
 build
 plugins
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 executions
 execution
 idunpack-axis-service/id
 phasegenerate-resources/phase
 goals
 goalunpack-dependencies/goal
 /goals
 configuration
 
  includeArtifactIdsaxis-service/includeArtifactIds
 
 
 
 
 
 
 outputDirectory${project.build.directory}/generated-resources/axis/outputDirectory
 
  overWriteReleasestrue/overWriteReleases
 
  overWriteSnapshotstrue/overWriteSnapshots
 
  includesMETA-INF/*.wsdl,META-INF/schema/**/*.xsd/includes
 /configuration
 /execution
 /executions
 /plugin
 /plugins
 /build
 
  /project
 
 
 
  On Mon, Jul 21, 2014 at 3:05 PM, Karl Heinz Marbaise 
  khmarba...@gmx.de
  wrote:
 
  HI David,
 
 
 
  I'm getting the following error trying to unpack some files
  from
  an
  aar.
 
   Is this not supported?  Is there any way to do this?
 
  Failed to execute goal
 
 
  org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack-dependencies
  (unpack-service) on project service: Unknown archiver type: No
  such
  archiver: 'aar'. - [Help 1]
 
 
  Could you please prepare a example project which reproduces the
  problem..so i can create a JIRA issue for this...
 
  Kind regards
  Karl-Heinz Marbaise
 
 
  -
  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 unpacking aar format?

[Puncel, Robert (393J)]

()) {
 AxisOperation operation =
(AxisOperation)
  operations.next();
 if (operation.getMessageReceiver() ==
  null) {
 
  operation.setMessageReceiver(loadDefaultMessageReceiver(
 
  operation.getMessageExchangePattern(), axisService));
 }
 }
 }
 }
 return servicList;
 }
 } catch (IOException e) {
 throw new DeploymentException(e);
 } catch (XMLStreamException e) {
 throw new DeploymentException(e);
 }
 return null;
 }
 
  does this answer your question?
  Martin
  __
 
 
  Date: Tue, 22 Jul 2014 07:56:55 +1000
  Subject: Re: maven-dependency-plugin unpacking aar format?
  From: william.fergu...@xandar.com.au
  To: users@maven.apache.org
 
  David, what the use case for unpacking the AAR?
 
 
  William
 
 
  On Tue, Jul 22, 2014 at 7:27 AM, David Hoffer dhoff...@gmail.com
  wrote:
 
  Here is a simplified project showing my use-case, I hope this
  helps.
  Note
  I'm using unpack-dependencies as the aar is a module in the same
  project;
  however I assume the same problem exists with unpack, if that's
the
  case
  that would make the test project even simpler.
 
  ?xml version=1.0 encoding=UTF-8?
 
  project xmlns=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;
 
 modelVersion4.0.0/modelVersion
 
 groupIdcom.company.project/groupId
 artifactIdservice/artifactId
 version1.0-SNAPSHOT/version
 
 packagingpom/packaging
 
 dependencies
 !--note: maven-dependency-plug fails reporting that aar
is
  not
  supported--
 dependency
 groupIdcom.company.project/groupId
 artifactIdaxis-service/artifactId
 typeaar/type
 version1.0-SNAPSHOT/version
 /dependency
 !--note: I assume it will have the same problem unpacking
  a
  public
  artifact such as this--
 dependency
 groupIdcom.helpshift/groupId
 artifactIdandroid-aar/artifactId
 version3.4.2/version
 typeaar/type
 /dependency
 /dependencies
 
 build
 plugins
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 executions
 execution
 idunpack-axis-service/id
 phasegenerate-resources/phase
 goals
 goalunpack-dependencies/goal
 /goals
 configuration
 
  includeArtifactIdsaxis-service/includeArtifactIds
 
 
 
 
 
 
 
outputDirectory${project.build.directory}/generated-resources/axis/out
putDirectory
 
  overWriteReleasestrue/overWriteReleases
 
  overWriteSnapshotstrue/overWriteSnapshots
 
  includesMETA-INF/*.wsdl,META-INF/schema/**/*.xsd/includes
 /configuration
 /execution
 /executions
 /plugin
 /plugins
 /build
 
  /project
 
 
 
  On Mon, Jul 21, 2014 at 3:05 PM, Karl Heinz Marbaise 
  khmarba...@gmx.de
  wrote:
 
  HI David,
 
 
 
  I'm getting the following error trying to unpack some files
  from
  an
  aar.
 
   Is this not supported?  Is there any way to do this?
 
  Failed to execute goal
 
 
  
org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack-dependencies
  (unpack-service) on project service: Unknown archiver type: No
  such
  archiver: 'aar'. - [Help 1]
 
 
  Could you please prepare a example project which reproduces the
  problem..so i can create a JIRA issue for this...
 
  Kind regards
  Karl-Heinz Marbaise
 
 
  
-
  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




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

Re: maven-dependency-plugin unpacking aar format?

[David Hoffer]

();
  axisService.setWsdlFound(true);
  axisService.setCustomWsdl(true);
  // Set the default message receiver for the
   operations that were
  // not listed in the services.xml
  Iterator operations =
   axisService.getOperations();
  while (operations.hasNext()) {
  AxisOperation operation = (AxisOperation)
   operations.next();
  if (operation.getMessageReceiver() ==
   null) {
  
   operation.setMessageReceiver(loadDefaultMessageReceiver(
  
   operation.getMessageExchangePattern(), axisService));
  }
  }
  }
  }
  return servicList;
  }
  } catch (IOException e) {
  throw new DeploymentException(e);
  } catch (XMLStreamException e) {
  throw new DeploymentException(e);
  }
  return null;
  }
  
   does this answer your question?
   Martin
   __
  
  
   Date: Tue, 22 Jul 2014 07:56:55 +1000
   Subject: Re: maven-dependency-plugin unpacking aar format?
   From: william.fergu...@xandar.com.au
   To: users@maven.apache.org
  
   David, what the use case for unpacking the AAR?
  
  
   William
  
  
   On Tue, Jul 22, 2014 at 7:27 AM, David Hoffer dhoff...@gmail.com
   wrote:
  
   Here is a simplified project showing my use-case, I hope this
   helps.
   Note
   I'm using unpack-dependencies as the aar is a module in the same
   project;
   however I assume the same problem exists with unpack, if that's
 the
   case
   that would make the test project even simpler.
  
   ?xml version=1.0 encoding=UTF-8?
  
   project xmlns=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;
  
  modelVersion4.0.0/modelVersion
  
  groupIdcom.company.project/groupId
  artifactIdservice/artifactId
  version1.0-SNAPSHOT/version
  
  packagingpom/packaging
  
  dependencies
  !--note: maven-dependency-plug fails reporting that aar is
   not
   supported--
  dependency
  groupIdcom.company.project/groupId
  artifactIdaxis-service/artifactId
  typeaar/type
  version1.0-SNAPSHOT/version
  /dependency
  !--note: I assume it will have the same problem unpacking
   a
   public
   artifact such as this--
  dependency
  groupIdcom.helpshift/groupId
  artifactIdandroid-aar/artifactId
  version3.4.2/version
  typeaar/type
  /dependency
  /dependencies
  
  build
  plugins
  plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-dependency-plugin/artifactId
  executions
  execution
  idunpack-axis-service/id
  phasegenerate-resources/phase
  goals
  goalunpack-dependencies/goal
  /goals
  configuration
  
   includeArtifactIdsaxis-service/includeArtifactIds
  
  
  
  
  
  
 
 outputDirectory${project.build.directory}/generated-resources/axis/outputDirectory
  
   overWriteReleasestrue/overWriteReleases
  
   overWriteSnapshotstrue/overWriteSnapshots
  
   includesMETA-INF/*.wsdl,META-INF/schema/**/*.xsd/includes
  /configuration
  /execution
  /executions
  /plugin
  /plugins
  /build
  
   /project
  
  
  
   On Mon, Jul 21, 2014 at 3:05 PM, Karl Heinz Marbaise 
   khmarba...@gmx.de
   wrote:
  
   HI David,
  
  
  
   I'm getting the following error trying to unpack some files
   from
   an
   aar.
  
Is this not supported?  Is there any way to do this?
  
   Failed to execute goal
  
  
  
 org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack-dependencies
   (unpack-service) on project service: Unknown archiver type: No
   such
   archiver: 'aar'. - [Help 1]
  
  
   Could you please prepare a example project which reproduces the
   problem..so i can create a JIRA issue for this...
  
   Kind regards
   Karl-Heinz Marbaise
  
  
   -
   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 unpacking aar format?

[Karl Heinz Marbaise]

Hi Robert,

 Sorry to interject, but isn¹t the unpack goal of the 
maven-assembly-plugin

deprecated?  The documentation actually refers users to the MDP¹s unpack
capabilities:
https://maven.apache.org/plugins/maven-assembly-plugin/plugin-info.html

That page is dated from 2012, so I¹m not sure if something has changed
since it was last published.


What you mentioned is correct...the unpack goal is marked as deprecated 
and will be removed...


This page is not updated cause on the public available things have not 
being changed...


Apart from that those pages are only updated according with new released 
which has not been done yet


(new release is in preparation 2.4.1 
(http://jira.codehaus.org/browse/MASSEMBLY), but it will take some time)...


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 unpacking aar format?

[William Ferguson]

Ah well. I was just going from memory.


On Wed, Jul 23, 2014 at 1:26 AM, Karl Heinz Marbaise khmarba...@gmx.de
wrote:

 Hi Robert,


  Sorry to interject, but isn¹t the unpack goal of the
 maven-assembly-plugin

 deprecated?  The documentation actually refers users to the MDP¹s unpack
 capabilities:
 https://maven.apache.org/plugins/maven-assembly-plugin/plugin-info.html

 That page is dated from 2012, so I¹m not sure if something has changed
 since it was last published.


 What you mentioned is correct...the unpack goal is marked as deprecated
 and will be removed...

 This page is not updated cause on the public available things have not
 being changed...

 Apart from that those pages are only updated according with new released
 which has not been done yet

 (new release is in preparation 2.4.1 (http://jira.codehaus.org/
 browse/MASSEMBLY), but it will take some time)...


 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 unpacking aar format?

[Robert Scholte]

Hi,

to be able to unpack/unarchive Maven must know which Unarchiver should be  
used for this type. 'aar' is not one of the few default supported types,  
hence the exception.
The plugin responsible for packaging the aar-file should also have  
configured how to unarchive the aar-file.
In case of dependency:unpack it is quite simple: I would expect that the  
packaging plugin is configured in the pom.xml with a  
extensiontrue/extension. This way Maven can find such information.


However, I can imagine that in case of unpack-dependencies the  
aar-project.pom isn't used to detect the corresponding Unarchiver. Sounds  
like an improvement to me.


thanks,
Robert

ps. this is also an interesting usecase for the consumer-pom or the  
flatten-maven-plugin




Op Mon, 21 Jul 2014 22:40:18 +0200 schreef David Hoffer  
dhoff...@gmail.com:



I'm getting the following error trying to unpack some files from an aar.
 Is this not supported?  Is there any way to do this?

Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack-dependencies
(unpack-service) on project service: Unknown archiver type: No such
archiver: 'aar'. - [Help 1]

-Dave


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

Re: maven-dependency-plugin unpacking aar format?

[Karl Heinz Marbaise]

HI David,


 I'm getting the following error trying to unpack some files from an aar.

  Is this not supported?  Is there any way to do this?

Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack-dependencies
(unpack-service) on project service: Unknown archiver type: No such
archiver: 'aar'. - [Help 1]


Could you please prepare a example project which reproduces the 
problem..so i can create a JIRA issue for this...


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 unpacking aar format?

[Dan Tran]

this may help
http://stackoverflow.com/questions/15393110/maven-custom-archive-extension-how-do-i-use-unpack-dependencies


On Mon, Jul 21, 2014 at 2:05 PM, Karl Heinz Marbaise khmarba...@gmx.de
wrote:

 HI David,



  I'm getting the following error trying to unpack some files from an aar.

   Is this not supported?  Is there any way to do this?

 Failed to execute goal
 org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack-dependencies
 (unpack-service) on project service: Unknown archiver type: No such
 archiver: 'aar'. - [Help 1]


 Could you please prepare a example project which reproduces the
 problem..so i can create a JIRA issue for this...

 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 unpacking aar format?

[David Hoffer]

Here is a simplified project showing my use-case, I hope this helps.  Note
I'm using unpack-dependencies as the aar is a module in the same project;
however I assume the same problem exists with unpack, if that's the case
that would make the test project even simpler.

?xml version=1.0 encoding=UTF-8?

project xmlns=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;

modelVersion4.0.0/modelVersion

groupIdcom.company.project/groupId
artifactIdservice/artifactId
version1.0-SNAPSHOT/version

packagingpom/packaging

dependencies
!--note: maven-dependency-plug fails reporting that aar is not
supported--
dependency
groupIdcom.company.project/groupId
artifactIdaxis-service/artifactId
typeaar/type
version1.0-SNAPSHOT/version
/dependency
!--note: I assume it will have the same problem unpacking a public
artifact such as this--
dependency
groupIdcom.helpshift/groupId
artifactIdandroid-aar/artifactId
version3.4.2/version
typeaar/type
/dependency
/dependencies

build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idunpack-axis-service/id
phasegenerate-resources/phase
goals
goalunpack-dependencies/goal
/goals
configuration

includeArtifactIdsaxis-service/includeArtifactIds

outputDirectory${project.build.directory}/generated-resources/axis/outputDirectory
overWriteReleasestrue/overWriteReleases
overWriteSnapshotstrue/overWriteSnapshots

includesMETA-INF/*.wsdl,META-INF/schema/**/*.xsd/includes
/configuration
/execution
/executions
/plugin
/plugins
/build

/project



On Mon, Jul 21, 2014 at 3:05 PM, Karl Heinz Marbaise khmarba...@gmx.de
wrote:

 HI David,



  I'm getting the following error trying to unpack some files from an aar.

   Is this not supported?  Is there any way to do this?

 Failed to execute goal
 org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack-dependencies
 (unpack-service) on project service: Unknown archiver type: No such
 archiver: 'aar'. - [Help 1]


 Could you please prepare a example project which reproduces the
 problem..so i can create a JIRA issue for this...

 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 unpacking aar format?

[William Ferguson]

David, what the use case for unpacking the AAR?


William


On Tue, Jul 22, 2014 at 7:27 AM, David Hoffer dhoff...@gmail.com wrote:

 Here is a simplified project showing my use-case, I hope this helps.  Note
 I'm using unpack-dependencies as the aar is a module in the same project;
 however I assume the same problem exists with unpack, if that's the case
 that would make the test project even simpler.

 ?xml version=1.0 encoding=UTF-8?

 project xmlns=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;

 modelVersion4.0.0/modelVersion

 groupIdcom.company.project/groupId
 artifactIdservice/artifactId
 version1.0-SNAPSHOT/version

 packagingpom/packaging

 dependencies
 !--note: maven-dependency-plug fails reporting that aar is not
 supported--
 dependency
 groupIdcom.company.project/groupId
 artifactIdaxis-service/artifactId
 typeaar/type
 version1.0-SNAPSHOT/version
 /dependency
 !--note: I assume it will have the same problem unpacking a public
 artifact such as this--
 dependency
 groupIdcom.helpshift/groupId
 artifactIdandroid-aar/artifactId
 version3.4.2/version
 typeaar/type
 /dependency
 /dependencies

 build
 plugins
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 executions
 execution
 idunpack-axis-service/id
 phasegenerate-resources/phase
 goals
 goalunpack-dependencies/goal
 /goals
 configuration

 includeArtifactIdsaxis-service/includeArtifactIds


 outputDirectory${project.build.directory}/generated-resources/axis/outputDirectory
 overWriteReleasestrue/overWriteReleases
 overWriteSnapshotstrue/overWriteSnapshots

 includesMETA-INF/*.wsdl,META-INF/schema/**/*.xsd/includes
 /configuration
 /execution
 /executions
 /plugin
 /plugins
 /build

 /project



 On Mon, Jul 21, 2014 at 3:05 PM, Karl Heinz Marbaise khmarba...@gmx.de
 wrote:

  HI David,
 
 
 
   I'm getting the following error trying to unpack some files from an
 aar.
 
Is this not supported?  Is there any way to do this?
 
  Failed to execute goal
  org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack-dependencies
  (unpack-service) on project service: Unknown archiver type: No such
  archiver: 'aar'. - [Help 1]
 
 
  Could you please prepare a example project which reproduces the
  problem..so i can create a JIRA issue for this...
 
  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 unpacking aar format?

[David Hoffer]

It has resources specified by the includes that are needed by a different
sub-system of the build.  Some are in jars but lots are in aars too.

includesMETA-INF/*.wsdl,META-INF/schema/**/*.xsd/includes


On Mon, Jul 21, 2014 at 3:56 PM, William Ferguson 
william.fergu...@xandar.com.au wrote:

 David, what the use case for unpacking the AAR?


 William


 On Tue, Jul 22, 2014 at 7:27 AM, David Hoffer dhoff...@gmail.com wrote:

  Here is a simplified project showing my use-case, I hope this helps.
  Note
  I'm using unpack-dependencies as the aar is a module in the same project;
  however I assume the same problem exists with unpack, if that's the case
  that would make the test project even simpler.
 
  ?xml version=1.0 encoding=UTF-8?
 
  project xmlns=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;
 
  modelVersion4.0.0/modelVersion
 
  groupIdcom.company.project/groupId
  artifactIdservice/artifactId
  version1.0-SNAPSHOT/version
 
  packagingpom/packaging
 
  dependencies
  !--note: maven-dependency-plug fails reporting that aar is not
  supported--
  dependency
  groupIdcom.company.project/groupId
  artifactIdaxis-service/artifactId
  typeaar/type
  version1.0-SNAPSHOT/version
  /dependency
  !--note: I assume it will have the same problem unpacking a
 public
  artifact such as this--
  dependency
  groupIdcom.helpshift/groupId
  artifactIdandroid-aar/artifactId
  version3.4.2/version
  typeaar/type
  /dependency
  /dependencies
 
  build
  plugins
  plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-dependency-plugin/artifactId
  executions
  execution
  idunpack-axis-service/id
  phasegenerate-resources/phase
  goals
  goalunpack-dependencies/goal
  /goals
  configuration
 
  includeArtifactIdsaxis-service/includeArtifactIds
 
 
 
 outputDirectory${project.build.directory}/generated-resources/axis/outputDirectory
  overWriteReleasestrue/overWriteReleases
  overWriteSnapshotstrue/overWriteSnapshots
 
  includesMETA-INF/*.wsdl,META-INF/schema/**/*.xsd/includes
  /configuration
  /execution
  /executions
  /plugin
  /plugins
  /build
 
  /project
 
 
 
  On Mon, Jul 21, 2014 at 3:05 PM, Karl Heinz Marbaise khmarba...@gmx.de
  wrote:
 
   HI David,
  
  
  
I'm getting the following error trying to unpack some files from an
  aar.
  
 Is this not supported?  Is there any way to do this?
  
   Failed to execute goal
  
 org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack-dependencies
   (unpack-service) on project service: Unknown archiver type: No such
   archiver: 'aar'. - [Help 1]
  
  
   Could you please prepare a example project which reproduces the
   problem..so i can create a JIRA issue for this...
  
   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 unpacking aar format?

[Martin Gainty]

));
}
if (wsdlURL != null) {

wsdl2AxisServiceBuilder.setDocumentBaseUri(wsdlURL.toString());
}
axisService = wsdl2AxisServiceBuilder.populateService();
axisService.setWsdlFound(true);
axisService.setCustomWsdl(true);
axisService.setName(serviceName);
}
if (axisService == null) {
axisService = new AxisService(serviceName);
}

axisService.setParent(serviceGroup);
axisService.setClassLoader(serviceClassLoader);

ServiceBuilder serviceBuilder = new 
ServiceBuilder(configContext, axisService);
AxisService service = 
serviceBuilder.populateService(rootElement);

ArrayList serviceList = new ArrayList();
serviceList.add(service);
return serviceList;
} else if (TAG_SERVICE_GROUP.equals(elementName)) {
ServiceGroupBuilder groupBuilder = new 
ServiceGroupBuilder(rootElement, servicesMap,
configContext);
ArrayList servicList = 
groupBuilder.populateServiceGroup(serviceGroup);
Iterator serviceIterator = servicList.iterator();
while (serviceIterator.hasNext()) {
AxisService axisService = (AxisService) 
serviceIterator.next();
String wsdlLocation = META-INF/service.wsdl;
InputStream wsdlStream =

serviceClassLoader.getResourceAsStream(wsdlLocation);
URL wsdlURL = serviceClassLoader.getResource(wsdlLocation);
if (wsdlStream == null) {
wsdlLocation = META-INF/ + serviceName + .wsdl;
wsdlStream = serviceClassLoader
.getResourceAsStream(wsdlLocation);
wsdlURL =
serviceClassLoader.getResource(wsdlLocation);
}
if (wsdlStream != null) {
WSDL11ToAxisServiceBuilder wsdl2AxisServiceBuilder =
new WSDL11ToAxisServiceBuilder(wsdlStream, 
axisService);
File file = Utils.toFile(servicesURL);
if (file != null  file.exists()) {
wsdl2AxisServiceBuilder.setCustomWSDLResolver(
new AARBasedWSDLLocator(wsdlLocation, file, 
wsdlStream));
wsdl2AxisServiceBuilder.setCustomResolver(
new AARFileBasedURIResolver(file));
}
if (wsdlURL != null) {

wsdl2AxisServiceBuilder.setDocumentBaseUri(wsdlURL.toString());
}
axisService = wsdl2AxisServiceBuilder.populateService();
axisService.setWsdlFound(true);
axisService.setCustomWsdl(true);
// Set the default message receiver for the operations 
that were
// not listed in the services.xml
Iterator operations = axisService.getOperations();
while (operations.hasNext()) {
AxisOperation operation = (AxisOperation) 
operations.next();
if (operation.getMessageReceiver() == null) {

operation.setMessageReceiver(loadDefaultMessageReceiver(
operation.getMessageExchangePattern(), 
axisService));
}
}
}
}
return servicList;
}
} catch (IOException e) {
throw new DeploymentException(e);
} catch (XMLStreamException e) {
throw new DeploymentException(e);
}
return null;
}

does this answer your question?
Martin 
__


 Date: Tue, 22 Jul 2014 07:56:55 +1000
 Subject: Re: maven-dependency-plugin unpacking aar format?
 From: william.fergu...@xandar.com.au
 To: users@maven.apache.org
 
 David, what the use case for unpacking the AAR?
 
 
 William
 
 
 On Tue, Jul 22, 2014 at 7:27 AM, David Hoffer dhoff...@gmail.com wrote:
 
  Here is a simplified project showing my use-case, I hope this helps.  Note
  I'm using unpack-dependencies as the aar is a module in the same project;
  however I assume the same problem exists with unpack, if that's the case
  that would make the test project even simpler.
 
  ?xml version=1.0 encoding=UTF-8?
 
  project xmlns=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

Re: maven-dependency-plugin unpacking aar format?

[William Ferguson]

));
 wsdl2AxisServiceBuilder.setCustomResolver(
 new AARFileBasedURIResolver(file));
 }
 if (wsdlURL != null) {

 wsdl2AxisServiceBuilder.setDocumentBaseUri(wsdlURL.toString());
 }
 axisService =
 wsdl2AxisServiceBuilder.populateService();
 axisService.setWsdlFound(true);
 axisService.setCustomWsdl(true);
 axisService.setName(serviceName);
 }
 if (axisService == null) {
 axisService = new AxisService(serviceName);
 }

 axisService.setParent(serviceGroup);
 axisService.setClassLoader(serviceClassLoader);

 ServiceBuilder serviceBuilder = new
 ServiceBuilder(configContext, axisService);
 AxisService service =
 serviceBuilder.populateService(rootElement);

 ArrayList serviceList = new ArrayList();
 serviceList.add(service);
 return serviceList;
 } else if (TAG_SERVICE_GROUP.equals(elementName)) {
 ServiceGroupBuilder groupBuilder = new
 ServiceGroupBuilder(rootElement, servicesMap,
 configContext);
 ArrayList servicList =
 groupBuilder.populateServiceGroup(serviceGroup);
 Iterator serviceIterator = servicList.iterator();
 while (serviceIterator.hasNext()) {
 AxisService axisService = (AxisService)
 serviceIterator.next();
 String wsdlLocation = META-INF/service.wsdl;
 InputStream wsdlStream =

 serviceClassLoader.getResourceAsStream(wsdlLocation);
 URL wsdlURL =
 serviceClassLoader.getResource(wsdlLocation);
 if (wsdlStream == null) {
 wsdlLocation = META-INF/ + serviceName + .wsdl;
 wsdlStream = serviceClassLoader
 .getResourceAsStream(wsdlLocation);
 wsdlURL =

 serviceClassLoader.getResource(wsdlLocation);
 }
 if (wsdlStream != null) {
 WSDL11ToAxisServiceBuilder wsdl2AxisServiceBuilder
 =
 new WSDL11ToAxisServiceBuilder(wsdlStream,
 axisService);
 File file = Utils.toFile(servicesURL);
 if (file != null  file.exists()) {
 wsdl2AxisServiceBuilder.setCustomWSDLResolver(
 new AARBasedWSDLLocator(wsdlLocation,
 file, wsdlStream));
 wsdl2AxisServiceBuilder.setCustomResolver(
 new AARFileBasedURIResolver(file));
 }
 if (wsdlURL != null) {

 wsdl2AxisServiceBuilder.setDocumentBaseUri(wsdlURL.toString());
 }
 axisService =
 wsdl2AxisServiceBuilder.populateService();
 axisService.setWsdlFound(true);
 axisService.setCustomWsdl(true);
 // Set the default message receiver for the
 operations that were
 // not listed in the services.xml
 Iterator operations = axisService.getOperations();
 while (operations.hasNext()) {
 AxisOperation operation = (AxisOperation)
 operations.next();
 if (operation.getMessageReceiver() == null) {

 operation.setMessageReceiver(loadDefaultMessageReceiver(

 operation.getMessageExchangePattern(), axisService));
 }
 }
 }
 }
 return servicList;
 }
 } catch (IOException e) {
 throw new DeploymentException(e);
 } catch (XMLStreamException e) {
 throw new DeploymentException(e);
 }
 return null;
 }

 does this answer your question?
 Martin
 __


  Date: Tue, 22 Jul 2014 07:56:55 +1000
  Subject: Re: maven-dependency-plugin unpacking aar format?
  From: william.fergu...@xandar.com.au
  To: users@maven.apache.org
 
  David, what the use case for unpacking the AAR?
 
 
  William
 
 
  On Tue, Jul 22, 2014 at 7:27 AM, David Hoffer dhoff...@gmail.com
 wrote:
 
   Here is a simplified project showing my use-case, I hope this helps.
  Note
   I'm using unpack-dependencies as the aar is a module in the same
 project;
   however I assume the same problem exists with unpack, if that's the
 case
   that would make the test project even simpler.
  
   ?xml version=1.0 encoding=UTF-8?
  
   project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
   http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
   http://maven.apache.org

Re: maven-dependency-plugin purge proper usage

[Graham Leggett]

On 12 May 2013, at 2:47 AM, Joe Osowski joe.osow...@gmail.com wrote:

 Yes, you are correct.  However, the problem with release/snapshots is that 
 maven assumes a revision in the VCS is a release.  But in reality, a release 
 is the binary built by maven.

A release is never just the binary built by maven, those are just bits, which 
can be rebuilt by maven at any time. Think of a release as something that can 
signed off, be it by a set of testers, or perhaps by someone doing due 
diligence with respect to intellectual property or license compliance, or 
perhaps as the entity that you delivered to the client. You can't sign off 
opaque bits, but you can sign off source code.

  Using snapshots with multiple snapshot dependencies introduces changes at 
 release time that a release engineer has get to right, and mistakes will get 
 made.

Exactly, and because of this all bets are off. A release in the maven world has 
a firm definition, it is a repeatable build, and a repeatable build cannot 
depend on or include any snapshot code.

  The binary that is tested needs to be the release, not a binary that gets 
 generated after the release.  For us anyway, I'm sure with fewer or no 
 snapshot dependencies it's different.

If you're creating releases with maven ideally you should be doing this with 
the maven-release-plugin. This plugin performs a comprehensive set of sanity 
checks, and if the project passes a tag is created with a unique version 
number. As a second step the plugin then builds that pristine tag (and only 
that tag) after a clean checkout, giving you the guarantee that your binary 
matches the source code precisely.

Most importantly the release plugin doesn't rely on humans following (or not 
following) a set of instructions, it is all completely automated and hands free.

Regards,
Graham
--


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

Re: maven-dependency-plugin purge proper usage

[Wayne Fay]

 the build to make sure the latest dependencies are downloaded, as we sometimes
 change the non snapshot released binaries on our local maven repository.

You do realize that this is a really bad idea, and it will eventually
bite you, right?

 [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ ambra-admin ---
 [INFO]
 [INFO] --- maven-dependency-plugin:2.7:purge-local-repository 
 (purge-local-dependencies) @ ambra-admin ---
 [WARNING] Unable to purge local repository location: 
 /home/josowski/.m2/repository/org/ambraproject
...
 Oddly, I don't see the same behavior on my Mac, only on Ubuntu.

Perhaps you have some permissions wrong or something under ~/.m2?
Since the plugin works on Mac, I'd suspect something specific to your
environment or some OS-specific problem. Can you try on another Ubuntu
system, another Linux system, or even just under a different (new)
user on the same system?

Wayne

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

Re: maven-dependency-plugin purge proper usage

[Joe Osowski]

On May 11, 2013, at 1:04 PM, Wayne Fay wayne...@gmail.com wrote:

 the build to make sure the latest dependencies are downloaded, as we 
 sometimes
 change the non snapshot released binaries on our local maven repository.
 
 You do realize that this is a really bad idea, and it will eventually
 bite you, right?

I can see why you would say that.  We do weekly internal releases, using 
snapshots introduces a lot of complexity into the release process across our 
dependencies.  This is whole other discussion however.

 [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ ambra-admin ---
 [INFO]
 [INFO] --- maven-dependency-plugin:2.7:purge-local-repository 
 (purge-local-dependencies) @ ambra-admin ---
 [WARNING] Unable to purge local repository location: 
 /home/josowski/.m2/repository/org/ambraproject
 ...
 Oddly, I don't see the same behavior on my Mac, only on Ubuntu.
 
 Perhaps you have some permissions wrong or something under ~/.m2?
 Since the plugin works on Mac, I'd suspect something specific to your
 environment or some OS-specific problem. Can you try on another Ubuntu
 system, another Linux system, or even just under a different (new)
 user on the same system?

Not a permissions thing.  Everything is owned by the user running it.


 -
 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 purge proper usage

[Graham Leggett]

On 11 May 2013, at 10:17 PM, Joe Osowski joe.osow...@gmail.com wrote:

 the build to make sure the latest dependencies are downloaded, as we 
 sometimes
 change the non snapshot released binaries on our local maven repository.
 
 You do realize that this is a really bad idea, and it will eventually
 bite you, right?
 
 I can see why you would say that.  We do weekly internal releases, using 
 snapshots introduces a lot of complexity into the release process across our 
 dependencies.

What you're doing is trying to subvert releases and turn them into snapshots, 
instead of just using snapshots exactly as they were designed.

Every new person to your project will see releases and assume they are, in 
fact, releases. Later, they will get a rude shock when they discover that what 
they thought was released code was actually snapshot code and sudden unexpected 
code changes and breakages appear. With no visible difference between a 
snapshot and a release, all bets are off.

Regards,
Graham
--


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

Re: maven-dependency-plugin purge proper usage

[Joe Osowski]

Yes, you are correct.  However, the problem with release/snapshots is that 
maven assumes a revision in the VCS is a release.  But in reality, a release is 
the binary built by maven.  Using snapshots with multiple snapshot dependencies 
introduces changes at release time that a release engineer has get to right, 
and mistakes will get made.  The binary that is tested needs to be the release, 
not a binary that gets generated after the release.  For us anyway, I'm sure 
with fewer or no snapshot dependencies it's different.

On May 11, 2013, at 2:39 PM, Graham Leggett minf...@sharp.fm wrote:

 On 11 May 2013, at 10:17 PM, Joe Osowski joe.osow...@gmail.com wrote:
 
 the build to make sure the latest dependencies are downloaded, as we 
 sometimes
 change the non snapshot released binaries on our local maven repository.
 
 You do realize that this is a really bad idea, and it will eventually
 bite you, right?
 
 I can see why you would say that.  We do weekly internal releases, using 
 snapshots introduces a lot of complexity into the release process across our 
 dependencies.
 
 What you're doing is trying to subvert releases and turn them into snapshots, 
 instead of just using snapshots exactly as they were designed.
 
 Every new person to your project will see releases and assume they are, in 
 fact, releases. Later, they will get a rude shock when they discover that 
 what they thought was released code was actually snapshot code and sudden 
 unexpected code changes and breakages appear. With no visible difference 
 between a snapshot and a release, all bets are off.
 
 Regards,
 Graham
 --
 
 
 -
 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

[virg g]

Hi,
T

On Tue, Mar 19, 2013 at 7:55 PM, Adrien Rivard adrien.riv...@gmail.comwrote:

 On Tue, Mar 19, 2013 at 1:39 PM, virg g 06v...@gmail.com wrote:

  Hi,
  Yes have added as two different artifactItems like this
  Since I have placed this in Parent POM, it was trying to copy even my
  PARENT artifact (parentProj) which is of Type POM.
  My Guess the PARENT POM is causing this issue, since its type POM, And i
  have added another section for this also as type pom, but it did not
 help.
  Is there anyaway to exclude Parent Artifact being copied?
  This is the error i am getting
  [ERROR] Failed to execute goal
  org.apache.maven.plugins:maven-dependency-plugin:
  2.7:copy (copy-installed) on project parentProj: Unable to find artifact.
  Failure to find parentProj:jar:1.1-SNAPSHOT in
  http://repo1.maven.org/maven2was cached in the local repository,
  resolution will not be reattempted
  until the update interval of central has elapsed or updates are forced
 
  This is my sample conf
 
 artifactItems
  artifactItem
  groupId${project.groupId}/groupId
 
  artifactId${project.artifactId}/artifactId
  version${project.version}/version
  typepom/type
  -
  /artifactItem
  artifactItem
  groupId${project.groupId}/groupId
 
  artifactId${project.artifactId}/artifactId
  version${project.version}/version
  typejar/type
  -
  /artifactItem
  artifactItem
  groupId${project.groupId}/groupId
 
  artifactId${project.artifactId}/artifactId
  version${project.version}/version
  typewar/type
  ---
  /artifactItem
  /artifactItems
 
 
 I was suggested something like

 executions
 execution
 idcopy-jar/id
 phasepackage/phase
 goals
 goalcopy-dependencies/goal
 /goals
 configuration
 includeTypesjar/includeTypes
 outputDirectory../../jar/outputDirectory
 /configuration
 /execution
 execution
 idcopy-war/id
 phasepackage/phase
 goals
 goalcopy-dependencies/goal
 /goals
 configuration
 includeTypeswar/includeTypes
 outputDirectory../../war/outputDirectory
 /configuration
 /execution
 /executions

 Also if I  understand it correctly the ${project*} variables are resolved
 in the context of the parent project, so not exactly what you (seems to)
 want.

 What are you trying to achieve with this ?

 On Tue, Mar 19, 2013 at 5:05 PM, Adrien Rivard adrien.riv...@gmail.com
  wrote:
 
   Hi,
   Have you try  to add two differents executions (with differents id),
 one
   for type war the others for type jar ?
  
  
   On Tue, Mar 19, 2013 at 10:51 AM, virg g 06v...@gmail.com wrote:
  
HI,
I have project which contains many modules and creates jars and wars.
  My
Build structure is parent POM has all modules. I am placing all my
   plugins
in PARENT POM to be required to to applied all child modules. My
requirement is to copy all these created jars to one location and
 wars
  to
another location. I am using maven-dependency-plugin to do this. This
  is
sample plugin. I have two issues with this.
1.  I am able to copy all the jars and wars to one folder, but not
 jars
   to
one folder and wars to another. Not able to distinguish
2. SInce i have placed this plugin in parent, along with all the jars
  and
wars, from Parent POM type is POM it is copying project.pom to this
location also. How to exclude project.pom being copied.
   
Here is my plugin. I have added 2 artifactItems one for jar and
 another
with war by mentioning TYPE as jar and war for each, also added
  excludes
and includes, nothing worked. Any solution to my problem? Really it
  would
be great help.
   
 plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.7/version
executions
execution
idcopy-installed/id
phaseinstall/phase
goals
goalcopy/goal
/goals
configuration
artifactItems
artifactItem
   
  groupId${project.groupId}/groupId
   
 artifactId${project.artifactId}/artifactId
   
  

Re: maven-dependency-plugin

[virg g]

Hi
Thank you. But this copies only the dependencies. But i want to copy all
the artifactids i.e my project build creats jars and wars, and i need to
copy all the jars with md5 to one location and wars with md5 to another
location. I used this sample code, could not understand why it is not
filtering based on types. it copies both jars and wars to same location
irrespective what type it is, it is ignoring
includeTypesjar/includeTypes, where i am doing wrong. Any help is
highly appreciated. I have added different excutions section with
includeTypes as war, it copies all the files to both the folders.
execution
idcopy-jar/id
phaseinstall/phase
goals
goalcopy/goal
/goals
configuration
includeTypesjar/includeTypes
overWritetrue/overWrite
outputDirectory../../aa/outputDirectory
artifactItems
artifactItem
groupId${project.groupId}/groupId

artifactId${project.artifactId}/artifactId
version${project.version}/version
type${project.packaging}/type
/artifactItem
/artifactItems
 /configuration
/execution

Thanks
virg





 On Tue, Mar 19, 2013 at 7:55 PM, Adrien Rivard adrien.riv...@gmail.comwrote:

 On Tue, Mar 19, 2013 at 1:39 PM, virg g 06v...@gmail.com wrote:

  Hi,
  Yes have added as two different artifactItems like this
  Since I have placed this in Parent POM, it was trying to copy even my
  PARENT artifact (parentProj) which is of Type POM.
  My Guess the PARENT POM is causing this issue, since its type POM, And i
  have added another section for this also as type pom, but it did not
 help.
  Is there anyaway to exclude Parent Artifact being copied?
  This is the error i am getting
  [ERROR] Failed to execute goal
  org.apache.maven.plugins:maven-dependency-plugin:
  2.7:copy (copy-installed) on project parentProj: Unable to find
 artifact.
  Failure to find parentProj:jar:1.1-SNAPSHOT in
  http://repo1.maven.org/maven2was cached in the local repository,
  resolution will not be reattempted
  until the update interval of central has elapsed or updates are forced
 
  This is my sample conf
 
 artifactItems
  artifactItem
 
 groupId${project.groupId}/groupId
 
  artifactId${project.artifactId}/artifactId
 
 version${project.version}/version
  typepom/type
  -
  /artifactItem
  artifactItem
 
 groupId${project.groupId}/groupId
 
  artifactId${project.artifactId}/artifactId
 
 version${project.version}/version
  typejar/type
  -
  /artifactItem
  artifactItem
 
 groupId${project.groupId}/groupId
 
  artifactId${project.artifactId}/artifactId
 
 version${project.version}/version
  typewar/type
  ---
  /artifactItem
  /artifactItems
 
 
 I was suggested something like

 executions
 execution
 idcopy-jar/id
 phasepackage/phase
 goals
 goalcopy-dependencies/goal
 /goals
 configuration
 includeTypesjar/includeTypes
 outputDirectory../../jar/outputDirectory
 /configuration
 /execution
 execution
 idcopy-war/id
 phasepackage/phase
 goals
 goalcopy-dependencies/goal
 /goals
 configuration
 includeTypeswar/includeTypes
 outputDirectory../../war/outputDirectory
 /configuration
 /execution
 /executions

 Also if I  understand it correctly the ${project*} variables are resolved
 in the context of the parent project, so not exactly what you (seems to)
 want.

 What are you trying to achieve with this ?

 On Tue, Mar 19, 2013 at 5:05 PM, Adrien Rivard adrien.riv...@gmail.com
  wrote:
 
   Hi,
   Have you try  to add two differents executions (with differents id),
 one
   for type war the others for type jar ?
  
  
   On Tue, Mar 19, 2013 at 10:51 AM, virg g 06v...@gmail.com wrote:
  
HI,
I have project which contains many modules and creates jars and
 wars.
  My
Build structure is parent POM has all modules. I am placing all my
   plugins
in PARENT POM to be required to to applied all child modules. My
requirement is to copy all these created jars to one location and
 wars
  to
another location. I am using maven-dependency-plugin to do this.
 This
  is
sample plugin. I have two issues with this.
1.  I 

Re: maven-dependency-plugin

[Adrien Rivard]

Hi,
Have you try  to add two differents executions (with differents id), one
for type war the others for type jar ?


On Tue, Mar 19, 2013 at 10:51 AM, virg g 06v...@gmail.com wrote:

 HI,
 I have project which contains many modules and creates jars and wars. My
 Build structure is parent POM has all modules. I am placing all my plugins
 in PARENT POM to be required to to applied all child modules. My
 requirement is to copy all these created jars to one location and wars to
 another location. I am using maven-dependency-plugin to do this. This is
 sample plugin. I have two issues with this.
 1.  I am able to copy all the jars and wars to one folder, but not jars to
 one folder and wars to another. Not able to distinguish
 2. SInce i have placed this plugin in parent, along with all the jars and
 wars, from Parent POM type is POM it is copying project.pom to this
 location also. How to exclude project.pom being copied.

 Here is my plugin. I have added 2 artifactItems one for jar and another
 with war by mentioning TYPE as jar and war for each, also added excludes
 and includes, nothing worked. Any solution to my problem? Really it would
 be great help.

  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 version2.7/version
 executions
 execution
 idcopy-installed/id
 phaseinstall/phase
 goals
 goalcopy/goal
 /goals
 configuration
 artifactItems
 artifactItem
 groupId${project.groupId}/groupId

  artifactId${project.artifactId}/artifactId
 version${project.version}/version
 type${project.packaging}/type
 overWritetrue/overWrite

  destFileName${project.artifactId}.${project.packaging}/destFileName
 /artifactItem
/artifactItems

  outputDirectory../../${install.jar.folder}/outputDirectory
 /configuration
 /execution
 /executions
 /plugin

 Thanks
 Virg




-- 
Adrien Rivard

RE: maven-dependency-plugin

[Martin Gainty]

so essentially you have 2 different executions which you want to trigger with 2 
different profiles 
 
http://www.thinkplexx.com/learn/howto/maven2/m2-execution/configure-default-and-alternative-executions-in-maven-pom-using-profiles

there are a number of triggers you can implement to trigger your profile:

absence or presence of a file
which maven phase you want the execution to bind to
environment variables detection
detection of OS variables
property values
 
http://maven.apache.org/settings.html#Profiles

Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.

  


 Date: Tue, 19 Mar 2013 12:35:04 +0100
 Subject: Re: maven-dependency-plugin
 From: adrien.riv...@gmail.com
 To: users@maven.apache.org
 
 Hi,
 Have you try to add two differents executions (with differents id), one
 for type war the others for type jar ?
 
 
 On Tue, Mar 19, 2013 at 10:51 AM, virg g 06v...@gmail.com wrote:
 
  HI,
  I have project which contains many modules and creates jars and wars. My
  Build structure is parent POM has all modules. I am placing all my plugins
  in PARENT POM to be required to to applied all child modules. My
  requirement is to copy all these created jars to one location and wars to
  another location. I am using maven-dependency-plugin to do this. This is
  sample plugin. I have two issues with this.
  1. I am able to copy all the jars and wars to one folder, but not jars to
  one folder and wars to another. Not able to distinguish
  2. SInce i have placed this plugin in parent, along with all the jars and
  wars, from Parent POM type is POM it is copying project.pom to this
  location also. How to exclude project.pom being copied.
 
  Here is my plugin. I have added 2 artifactItems one for jar and another
  with war by mentioning TYPE as jar and war for each, also added excludes
  and includes, nothing worked. Any solution to my problem? Really it would
  be great help.
 
  plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-dependency-plugin/artifactId
  version2.7/version
  executions
  execution
  idcopy-installed/id
  phaseinstall/phase
  goals
  goalcopy/goal
  /goals
  configuration
  artifactItems
  artifactItem
  groupId${project.groupId}/groupId
 
  artifactId${project.artifactId}/artifactId
  version${project.version}/version
  type${project.packaging}/type
  overWritetrue/overWrite
 
  destFileName${project.artifactId}.${project.packaging}/destFileName
  /artifactItem
  /artifactItems
 
  outputDirectory../../${install.jar.folder}/outputDirectory
  /configuration
  /execution
  /executions
  /plugin
 
  Thanks
  Virg
 
 
 
 
 -- 
 Adrien Rivard
  

Re: maven-dependency-plugin

[virg g]

Hi,
Yes have added as two different artifactItems like this
Since I have placed this in Parent POM, it was trying to copy even my
PARENT artifact (parentProj) which is of Type POM.
My Guess the PARENT POM is causing this issue, since its type POM, And i
have added another section for this also as type pom, but it did not help.
Is there anyaway to exclude Parent Artifact being copied?
This is the error i am getting
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:
2.7:copy (copy-installed) on project parentProj: Unable to find artifact.
Failure to find parentProj:jar:1.1-SNAPSHOT in
http://repo1.maven.org/maven2was cached in the local repository,
resolution will not be reattempted
until the update interval of central has elapsed or updates are forced

This is my sample conf

   artifactItems
artifactItem
groupId${project.groupId}/groupId

artifactId${project.artifactId}/artifactId
version${project.version}/version
typepom/type
-
/artifactItem
artifactItem
groupId${project.groupId}/groupId

artifactId${project.artifactId}/artifactId
version${project.version}/version
typejar/type
-
/artifactItem
artifactItem
groupId${project.groupId}/groupId

artifactId${project.artifactId}/artifactId
version${project.version}/version
typewar/type
---
/artifactItem
/artifactItems

On Tue, Mar 19, 2013 at 5:05 PM, Adrien Rivard adrien.riv...@gmail.comwrote:

 Hi,
 Have you try  to add two differents executions (with differents id), one
 for type war the others for type jar ?


 On Tue, Mar 19, 2013 at 10:51 AM, virg g 06v...@gmail.com wrote:

  HI,
  I have project which contains many modules and creates jars and wars. My
  Build structure is parent POM has all modules. I am placing all my
 plugins
  in PARENT POM to be required to to applied all child modules. My
  requirement is to copy all these created jars to one location and wars to
  another location. I am using maven-dependency-plugin to do this. This is
  sample plugin. I have two issues with this.
  1.  I am able to copy all the jars and wars to one folder, but not jars
 to
  one folder and wars to another. Not able to distinguish
  2. SInce i have placed this plugin in parent, along with all the jars and
  wars, from Parent POM type is POM it is copying project.pom to this
  location also. How to exclude project.pom being copied.
 
  Here is my plugin. I have added 2 artifactItems one for jar and another
  with war by mentioning TYPE as jar and war for each, also added excludes
  and includes, nothing worked. Any solution to my problem? Really it would
  be great help.
 
   plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-dependency-plugin/artifactId
  version2.7/version
  executions
  execution
  idcopy-installed/id
  phaseinstall/phase
  goals
  goalcopy/goal
  /goals
  configuration
  artifactItems
  artifactItem
  groupId${project.groupId}/groupId
 
   artifactId${project.artifactId}/artifactId
  version${project.version}/version
  type${project.packaging}/type
  overWritetrue/overWrite
 
   destFileName${project.artifactId}.${project.packaging}/destFileName
  /artifactItem
 /artifactItems
 
   outputDirectory../../${install.jar.folder}/outputDirectory
  /configuration
  /execution
  /executions
  /plugin
 
  Thanks
  Virg
 



 --
 Adrien Rivard

Re: maven-dependency-plugin

[Ron Wheeler]

I may not understand everything that you are trying to do but this looks 
like something that the assembly plug-in or the shade plug-in might 
accomplish in a more straightforward fashion.


Ron
On 19/03/2013 8:39 AM, virg g wrote:

Hi,
Yes have added as two different artifactItems like this
Since I have placed this in Parent POM, it was trying to copy even my
PARENT artifact (parentProj) which is of Type POM.
My Guess the PARENT POM is causing this issue, since its type POM, And i
have added another section for this also as type pom, but it did not help.
Is there anyaway to exclude Parent Artifact being copied?
This is the error i am getting
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:
2.7:copy (copy-installed) on project parentProj: Unable to find artifact.
Failure to find parentProj:jar:1.1-SNAPSHOT in
http://repo1.maven.org/maven2was cached in the local repository,
resolution will not be reattempted
until the update interval of central has elapsed or updates are forced

This is my sample conf

artifactItems
 artifactItem
 groupId${project.groupId}/groupId

artifactId${project.artifactId}/artifactId
 version${project.version}/version
 typepom/type
 -
 /artifactItem
 artifactItem
 groupId${project.groupId}/groupId

artifactId${project.artifactId}/artifactId
 version${project.version}/version
 typejar/type
 -
 /artifactItem
 artifactItem
 groupId${project.groupId}/groupId

artifactId${project.artifactId}/artifactId
 version${project.version}/version
 typewar/type
 ---
 /artifactItem
 /artifactItems

On Tue, Mar 19, 2013 at 5:05 PM, Adrien Rivard adrien.riv...@gmail.comwrote:


Hi,
Have you try  to add two differents executions (with differents id), one
for type war the others for type jar ?


On Tue, Mar 19, 2013 at 10:51 AM, virg g 06v...@gmail.com wrote:


HI,
I have project which contains many modules and creates jars and wars. My
Build structure is parent POM has all modules. I am placing all my

plugins

in PARENT POM to be required to to applied all child modules. My
requirement is to copy all these created jars to one location and wars to
another location. I am using maven-dependency-plugin to do this. This is
sample plugin. I have two issues with this.
1.  I am able to copy all the jars and wars to one folder, but not jars

to

one folder and wars to another. Not able to distinguish
2. SInce i have placed this plugin in parent, along with all the jars and
wars, from Parent POM type is POM it is copying project.pom to this
location also. How to exclude project.pom being copied.

Here is my plugin. I have added 2 artifactItems one for jar and another
with war by mentioning TYPE as jar and war for each, also added excludes
and includes, nothing worked. Any solution to my problem? Really it would
be great help.

  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 version2.7/version
 executions
 execution
 idcopy-installed/id
 phaseinstall/phase
 goals
 goalcopy/goal
 /goals
 configuration
 artifactItems
 artifactItem
 groupId${project.groupId}/groupId

  artifactId${project.artifactId}/artifactId
 version${project.version}/version
 type${project.packaging}/type
 overWritetrue/overWrite

  destFileName${project.artifactId}.${project.packaging}/destFileName
 /artifactItem
/artifactItems

  outputDirectory../../${install.jar.folder}/outputDirectory
 /configuration
 /execution
 /executions
 /plugin

Thanks
Virg




--
Adrien Rivard




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: 

Re: maven-dependency-plugin

[Adrien Rivard]

On Tue, Mar 19, 2013 at 1:39 PM, virg g 06v...@gmail.com wrote:

 Hi,
 Yes have added as two different artifactItems like this
 Since I have placed this in Parent POM, it was trying to copy even my
 PARENT artifact (parentProj) which is of Type POM.
 My Guess the PARENT POM is causing this issue, since its type POM, And i
 have added another section for this also as type pom, but it did not help.
 Is there anyaway to exclude Parent Artifact being copied?
 This is the error i am getting
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-dependency-plugin:
 2.7:copy (copy-installed) on project parentProj: Unable to find artifact.
 Failure to find parentProj:jar:1.1-SNAPSHOT in
 http://repo1.maven.org/maven2was cached in the local repository,
 resolution will not be reattempted
 until the update interval of central has elapsed or updates are forced

 This is my sample conf

artifactItems
 artifactItem
 groupId${project.groupId}/groupId

 artifactId${project.artifactId}/artifactId
 version${project.version}/version
 typepom/type
 -
 /artifactItem
 artifactItem
 groupId${project.groupId}/groupId

 artifactId${project.artifactId}/artifactId
 version${project.version}/version
 typejar/type
 -
 /artifactItem
 artifactItem
 groupId${project.groupId}/groupId

 artifactId${project.artifactId}/artifactId
 version${project.version}/version
 typewar/type
 ---
 /artifactItem
 /artifactItems


I was suggested something like

executions
execution
idcopy-jar/id
phasepackage/phase
goals
goalcopy-dependencies/goal
/goals
configuration
includeTypesjar/includeTypes
outputDirectory../../jar/outputDirectory
/configuration
/execution
execution
idcopy-war/id
phasepackage/phase
goals
goalcopy-dependencies/goal
/goals
configuration
includeTypeswar/includeTypes
outputDirectory../../war/outputDirectory
/configuration
/execution
/executions

Also if I  understand it correctly the ${project*} variables are resolved
in the context of the parent project, so not exactly what you (seems to)
want.

What are you trying to achieve with this ?

On Tue, Mar 19, 2013 at 5:05 PM, Adrien Rivard adrien.riv...@gmail.com
 wrote:

  Hi,
  Have you try  to add two differents executions (with differents id), one
  for type war the others for type jar ?
 
 
  On Tue, Mar 19, 2013 at 10:51 AM, virg g 06v...@gmail.com wrote:
 
   HI,
   I have project which contains many modules and creates jars and wars.
 My
   Build structure is parent POM has all modules. I am placing all my
  plugins
   in PARENT POM to be required to to applied all child modules. My
   requirement is to copy all these created jars to one location and wars
 to
   another location. I am using maven-dependency-plugin to do this. This
 is
   sample plugin. I have two issues with this.
   1.  I am able to copy all the jars and wars to one folder, but not jars
  to
   one folder and wars to another. Not able to distinguish
   2. SInce i have placed this plugin in parent, along with all the jars
 and
   wars, from Parent POM type is POM it is copying project.pom to this
   location also. How to exclude project.pom being copied.
  
   Here is my plugin. I have added 2 artifactItems one for jar and another
   with war by mentioning TYPE as jar and war for each, also added
 excludes
   and includes, nothing worked. Any solution to my problem? Really it
 would
   be great help.
  
plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-dependency-plugin/artifactId
   version2.7/version
   executions
   execution
   idcopy-installed/id
   phaseinstall/phase
   goals
   goalcopy/goal
   /goals
   configuration
   artifactItems
   artifactItem
  
 groupId${project.groupId}/groupId
  
artifactId${project.artifactId}/artifactId
  
 version${project.version}/version
   type${project.packaging}/type
   overWritetrue/overWrite
  
  
  

Re: maven-dependency-plugin 2.5 no longer honors excludes property

[Laird Nelson]

On Mon, Aug 13, 2012 at 10:41 AM, Laird Nelson ljnel...@gmail.com wrote:

 Before I file a bug, is this a known issue?


I see that it is: http://jira.codehaus.org/browse/MDEP-365

Best,
Laird

-- 
http://about.me/lairdnelson

Re: maven-dependency-plugin 2.5 no longer honors excludes property

[Ansgar Konermann]

Shouldn't there be an IT to catch this kind of regression?
Am 13.08.2012 19:41 schrieb Laird Nelson ljnel...@gmail.com:

 I think that I've noticed that the Maven dependency plugin's excludes
 property (for the unpack goal) is no longer honored.  Before I file a bug,
 is this a known issue?

 If all I do is change the version of the plugin from 2.5 to 2.4 its output
 changes to reflect the specified excludes.

 Best,
 Laird

 --
 http://about.me/lairdnelson

Re: maven dependency plugin and maven 3

[Stephen Connolly]

From what I recall, nobody has yet updated dependency:tree to query
aether's graph directly rather than go through the emulation of 2.x's API
for examining the dependency tree. When I last chatted on this with
Benjamin, he left me with the distinct impression that I should not rely on
the output of dependency:tree when run on m3 until it has been adapted to
query aether's graph more directly... But having said all that, I usually
find it good enough and it may just be some edge cases that Benjamin was
referring to, in which case I would suspect this is one of those edges.

On Sunday, 3 June 2012, Jason van Zyl wrote:

 You need to make a test case so we can reproduce it. It's impossible to
 tell whether it's you, your environment, the dependency plugin or Maven
 itself from looking at the textual output of the build.

 On Jun 3, 2012, at 11:42 AM, Anthony Dahanne wrote:

  Hello  all,
  sorry to bump ... :-(
  but I'm still having issues understanding what's wrong with the maven
  dependency plugin and maven 3...
  I attached a pom to demonstrate the problem :
  Using maven 3,
  1) do a mvn package
  2) then do a mvn
 
 org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
  -Dverbose=true   -DresolutionFuzziness=version -U
 
  You will see the following output :
  [INFO] --- maven-dependency-plugin:2.4:purge-local-repository
  (default-cli) @ pof ---
  [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
  [INFO] Skipping: pof. It cannot be resolved.
  [INFO] Nothing to do for project: net.dahanne:pof:jar:1.0.0-SNAPSHOT
 
  But I can tell you javax.servlet:servlet-api:jar:2.5 has a pom, and is
  already installed in the local maven repository.
 
  Could you guys share some light on this ? I think the maven dependency
  plugin is not working fine with maven 3 , as opposed to what the
  documentation says :
  https://cwiki.apache.org/MAVEN/maven-3x-plugin-compatibility-matrix.html
 
  Thanks,
  Anthony
 
 
  -- Forwarded message --
  From: Anthony Dahanne anthony.daha...@gmail.com javascript:;
  Date: Thu, May 31, 2012 at 5:50 PM
  Subject: maven dependency plugin and maven 3
  To: users@maven.apache.org javascript:;
 
 
  Hello all,
  I'm only using maven 3 on my machine (be it command line or m2e).
  I tried to use the maven dependency plugin on a project,
 
  mvn
 org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
  -Dverbose=true   -DresolutionFuzziness=version
 
  and it printed such warnings :
 
  [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
  [WARNING] Missing POM for org.easymock:easymock:jar:3.0
  [WARNING] Missing POM for junit:junit:jar:4.8.2
 
  before telling me that the build was successful.
  Thing is, it did not purge anything from my repo; because of those
  warnings actually; launching the same command with -X, I could see :
  [DEBUG] Verifying availability of
 
 /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom
  from []
  [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5: Error
  resolving project artifact: Could not find artifact
  javax.servlet:servlet-api:pom:2.5 for project
  javax.servlet:servlet-api:pom:2.5
  [DEBUG]   javax.servlet:servlet-api:jar:2.5:provided (selected for
 provided)
 
  and... I can tell you
 
 /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom
  exists and contains :
  project
   modelVersion4.0.0/modelVersion
   groupIdjavax.servlet/groupId
   artifactIdservlet-api/artifactId
   version2.5/version
  /project
 
  Debugging the code a little, I could notice that this goal was using
 
 org.apache.maven.artifact.resolver.DefaultArtifactResolver#resolveTransitively
  from maven-artifact-manager 2.0.9 to find the dependencies.
 
  I am wondering if this plugin failed purging my dependencies because
  it used a maven 2 library to scan the dependencies, and my local repo
  has only been built and used by mvn3 (and the repo metadata/layout
  could be different to what this plugin was expecting) ..
  Any thoughts ?
  thanks a lot in advance
  Anthony
  pom.xml
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.orgjavascript:;
  For additional commands, e-mail: users-h...@maven.apache.orgjavascript:;

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 To do two things at once is to do neither.

  -—Publilius Syrus, Roman slave, first century B.C.

RE: maven dependency plugin and maven 3

[Tim Wu T]

Do you know if there is any small tool for us to deploy the 3pp jar into nexus 
in additional to the nexus gui?

Br,
Tim



Ericsson

TIM WU
Software Designer

CBC/XIT/J
100102, China
Phone 84768153 (13153)
SMS/MMS +86 13810715183
tim.t...@ericsson.com
www.ericsson.com



This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at www.ericsson.com/email_disclaimer
-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Monday, June 04, 2012 4:10 PM
To: Maven Users List
Subject: Re: maven dependency plugin and maven 3

From what I recall, nobody has yet updated dependency:tree to query
aether's graph directly rather than go through the emulation of 2.x's API
for examining the dependency tree. When I last chatted on this with
Benjamin, he left me with the distinct impression that I should not rely on
the output of dependency:tree when run on m3 until it has been adapted to
query aether's graph more directly... But having said all that, I usually
find it good enough and it may just be some edge cases that Benjamin was
referring to, in which case I would suspect this is one of those edges.

On Sunday, 3 June 2012, Jason van Zyl wrote:

 You need to make a test case so we can reproduce it. It's impossible to
 tell whether it's you, your environment, the dependency plugin or Maven
 itself from looking at the textual output of the build.

 On Jun 3, 2012, at 11:42 AM, Anthony Dahanne wrote:

  Hello  all,
  sorry to bump ... :-(
  but I'm still having issues understanding what's wrong with the maven
  dependency plugin and maven 3...
  I attached a pom to demonstrate the problem :
  Using maven 3,
  1) do a mvn package
  2) then do a mvn
 
 org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
  -Dverbose=true   -DresolutionFuzziness=version -U
 
  You will see the following output :
  [INFO] --- maven-dependency-plugin:2.4:purge-local-repository
  (default-cli) @ pof ---
  [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
  [INFO] Skipping: pof. It cannot be resolved.
  [INFO] Nothing to do for project: net.dahanne:pof:jar:1.0.0-SNAPSHOT
 
  But I can tell you javax.servlet:servlet-api:jar:2.5 has a pom, and is
  already installed in the local maven repository.
 
  Could you guys share some light on this ? I think the maven dependency
  plugin is not working fine with maven 3 , as opposed to what the
  documentation says :
  https://cwiki.apache.org/MAVEN/maven-3x-plugin-compatibility-matrix.html
 
  Thanks,
  Anthony
 
 
  -- Forwarded message --
  From: Anthony Dahanne anthony.daha...@gmail.com javascript:;
  Date: Thu, May 31, 2012 at 5:50 PM
  Subject: maven dependency plugin and maven 3
  To: users@maven.apache.org javascript:;
 
 
  Hello all,
  I'm only using maven 3 on my machine (be it command line or m2e).
  I tried to use the maven dependency plugin on a project,
 
  mvn
 org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
  -Dverbose=true   -DresolutionFuzziness=version
 
  and it printed such warnings :
 
  [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
  [WARNING] Missing POM for org.easymock:easymock:jar:3.0
  [WARNING] Missing POM for junit:junit:jar:4.8.2
 
  before telling me that the build was successful.
  Thing is, it did not purge anything from my repo; because of those
  warnings actually; launching the same command with -X, I could see :
  [DEBUG] Verifying availability of
 
 /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom
  from []
  [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5: Error
  resolving project artifact: Could not find artifact
  javax.servlet:servlet-api:pom:2.5 for project
  javax.servlet:servlet-api:pom:2.5
  [DEBUG]   javax.servlet:servlet-api:jar:2.5:provided (selected for
 provided)
 
  and... I can tell you
 
 /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom
  exists and contains :
  project
   modelVersion4.0.0/modelVersion
   groupIdjavax.servlet/groupId
   artifactIdservlet-api/artifactId
   version2.5/version
  /project
 
  Debugging the code a little, I could notice that this goal was using
 
 org.apache.maven.artifact.resolver.DefaultArtifactResolver#resolveTransitively
  from maven-artifact-manager 2.0.9 to find the dependencies.
 
  I am wondering if this plugin failed purging my dependencies because
  it used a maven 2 library to scan the dependencies, and my local repo
  has only been built and used by mvn3 (and the repo metadata/layout
  could be different to what this plugin was expecting) ..
  Any thoughts ?
  thanks a lot in advance
  Anthony
  pom.xml
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.orgjavascript:;
  For additional commands, e-mail: users-h...@maven.apache.orgjavascript:;

 Thanks,

 Jason

Re: maven dependency plugin and maven 3

[Anders Hammar]

Please don't hijack someone else's thread. Start a new thread instead.
Also, this question is much more appropriate on the Nexus users
mailing list. This is a generic Maven mailing list.

/Anders

On Mon, Jun 4, 2012 at 11:19 AM, Tim Wu T tim.t...@ericsson.com wrote:
 Do you know if there is any small tool for us to deploy the 3pp jar into 
 nexus in additional to the nexus gui?

 Br,
 Tim



 Ericsson

 TIM WU
 Software Designer

 CBC/XIT/J
 100102, China
 Phone 84768153 (13153)
 SMS/MMS +86 13810715183
 tim.t...@ericsson.com
 www.ericsson.com



 This Communication is Confidential. We only send and receive email on the 
 basis of the terms set out at www.ericsson.com/email_disclaimer
 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Monday, June 04, 2012 4:10 PM
 To: Maven Users List
 Subject: Re: maven dependency plugin and maven 3

 From what I recall, nobody has yet updated dependency:tree to query
 aether's graph directly rather than go through the emulation of 2.x's API
 for examining the dependency tree. When I last chatted on this with
 Benjamin, he left me with the distinct impression that I should not rely on
 the output of dependency:tree when run on m3 until it has been adapted to
 query aether's graph more directly... But having said all that, I usually
 find it good enough and it may just be some edge cases that Benjamin was
 referring to, in which case I would suspect this is one of those edges.

 On Sunday, 3 June 2012, Jason van Zyl wrote:

 You need to make a test case so we can reproduce it. It's impossible to
 tell whether it's you, your environment, the dependency plugin or Maven
 itself from looking at the textual output of the build.

 On Jun 3, 2012, at 11:42 AM, Anthony Dahanne wrote:

  Hello  all,
  sorry to bump ... :-(
  but I'm still having issues understanding what's wrong with the maven
  dependency plugin and maven 3...
  I attached a pom to demonstrate the problem :
  Using maven 3,
  1) do a mvn package
  2) then do a mvn
 
 org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
  -Dverbose=true   -DresolutionFuzziness=version -U
 
  You will see the following output :
  [INFO] --- maven-dependency-plugin:2.4:purge-local-repository
  (default-cli) @ pof ---
  [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
  [INFO] Skipping: pof. It cannot be resolved.
  [INFO] Nothing to do for project: net.dahanne:pof:jar:1.0.0-SNAPSHOT
 
  But I can tell you javax.servlet:servlet-api:jar:2.5 has a pom, and is
  already installed in the local maven repository.
 
  Could you guys share some light on this ? I think the maven dependency
  plugin is not working fine with maven 3 , as opposed to what the
  documentation says :
  https://cwiki.apache.org/MAVEN/maven-3x-plugin-compatibility-matrix.html
 
  Thanks,
  Anthony
 
 
  -- Forwarded message --
  From: Anthony Dahanne anthony.daha...@gmail.com javascript:;
  Date: Thu, May 31, 2012 at 5:50 PM
  Subject: maven dependency plugin and maven 3
  To: users@maven.apache.org javascript:;
 
 
  Hello all,
  I'm only using maven 3 on my machine (be it command line or m2e).
  I tried to use the maven dependency plugin on a project,
 
  mvn
 org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
  -Dverbose=true   -DresolutionFuzziness=version
 
  and it printed such warnings :
 
  [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
  [WARNING] Missing POM for org.easymock:easymock:jar:3.0
  [WARNING] Missing POM for junit:junit:jar:4.8.2
 
  before telling me that the build was successful.
  Thing is, it did not purge anything from my repo; because of those
  warnings actually; launching the same command with -X, I could see :
  [DEBUG] Verifying availability of
 
 /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom
  from []
  [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5: Error
  resolving project artifact: Could not find artifact
  javax.servlet:servlet-api:pom:2.5 for project
  javax.servlet:servlet-api:pom:2.5
  [DEBUG]   javax.servlet:servlet-api:jar:2.5:provided (selected for
 provided)
 
  and... I can tell you
 
 /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom
  exists and contains :
  project
   modelVersion4.0.0/modelVersion
   groupIdjavax.servlet/groupId
   artifactIdservlet-api/artifactId
   version2.5/version
  /project
 
  Debugging the code a little, I could notice that this goal was using
 
 org.apache.maven.artifact.resolver.DefaultArtifactResolver#resolveTransitively
  from maven-artifact-manager 2.0.9 to find the dependencies.
 
  I am wondering if this plugin failed purging my dependencies because
  it used a maven 2 library to scan the dependencies, and my local repo
  has only been built and used by mvn3 (and the repo metadata/layout
  could be different to what this plugin was expecting) ..
  Any thoughts ?
  thanks

RE: maven dependency plugin and maven 3

[Tim Wu T]

Hi Anders,

Thanks :), my mistake.

Br,
Tim



Ericsson

TIM WU
Software Designer

CBC/XIT/J
100102, China
Phone 84768153 (13153)
SMS/MMS +86 13810715183
tim.t...@ericsson.com
www.ericsson.com



This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at www.ericsson.com/email_disclaimer

-Original Message-
From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of 
Anders Hammar
Sent: Monday, June 04, 2012 5:24 PM
To: Maven Users List
Subject: Re: maven dependency plugin and maven 3

Please don't hijack someone else's thread. Start a new thread instead.
Also, this question is much more appropriate on the Nexus users
mailing list. This is a generic Maven mailing list.

/Anders

On Mon, Jun 4, 2012 at 11:19 AM, Tim Wu T tim.t...@ericsson.com wrote:
 Do you know if there is any small tool for us to deploy the 3pp jar into 
 nexus in additional to the nexus gui?

 Br,
 Tim



 Ericsson

 TIM WU
 Software Designer

 CBC/XIT/J
 100102, China
 Phone 84768153 (13153)
 SMS/MMS +86 13810715183
 tim.t...@ericsson.com
 www.ericsson.com



 This Communication is Confidential. We only send and receive email on the 
 basis of the terms set out at www.ericsson.com/email_disclaimer
 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Monday, June 04, 2012 4:10 PM
 To: Maven Users List
 Subject: Re: maven dependency plugin and maven 3

 From what I recall, nobody has yet updated dependency:tree to query
 aether's graph directly rather than go through the emulation of 2.x's API
 for examining the dependency tree. When I last chatted on this with
 Benjamin, he left me with the distinct impression that I should not rely on
 the output of dependency:tree when run on m3 until it has been adapted to
 query aether's graph more directly... But having said all that, I usually
 find it good enough and it may just be some edge cases that Benjamin was
 referring to, in which case I would suspect this is one of those edges.

 On Sunday, 3 June 2012, Jason van Zyl wrote:

 You need to make a test case so we can reproduce it. It's impossible to
 tell whether it's you, your environment, the dependency plugin or Maven
 itself from looking at the textual output of the build.

 On Jun 3, 2012, at 11:42 AM, Anthony Dahanne wrote:

  Hello  all,
  sorry to bump ... :-(
  but I'm still having issues understanding what's wrong with the maven
  dependency plugin and maven 3...
  I attached a pom to demonstrate the problem :
  Using maven 3,
  1) do a mvn package
  2) then do a mvn
 
 org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
  -Dverbose=true   -DresolutionFuzziness=version -U
 
  You will see the following output :
  [INFO] --- maven-dependency-plugin:2.4:purge-local-repository
  (default-cli) @ pof ---
  [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
  [INFO] Skipping: pof. It cannot be resolved.
  [INFO] Nothing to do for project: net.dahanne:pof:jar:1.0.0-SNAPSHOT
 
  But I can tell you javax.servlet:servlet-api:jar:2.5 has a pom, and is
  already installed in the local maven repository.
 
  Could you guys share some light on this ? I think the maven dependency
  plugin is not working fine with maven 3 , as opposed to what the
  documentation says :
  https://cwiki.apache.org/MAVEN/maven-3x-plugin-compatibility-matrix.html
 
  Thanks,
  Anthony
 
 
  -- Forwarded message --
  From: Anthony Dahanne anthony.daha...@gmail.com javascript:;
  Date: Thu, May 31, 2012 at 5:50 PM
  Subject: maven dependency plugin and maven 3
  To: users@maven.apache.org javascript:;
 
 
  Hello all,
  I'm only using maven 3 on my machine (be it command line or m2e).
  I tried to use the maven dependency plugin on a project,
 
  mvn
 org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
  -Dverbose=true   -DresolutionFuzziness=version
 
  and it printed such warnings :
 
  [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
  [WARNING] Missing POM for org.easymock:easymock:jar:3.0
  [WARNING] Missing POM for junit:junit:jar:4.8.2
 
  before telling me that the build was successful.
  Thing is, it did not purge anything from my repo; because of those
  warnings actually; launching the same command with -X, I could see :
  [DEBUG] Verifying availability of
 
 /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom
  from []
  [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5: Error
  resolving project artifact: Could not find artifact
  javax.servlet:servlet-api:pom:2.5 for project
  javax.servlet:servlet-api:pom:2.5
  [DEBUG]   javax.servlet:servlet-api:jar:2.5:provided (selected for
 provided)
 
  and... I can tell you
 
 /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom
  exists and contains :
  project
   modelVersion4.0.0/modelVersion
   groupIdjavax.servlet/groupId
   artifactIdservlet-api

Re: maven dependency plugin and maven 3

[Anthony Dahanne]

Update !
Creating a jira for this issue, providing the same example pom,
http://jira.codehaus.org/secure/attachment/60149/pom.xml
when I tried to reproduce on a linux box, with the latest maven 3.0.4
  1) do a mvn package
  2) then do a mvn 
  org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
   -Dverbose=true   -DresolutionFuzziness=version

it actually worked as designed :


ubuntu@ubuntu-server:~/maven-issue$ /opt/apache-maven-3.0.4/bin/mvn
org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
-Dverbose=true   -DresolutionFuzziness=version
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building pof 1.0.0-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-dependency-plugin:2.4:purge-local-repository
(default-cli) @ pof ---
[WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
[WARNING] Missing POM for net.dahanne.gallery:commons-gallery:jar:2.1.0-SNAPSHOT
[INFO] Processing dependencies for project: net.dahanne:pof:jar:1.0.0-SNAPSHOT
[INFO] Processing artifact: javax.servlet:servlet-api:jar:2.5
[INFO] Deleting: /home/ubuntu/.m2/repository/javax/servlet/servlet-api/2.5
[INFO] Re-resolving.
Downloading: 
http://nexus.dahanne.net/nexus/content/repositories/snapshots/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar
Downloading: 
http://nexus.dahanne.net/nexus/content/repositories/releases/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar
Downloading: 
http://repo.maven.apache.org/maven2/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar
Downloaded: 
http://repo.maven.apache.org/maven2/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar
(103 KB at 15.9 KB/sec)
[INFO] Processing artifact:
net.dahanne.gallery:commons-gallery:jar:2.1.0-SNAPSHOT
[INFO] Deleting:
/home/ubuntu/.m2/repository/net/dahanne/gallery/commons-gallery/2.1.0-SNAPSHOT
[INFO] Re-resolving.
Downloading: 
http://nexus.dahanne.net/nexus/content/repositories/snapshots/net/dahanne/gallery/commons-gallery/2.1.0-SNAPSHOT/maven-metadata.xml
Downloading: 
http://nexus.dahanne.net/nexus/content/repositories/releases/net/dahanne/gallery/commons-gallery/2.1.0-SNAPSHOT/maven-metadata.xml
Downloaded: 
http://nexus.dahanne.net/nexus/content/repositories/snapshots/net/dahanne/gallery/commons-gallery/2.1.0-SNAPSHOT/maven-metadata.xml
(998 B at 2.1 KB/sec)
Downloading: 
http://nexus.dahanne.net/nexus/content/repositories/snapshots/net/dahanne/gallery/commons-gallery/2.1.0-SNAPSHOT/commons-gallery-2.1.0-20120525.140124-5.jar
Downloaded: 
http://nexus.dahanne.net/nexus/content/repositories/snapshots/net/dahanne/gallery/commons-gallery/2.1.0-SNAPSHOT/commons-gallery-2.1.0-20120525.140124-5.jar
(16 KB at 23.3 KB/sec)
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 17.522s
[INFO] Finished at: Mon Jun 04 09:10:33 EDT 2012
[INFO] Final Memory: 6M/14M
[INFO] 

my dependencies were deleted and re resolved !
One thing though, is that I still had those messages :
[WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
[WARNING] Missing POM for net.dahanne.gallery:commons-gallery:jar:2.1.0-SNAPSHOT
even though those 2 artifacts are existing in my local repo.
So I created  a bug in the maven dependency plugin Jira :
http://jira.codehaus.org/browse/MDEP-356
to consider the use of maven 3 dependency resolver in the maven
dependency plugin

Thanks,
Anthony


On Mon, Jun 4, 2012 at 4:09 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 From what I recall, nobody has yet updated dependency:tree to query
 aether's graph directly rather than go through the emulation of 2.x's API
 for examining the dependency tree. When I last chatted on this with
 Benjamin, he left me with the distinct impression that I should not rely on
 the output of dependency:tree when run on m3 until it has been adapted to
 query aether's graph more directly... But having said all that, I usually
 find it good enough and it may just be some edge cases that Benjamin was
 referring to, in which case I would suspect this is one of those edges.

 On Sunday, 3 June 2012, Jason van Zyl wrote:

 You need to make a test case so we can reproduce it. It's impossible to
 tell whether it's you, your environment, the dependency plugin or Maven
 itself from looking at the textual output of the build.

 On Jun 3, 2012, at 11:42 AM, Anthony Dahanne wrote:

  Hello  all,
  sorry to bump ... :-(
  but I'm still having issues understanding what's wrong with the maven
  dependency plugin and maven 3...
  I attached a pom to demonstrate the problem :
  Using maven 3,
  1) do a mvn package
  2) then do a mvn
 
 org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
  -Dverbose=true   

Re: maven dependency plugin and maven 3

[Wayne Fay]

 [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
 [WARNING] Missing POM for 
 net.dahanne.gallery:commons-gallery:jar:2.1.0-SNAPSHOT
 even though those 2 artifacts are existing in my local repo.

Have you looked at the content of those pom files to ensure they
aren't corrupted?

Wayne

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

Re: maven dependency plugin and maven 3

[Anthony Dahanne]

Hi Wayne,
you are right, running the purge  corrupted my local repo in a way :
$ ls ~/.m2/repository/javax/servlet/servlet-api/2.5/
_maven.repositories servlet-api-2.5.jar
servlet-api-2.5.jar.lastUpdated servlet-api-2.5.jar.sha1

and if I run mvn clean install just after , everything gets back to normal.
$ ls ~/.m2/repository/javax/servlet/servlet-api/2.5/
_maven.repositories servlet-api-2.5.jar.lastUpdated
servlet-api-2.5.pom servlet-api-2.5.pom.sha1
servlet-api-2.5.jar servlet-api-2.5.jar.sha1
servlet-api-2.5.pom.lastUpdated

updating the Jira,
thanks
Anthony

On Mon, Jun 4, 2012 at 10:47 AM, Wayne Fay wayne...@gmail.com wrote:
 [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
 [WARNING] Missing POM for 
 net.dahanne.gallery:commons-gallery:jar:2.1.0-SNAPSHOT
 even though those 2 artifacts are existing in my local repo.

 Have you looked at the content of those pom files to ensure they
 aren't corrupted?

 Wayne

 -
 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 and maven 3

[Jason van Zyl]

You need to make a test case so we can reproduce it. It's impossible to tell 
whether it's you, your environment, the dependency plugin or Maven itself from 
looking at the textual output of the build.

On Jun 3, 2012, at 11:42 AM, Anthony Dahanne wrote:

 Hello  all,
 sorry to bump ... :-(
 but I'm still having issues understanding what's wrong with the maven
 dependency plugin and maven 3...
 I attached a pom to demonstrate the problem :
 Using maven 3,
 1) do a mvn package
 2) then do a mvn
 org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
 -Dverbose=true   -DresolutionFuzziness=version -U
 
 You will see the following output :
 [INFO] --- maven-dependency-plugin:2.4:purge-local-repository
 (default-cli) @ pof ---
 [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
 [INFO] Skipping: pof. It cannot be resolved.
 [INFO] Nothing to do for project: net.dahanne:pof:jar:1.0.0-SNAPSHOT
 
 But I can tell you javax.servlet:servlet-api:jar:2.5 has a pom, and is
 already installed in the local maven repository.
 
 Could you guys share some light on this ? I think the maven dependency
 plugin is not working fine with maven 3 , as opposed to what the
 documentation says :
 https://cwiki.apache.org/MAVEN/maven-3x-plugin-compatibility-matrix.html
 
 Thanks,
 Anthony
 
 
 -- Forwarded message --
 From: Anthony Dahanne anthony.daha...@gmail.com
 Date: Thu, May 31, 2012 at 5:50 PM
 Subject: maven dependency plugin and maven 3
 To: users@maven.apache.org
 
 
 Hello all,
 I'm only using maven 3 on my machine (be it command line or m2e).
 I tried to use the maven dependency plugin on a project,
 
 mvn 
 org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
 -Dverbose=true   -DresolutionFuzziness=version
 
 and it printed such warnings :
 
 [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
 [WARNING] Missing POM for org.easymock:easymock:jar:3.0
 [WARNING] Missing POM for junit:junit:jar:4.8.2
 
 before telling me that the build was successful.
 Thing is, it did not purge anything from my repo; because of those
 warnings actually; launching the same command with -X, I could see :
 [DEBUG] Verifying availability of
 /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom
 from []
 [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5: Error
 resolving project artifact: Could not find artifact
 javax.servlet:servlet-api:pom:2.5 for project
 javax.servlet:servlet-api:pom:2.5
 [DEBUG]   javax.servlet:servlet-api:jar:2.5:provided (selected for provided)
 
 and... I can tell you
 /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom
 exists and contains :
 project
  modelVersion4.0.0/modelVersion
  groupIdjavax.servlet/groupId
  artifactIdservlet-api/artifactId
  version2.5/version
 /project
 
 Debugging the code a little, I could notice that this goal was using
 org.apache.maven.artifact.resolver.DefaultArtifactResolver#resolveTransitively
 from maven-artifact-manager 2.0.9 to find the dependencies.
 
 I am wondering if this plugin failed purging my dependencies because
 it used a maven 2 library to scan the dependencies, and my local repo
 has only been built and used by mvn3 (and the repo metadata/layout
 could be different to what this plugin was expecting) ..
 Any thoughts ?
 thanks a lot in advance
 Anthony
 pom.xml
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Thanks,

Jason

--
Jason van Zyl
Founder  CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

To do two things at once is to do neither.
 
 -—Publilius Syrus, Roman slave, first century B.C.

Re: maven-dependency-plugin fails when using maven's multi-thread feature

[Stephen Connolly]

the copy goal works best for dependencies outside the reactor. if your
copying dependencies from within the reactor you should use the
copy-dependencies goal instead (side effect is you will have to add the
artifacts as dependencies thus giving maven the required build ordering
info)

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 21 Nov 2011 08:54, tarand thomas.ar...@nsn.com wrote:

 I'm experieting with maven-3's multi-threading feature, as it looks
 promising. Unfortunately I have basic problems with the dependency-plugin
 (version 2.3): We are using the copy-goal, the configuration style with
 artifactItems. Whenever one of these artifacts have to be built within
 the
 same reactor, it happens that the dependent artifact has not been built
 before, and we encounter an artifact-not-found error.

 Is that a know issue with the threading feature, or do we make a mistake?

 --
 View this message in context:
 http://maven.40175.n5.nabble.com/maven-dependency-plugin-fails-when-using-maven-s-multi-thread-feature-tp5009857p5009857.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

Re: maven-dependency-plugin fails when using maven's multi-thread feature

[tarand]

Sure, this works. But please note: we have many, many usages of this usage
style of the dependency plugin. Thus it is hard work to change each and
every location. We would like to avoid that.

--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-dependency-plugin-fails-when-using-maven-s-multi-thread-feature-tp5009857p5010376.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

Re: maven-dependency-plugin fails when using maven's multi-thread feature

[Stephen Connolly]

The only way to avoid is to have the upstream modules as dependencies
of the downstream modules... IIRC I updated dependency:copy to
consider the reactor as a source of dependencies, in which case you
don't have to switch from dependency:copy to
dependency:copy-dependencies... but you will still have to add the
dependencies to your pom

On 21 November 2011 12:19, tarand thomas.ar...@nsn.com wrote:
 Sure, this works. But please note: we have many, many usages of this usage
 style of the dependency plugin. Thus it is hard work to change each and
 every location. We would like to avoid that.

 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/maven-dependency-plugin-fails-when-using-maven-s-multi-thread-feature-tp5009857p5010376.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



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

Re: maven-dependency-plugin fails when using maven's multi-thread feature

[Stephen Connolly]

FYI I recall correctly... ;-)

On 21 November 2011 12:45, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 The only way to avoid is to have the upstream modules as dependencies
 of the downstream modules... IIRC I updated dependency:copy to
 consider the reactor as a source of dependencies, in which case you
 don't have to switch from dependency:copy to
 dependency:copy-dependencies... but you will still have to add the
 dependencies to your pom

 On 21 November 2011 12:19, tarand thomas.ar...@nsn.com wrote:
 Sure, this works. But please note: we have many, many usages of this usage
 style of the dependency plugin. Thus it is hard work to change each and
 every location. We would like to avoid that.

 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/maven-dependency-plugin-fails-when-using-maven-s-multi-thread-feature-tp5009857p5010376.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




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

Re: maven-dependency-plugin uses target dir instead of artifacts from repository

[Brian Fox]

mvn site runs up to the test phase, it doesn't run the package phase, so
that's why you get just target/classes

On Mon, Apr 11, 2011 at 1:39 AM, Lucas Persson lucas.pers...@oracle.comwrote:

  But when I do mvn install on the multiprojet then I will get a JAR but
 when doing mvn site on the multiproject I get target/classes.

 That seems to be the opposite to what you have described?

 /Lucas


 On 04/08/2011 07:52 PM, Brian Fox wrote:

 It's not a hack, the plugin asks maven core to resolve the artifacts and the
 objects it gets back have file handles. In reactor builds with sibling
 dependencies, those handles point to the sibling target folder. If you do a
 compile reactor build, those handles will point to the /target/classes
 folder. IOW, this is Maven Core behavior, not the plugin.

 On Fri, Apr 8, 2011 at 3:56 AM, Anders Hammar and...@hammar.net 
 and...@hammar.net wrote:


  I believe I've run into a similar issue at some time.
 However, there are a few things you should understand:
 1. An reactor build is executed and for that to work, Maven *should* get
 artifacts from the reactor and not the repo
 2. executing mvn pmd:pmd will not install any artifacts to the local
 repository - the build lifecycle is *not* executed

 I think I basically gave up on this as I kind of think it's a hack reusing
 the sources from a different project. And it wasn't really my
 problem/project, so I told them to refactor instead. :-)
 I think that the jira ticket I filed for this is MDEP-291.

 /Anders


 On Fri, Apr 8, 2011 at 09:28, Lucas Persson lucas.pers...@oracle.com 
 lucas.pers...@oracle.comwrote:


   Hi


 I have some issues with the maven-dependency-plugin vers 2.2 under
 Maven3.

 In one project I uses the plugin to unpack a sources artifact like this:
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 executions
   execution
 idunpack-artifact-sources/id
 phasegenerate-resources/phase
 goals
   goalunpack/goal
 /goals
 configuration
   artifactItems
 artifactItem
   groupIdoracle.ucs.callcontrol/groupId
   artifactIdcallcontrolapi/artifactId
   version${project.version}/version
   classifiersources/classifier
   overWritetrue/overWrite
 /artifactItem
   /artifactItems

 outputDirectory${project.build.directory}/unpack-sources/outputDirectory
 /configuration
   /execution
 /executions
   /plugin


 This works very well when doing e.g. 'mvn install'
 But when runnning e.g. mvn pmd:pmd on the parent project (which also
 builds the artifact that this project tries to unpack)
 then the maven-dependency-plugin uses that project's target dir instead
 taking the sources jar form the repository.

  [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-dependency-plugin:2.2:unpack 
 (unpack-artifact-sources) on project javadoc: Error unpacking file: 
 /ade/aime_sdp_924164/target/oracle.ucs.callcontrol/callcontrolapi/target/classes
  to: /ade/aime_sdp_924164/target/oracle.sdp.tools/javadoc/
 target/unpack-sources


 This is very strange.

 Anyone with similar experience?

 Thanks
 Lucas


  --
 [image: Oracle] http://www.oracle.com http://www.oracle.com

 Lucas Persson | Principal Member of Technical Staff
 Phone: +4684773644 | | | Mobile: +46730946656
 Oracle Communications Platform
 ORACLE Sweden | Folkungagatan 122 | 116 30 Stockholm

 Oracle Svenska AB, Kronborgsgränd 17, S-164 28 KISTA, reg.no
 . 556254-6746
 [image: Green Oracle] http://www.oracle.com/commitment 
 http://www.oracle.com/commitment Oracle is
 committed to developing practices and products that help protect the
 environment




  --
 [image: Oracle] http://www.oracle.com
 Lucas Persson | Principal Member of Technical Staff
 Phone: +4684773644 | | | Mobile: +46730946656
 Oracle Communications Platform
 ORACLE Sweden | Folkungagatan 122 | 116 30 Stockholm

 Oracle Svenska AB, Kronborgsgränd 17, S-164 28 KISTA, reg.no. 556254-6746
 [image: Green Oracle] http://www.oracle.com/commitment Oracle is
 committed to developing practices and products that help protect the
 environment

Re: maven-dependency-plugin uses target dir instead of artifacts from repository

[Lucas Persson]

  
  
But when I do mvn install on the multiprojet then I will get a
  JAR but when doing mvn site on the multiproject I get
  target/classes.
  
  That seems to be the opposite to what you have described?
  
  /Lucas
  
  On 04/08/2011 07:52 PM, Brian Fox wrote:

  It's not a hack, the plugin asks maven core to resolve the artifacts and the
objects it gets back have file handles. In reactor builds with sibling
dependencies, those handles point to the sibling target folder. If you do a
compile reactor build, those handles will point to the /target/classes
folder. IOW, this is Maven Core behavior, not the plugin.

On Fri, Apr 8, 2011 at 3:56 AM, Anders Hammar and...@hammar.net wrote:


  
I believe I've run into a similar issue at some time.
However, there are a few things you should understand:
1. An reactor build is executed and for that to work, Maven *should* get
artifacts from the reactor and not the repo
2. executing "mvn pmd:pmd" will not install any artifacts to the local
repository - the build lifecycle is *not* executed

I think I basically gave up on this as I kind of think it's a hack reusing
the sources from a different project. And it wasn't really my
problem/project, so I told them to refactor instead. :-)
I think that the jira ticket I filed for this is MDEP-291.

/Anders


On Fri, Apr 8, 2011 at 09:28, Lucas Persson lucas.pers...@oracle.comwrote:



   Hi


I have some issues with the maven-dependency-plugin vers 2.2 under
Maven3.

In one project I uses the plugin to unpack a sources artifact like this:
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
  execution
idunpack-artifact-sources/id
phasegenerate-resources/phase
goals
  goalunpack/goal
/goals
configuration
  artifactItems
artifactItem
  groupIdoracle.ucs.callcontrol/groupId
  artifactIdcallcontrolapi/artifactId
  version${project.version}/version
  classifiersources/classifier
  overWritetrue/overWrite
/artifactItem
  /artifactItems

outputDirectory${project.build.directory}/unpack-sources/outputDirectory
/configuration
  /execution
/executions
  /plugin


This works very well when doing e.g. 'mvn install'
But when runnning e.g. mvn pmd:pmd on the parent project (which also
builds the artifact that this project tries to unpack)
then the maven-dependency-plugin uses that project's target dir instead
taking the sources jar form the repository.

 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.2:unpack (unpack-artifact-sources) on project javadoc: Error unpacking file: /ade/aime_sdp_924164/target/oracle.ucs.callcontrol/callcontrolapi/target/classes to: /ade/aime_sdp_924164/target/oracle.sdp.tools/javadoc/target/unpack-sources


This is very strange.

Anyone with similar experience?

Thanks
Lucas


 --
[image: Oracle] http://www.oracle.com
Lucas Persson | Principal Member of Technical Staff
Phone: +4684773644 | | | Mobile: +46730946656
Oracle Communications Platform
ORACLE Sweden | Folkungagatan 122 | 116 30 Stockholm

Oracle Svenska AB, Kronborgsgrnd 17, S-164 28 KISTA, reg.no. 556254-6746
[image: Green Oracle] http://www.oracle.com/commitment Oracle is
committed to developing practices and products that help protect the
environment






  
  




-- 

  
Lucas Persson | Principal Member
  of Technical Staff
  Phone: +4684773644 | | |
  Mobile: +46730946656
  
  Oracle Communications Platform
  ORACLE Sweden | Folkungagatan 122 | 116 30 Stockholm
  

Oracle Svenska AB, Kronborgsgrnd
  17, S-164 28 KISTA, reg.no. 556254-6746
  

  
Oracle is committed to developing
  practices and products that help protect the environment
  
  

  

Re: maven-dependency-plugin uses target dir instead of artifacts from repository

[Anders Hammar]

I believe I've run into a similar issue at some time.
However, there are a few things you should understand:
1. An reactor build is executed and for that to work, Maven *should* get
artifacts from the reactor and not the repo
2. executing mvn pmd:pmd will not install any artifacts to the local
repository - the build lifecycle is *not* executed

I think I basically gave up on this as I kind of think it's a hack reusing
the sources from a different project. And it wasn't really my
problem/project, so I told them to refactor instead. :-)
I think that the jira ticket I filed for this is MDEP-291.

/Anders

On Fri, Apr 8, 2011 at 09:28, Lucas Persson lucas.pers...@oracle.comwrote:

  Hi


 I have some issues with the maven-dependency-plugin vers 2.2 under Maven3.

 In one project I uses the plugin to unpack a sources artifact like this:
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 executions
   execution
 idunpack-artifact-sources/id
 phasegenerate-resources/phase
 goals
   goalunpack/goal
 /goals
 configuration
   artifactItems
 artifactItem
   groupIdoracle.ucs.callcontrol/groupId
   artifactIdcallcontrolapi/artifactId
   version${project.version}/version
   classifiersources/classifier
   overWritetrue/overWrite
 /artifactItem
   /artifactItems

 outputDirectory${project.build.directory}/unpack-sources/outputDirectory
 /configuration
   /execution
 /executions
   /plugin


 This works very well when doing e.g. 'mvn install'
 But when runnning e.g. mvn pmd:pmd on the parent project (which also builds
 the artifact that this project tries to unpack)
 then the maven-dependency-plugin uses that project's target dir instead
 taking the sources jar form the repository.

  [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-dependency-plugin:2.2:unpack 
 (unpack-artifact-sources) on project javadoc: Error unpacking file: 
 /ade/aime_sdp_924164/target/oracle.ucs.callcontrol/callcontrolapi/target/classes
  to: 
 /ade/aime_sdp_924164/target/oracle.sdp.tools/javadoc/target/unpack-sources


 This is very strange.

 Anyone with similar experience?

 Thanks
 Lucas


  --
 [image: Oracle] http://www.oracle.com
 Lucas Persson | Principal Member of Technical Staff
 Phone: +4684773644 | | | Mobile: +46730946656
 Oracle Communications Platform
 ORACLE Sweden | Folkungagatan 122 | 116 30 Stockholm

 Oracle Svenska AB, Kronborgsgränd 17, S-164 28 KISTA, reg.no. 556254-6746
 [image: Green Oracle] http://www.oracle.com/commitment Oracle is
 committed to developing practices and products that help protect the
 environment

Re: maven-dependency-plugin uses target dir instead of artifacts from repository

[Lucas Persson]

  
  
Thanks Anders
  
  I note I get the same issue for mvn site when the reports shall be
  generated.
  I can understand that during a reactor build artifacts shall be
  fetched from the build but it does not make scenes that the plugin
  tries to use target/classes when I specified a source classifier.
  
  Well I think I perhaps missuse maven here so I need to come up
  with a better solution.
  
  Cheers
  Lucas

On 04/08/2011 09:56 AM, Anders Hammar wrote:
I believe I've run into a similar issue at some time.
  However, there are a few things you should understand:
  1. An reactor build is executed and for that to work, Maven
  *should* get artifacts from the reactor and not the repo
  2. executing "mvn pmd:pmd" will not install any artifacts to the
  local repository - the build lifecycle is *not* executed
  
  I think I basically gave up on this as I kind of think it's a hack
  reusing the sources from a different project. And it wasn't really
  my problem/project, so I told them to refactor instead. :-)
  I think that the jira ticket I filed for this is MDEP-291.
  
  /Anders
  
  On Fri, Apr 8, 2011 at 09:28, Lucas
Persson lucas.pers...@oracle.com
wrote:

   Hi
  
  
  I have some issues with the maven-dependency-plugin

  vers 2.2 under Maven3.
  
  In one project I uses the plugin to unpack a sources
  artifact like this:
   plugin
  
  groupIdorg.apache.maven.plugins/groupId
  
  artifactIdmaven-dependency-plugin/artifactId
   executions
   execution
  
  idunpack-artifact-sources/id
  
  phasegenerate-resources/phase
   goals
   goalunpack/goal
   /goals
   configuration
   artifactItems
   artifactItem
  
  groupIdoracle.ucs.callcontrol/groupId
  
  artifactIdcallcontrolapi/artifactId
  
  version${project.version}/version
  
  classifiersources/classifier
  
  overWritetrue/overWrite
   /artifactItem
   /artifactItems
  
outputDirectory${project.build.directory}/unpack-sources/outputDirectory
   /configuration
   /execution
   /executions
   /plugin
  
  
  This works very well when doing e.g. 'mvn install'
  But when runnning e.g. mvn pmd:pmd on the parent
  project (which also builds the artifact that this
  project tries to unpack)
  then the maven-dependency-plugin

  uses that project's target dir instead taking the
  sources jar form the repository.


[ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.2:unpack (unpack-artifact-sources) on project javadoc: Error unpacking file: /ade/aime_sdp_924164/target/oracle.ucs.callcontrol/callcontrolapi/target/classes to: /ade/aime_sdp_924164/target/oracle.sdp.tools/javadoc/target/unpack-sources


  This is very strange.
  
  Anyone with similar experience?
  
  Thanks
  Lucas



-- 
  
  Lucas Persson | Principal Member of
Technical Staff
Phone: +4684773644 | | | Mobile: +46730946656 
Oracle Communications
Platform
ORACLE Sweden | Folkungagatan 122 | 116 30 Stockholm
  
  Oracle Svenska AB, Kronborgsgrnd
17, S-164 28 KISTA, reg.no.
556254-6746 
   Oracle is committed to developing
practices and products that help protect the environment

  

  
  


-- 
  
  Lucas Persson | Principal Member of Technical Staff
Phone: +4684773644 | | | Mobile:
+46730946656

Oracle Communications Platform
ORACLE Sweden | Folkungagatan 122 | 116 30 Stockholm
  
  Oracle Svenska AB, Kronborgsgrnd 17, S-164 28 KISTA,
reg.no. 556254-6746
  
  
  Oracle is committed to developing practices and
products that help protect the environment
  
  

  

Re: maven-dependency-plugin uses target dir instead of artifacts from repository

[Brian Fox]

It's not a hack, the plugin asks maven core to resolve the artifacts and the
objects it gets back have file handles. In reactor builds with sibling
dependencies, those handles point to the sibling target folder. If you do a
compile reactor build, those handles will point to the /target/classes
folder. IOW, this is Maven Core behavior, not the plugin.

On Fri, Apr 8, 2011 at 3:56 AM, Anders Hammar and...@hammar.net wrote:

 I believe I've run into a similar issue at some time.
 However, there are a few things you should understand:
 1. An reactor build is executed and for that to work, Maven *should* get
 artifacts from the reactor and not the repo
 2. executing mvn pmd:pmd will not install any artifacts to the local
 repository - the build lifecycle is *not* executed

 I think I basically gave up on this as I kind of think it's a hack reusing
 the sources from a different project. And it wasn't really my
 problem/project, so I told them to refactor instead. :-)
 I think that the jira ticket I filed for this is MDEP-291.

 /Anders


 On Fri, Apr 8, 2011 at 09:28, Lucas Persson lucas.pers...@oracle.comwrote:

  Hi


 I have some issues with the maven-dependency-plugin vers 2.2 under
 Maven3.

 In one project I uses the plugin to unpack a sources artifact like this:
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 executions
   execution
 idunpack-artifact-sources/id
 phasegenerate-resources/phase
 goals
   goalunpack/goal
 /goals
 configuration
   artifactItems
 artifactItem
   groupIdoracle.ucs.callcontrol/groupId
   artifactIdcallcontrolapi/artifactId
   version${project.version}/version
   classifiersources/classifier
   overWritetrue/overWrite
 /artifactItem
   /artifactItems

 outputDirectory${project.build.directory}/unpack-sources/outputDirectory
 /configuration
   /execution
 /executions
   /plugin


 This works very well when doing e.g. 'mvn install'
 But when runnning e.g. mvn pmd:pmd on the parent project (which also
 builds the artifact that this project tries to unpack)
 then the maven-dependency-plugin uses that project's target dir instead
 taking the sources jar form the repository.

  [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-dependency-plugin:2.2:unpack 
 (unpack-artifact-sources) on project javadoc: Error unpacking file: 
 /ade/aime_sdp_924164/target/oracle.ucs.callcontrol/callcontrolapi/target/classes
  to: 
 /ade/aime_sdp_924164/target/oracle.sdp.tools/javadoc/target/unpack-sources


 This is very strange.

 Anyone with similar experience?

 Thanks
 Lucas


  --
 [image: Oracle] http://www.oracle.com
 Lucas Persson | Principal Member of Technical Staff
 Phone: +4684773644 | | | Mobile: +46730946656
 Oracle Communications Platform
 ORACLE Sweden | Folkungagatan 122 | 116 30 Stockholm

 Oracle Svenska AB, Kronborgsgränd 17, S-164 28 KISTA, reg.no. 556254-6746
 [image: Green Oracle] http://www.oracle.com/commitment Oracle is
 committed to developing practices and products that help protect the
 environment

Re: maven dependency plugin exclude test dependencies

[Stephen Connolly]

http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html#excludeTransitive

On 14 December 2010 01:35, Erwin Mueller erwin.muel...@deventm.org wrote:
 Hello,

        Can I exclude test dependencies in the maven-dependency-plugin? I'm
 using this plugin to copy all dependencies to a specific directory so the
 izpack plugin can package them into an installation application. However, it
 seems the dependency plugin is also copying the test dependencies of the
 project, like junit, fest-swing-junit, etc. I like to exclude them without to
 specify each dependency explicit in the excludeGroupIds tag.

 Thank you, Erwin.
 --
 Erwin Mueller, erwin.muel...@deventm.org
 http://www.global-scaling-institute.de/

 -
 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 exclude test dependencies

[Erwin Mueller]

Hallo,

I did know about this but it's not what I want. I want to exclude all 
dependencies in the test scope. I don't want to exclude transitive 
dependencies.

But you pointed me in the documentation which I overlooked. I need 
excludeScope. Thank you.

On Tuesday 14 December 2010 11:46:23 Stephen Connolly wrote:
 http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-m
 ojo.html#excludeTransitive
 
 On 14 December 2010 01:35, Erwin Mueller erwin.muel...@deventm.org wrote:
  Hello,
  
 Can I exclude test dependencies in the maven-dependency-plugin?
  I'm using this plugin to copy all dependencies to a specific directory
  so the izpack plugin can package them into an installation application.
  However, it seems the dependency plugin is also copying the test
  dependencies of the project, like junit, fest-swing-junit, etc. I like
  to exclude them without to specify each dependency explicit in the
  excludeGroupIds tag.
  
  Thank you, Erwin.
  --
  Erwin Mueller, erwin.muel...@deventm.org
  http://www.global-scaling-institute.de/
  
  -
  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

-- 
Erwin Mueller, erwin.muel...@deventm.org
http://www.global-scaling-institute.de/

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

Re: maven-dependency-plugin 2.2 release?

[Brian Fox]

Soon. I resolved a ton of issues at ApacheCon and just ran out of time
to wrap it up. I'll be getting back to it in the next week or so.

On Wed, Dec 1, 2010 at 10:19 PM, Dan Tran dant...@gmail.com wrote:
 me too :-)

 On Wed, Dec 1, 2010 at 10:04 AM, Jim McCaskey
 jim.mccas...@pervasive.com wrote:
 Hello all,

 I ran across a problem with the maven-dependency-plugin that is already 
 fixed (actually fixed almost a year ago it seems):

 http://jira.codehaus.org/browse/MDEP-138

 I was wondering if there are any plans to release a new 
 maven-dependency-plugin?  According to Jira, there appear to be a rather 
 large number of resolved issues.

 -Jim



 -
 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



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

Re: maven-dependency-plugin 2.2 release?

[Dan Tran]

me too :-)

On Wed, Dec 1, 2010 at 10:04 AM, Jim McCaskey
jim.mccas...@pervasive.com wrote:
 Hello all,

 I ran across a problem with the maven-dependency-plugin that is already fixed 
 (actually fixed almost a year ago it seems):

 http://jira.codehaus.org/browse/MDEP-138

 I was wondering if there are any plans to release a new 
 maven-dependency-plugin?  According to Jira, there appear to be a rather 
 large number of resolved issues.

 -Jim



 -
 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: type and classifier for *-test-sources.jar?

[Justin Edelson]

type = jar
classifier = test-sources

HTH,
Justin

On Nov 12, 2010, at 9:42 AM, Andreas Sewe wrote:

 Hi all,
 
 I need to use the maven-dependency-plugin to copy a *-test-sources.jar 
 artifact. Alas, I am unable to find the proper values for the artifactItem's 
 type and classifier. I either end up copying *-sources-jar or 
 *-tests.jar, but never *-test-sources.jar. :-(
 
 Can anyone please help me with this? How to use type and/or classifier to 
 achieve the desired effect?
 
 Best wishes,
 
 Andreas
 
 -
 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: type and classifier for *-test-sources.jar?

[Andreas Sewe]

Hi Justin,


type = jar
classifier = test-sources


yes, that did the trick. Thanks :-)

Andreas

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

Re: maven-dependency-plugin (version 2.1) question

[Brian Fox]

I can say definitively that transitive was not intended for
Copy/Unpack. I wrote these goals with a very specific use case and
that was to be able to cherry-pick artifacts from this list. The
xxx-dependencies goals where intended to support transitivity.

On Wed, Sep 1, 2010 at 10:49 AM, EJ Ciramella ecirame...@casenetinc.com wrote:

 snip
 Actually, it very specifically says nothing about dependencies under
 the copy goal. It merely says artifacts. There is a difference...
 /snip

 This is why maven is so polarizing - either you love it or hate it.

 specifically saying nothing - it should be explicit...

 Thanks again all for the clarifications - I appreciate it!


 CONFIDENTIALITY NOTICE:  This e-mail and the information transmitted within 
 including any attachments is only for the recipient(s) to which it is 
 intended and may contain confidential and/or privileged material. Any review, 
 retransmission, dissemination or other use of; or taking of any action in 
 reliance upon this information by persons or entities other than the intended 
 recipient is prohibited. If you received this in error, please send the 
 e-mail back by replying to the sender and permanently delete the entire 
 message and its attachments from all computers and network systems involved 
 in its receipt.


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

RE: maven-dependency-plugin (version 2.1) question

[EJ Ciramella]

snip
Actually, it very specifically says nothing about dependencies under
the copy goal. It merely says artifacts. There is a difference...
/snip

This is why maven is so polarizing - either you love it or hate it.

specifically saying nothing - it should be explicit...

Thanks again all for the clarifications - I appreciate it!


CONFIDENTIALITY NOTICE:  This e-mail and the information transmitted within 
including any attachments is only for the recipient(s) to which it is intended 
and may contain confidential and/or privileged material. Any review, 
retransmission, dissemination or other use of; or taking of any action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, please send the e-mail 
back by replying to the sender and permanently delete the entire message and 
its attachments from all computers and network systems involved in its receipt.

Re: maven-dependency-plugin (version 2.1) question

[Anders Hammar]

You can exclude the transitive deps:
http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html#excludeTransitive

/Anders

On Tue, Aug 31, 2010 at 19:33, EJ Ciramella ecirame...@casenetinc.comwrote:

 I've noticed recently that copy-dependencies finds the transitive
 dependencies, but copy does not.

 Is this intentional?

 We'd like to NOT have to repeat a majority of the dependencies when just
 using copy as the full list of transitive dependencies is bigger than
 what's needed.


 
 CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within
 including any attachments is only for the recipient(s) to which it is
 intended and may contain confidential and/or privileged material. Any
 review, retransmission, dissemination or other use of; or taking of any
 action in reliance upon this information by persons or entities other than
 the intended recipient is prohibited. If you received this in error, please
 send the e-mail back by replying to the sender and permanently delete the
 entire message and its attachments from all computers and network systems
 involved in its receipt.

RE: maven-dependency-plugin (version 2.1) question

[EJ Ciramella]

That's the inverse of what I want.

We have this:

A  depends on   B

B  depends on   C

We're not getting C when we use the copy goal, only when we ask for ALL 
dependencies via the copy-dependencies goal.

Is this expected behavior?

-Original Message-
From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of 
Anders Hammar
Sent: Tuesday, August 31, 2010 2:26 PM
To: Maven Users List
Subject: Re: maven-dependency-plugin (version 2.1) question

You can exclude the transitive deps:
http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html#excludeTransitive

/Anders

On Tue, Aug 31, 2010 at 19:33, EJ Ciramella ecirame...@casenetinc.comwrote:

 I've noticed recently that copy-dependencies finds the transitive
 dependencies, but copy does not.

 Is this intentional?

 We'd like to NOT have to repeat a majority of the dependencies when just
 using copy as the full list of transitive dependencies is bigger than
 what's needed.


 
 CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within
 including any attachments is only for the recipient(s) to which it is
 intended and may contain confidential and/or privileged material. Any
 review, retransmission, dissemination or other use of; or taking of any
 action in reliance upon this information by persons or entities other than
 the intended recipient is prohibited. If you received this in error, please
 send the e-mail back by replying to the sender and permanently delete the
 entire message and its attachments from all computers and network systems
 involved in its receipt.


CONFIDENTIALITY NOTICE:  This e-mail and the information transmitted within 
including any attachments is only for the recipient(s) to which it is intended 
and may contain confidential and/or privileged material. Any review, 
retransmission, dissemination or other use of; or taking of any action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, please send the e-mail 
back by replying to the sender and permanently delete the entire message and 
its attachments from all computers and network systems involved in its receipt.

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

Re: maven-dependency-plugin (version 2.1) question

[Anders Hammar]

I don't think I follow. Do you want to use the copy goal and have transitive
deps included? That's not possible according to the docs. Why not use the
copy-dependencies goal?

/Anders

On Tue, Aug 31, 2010 at 21:20, EJ Ciramella ecirame...@casenetinc.comwrote:

 That's the inverse of what I want.

 We have this:

 A  depends on   B

 B  depends on   C

 We're not getting C when we use the copy goal, only when we ask for ALL
 dependencies via the copy-dependencies goal.

 Is this expected behavior?

 -Original Message-
 From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On
 Behalf Of Anders Hammar
 Sent: Tuesday, August 31, 2010 2:26 PM
 To: Maven Users List
 Subject: Re: maven-dependency-plugin (version 2.1) question

 You can exclude the transitive deps:

 http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html#excludeTransitive

 /Anders

 On Tue, Aug 31, 2010 at 19:33, EJ Ciramella ecirame...@casenetinc.com
 wrote:

  I've noticed recently that copy-dependencies finds the transitive
  dependencies, but copy does not.
 
  Is this intentional?
 
  We'd like to NOT have to repeat a majority of the dependencies when just
  using copy as the full list of transitive dependencies is bigger than
  what's needed.
 
 
  
  CONFIDENTIALITY NOTICE: This e-mail and the information transmitted
 within
  including any attachments is only for the recipient(s) to which it is
  intended and may contain confidential and/or privileged material. Any
  review, retransmission, dissemination or other use of; or taking of any
  action in reliance upon this information by persons or entities other
 than
  the intended recipient is prohibited. If you received this in error,
 please
  send the e-mail back by replying to the sender and permanently delete the
  entire message and its attachments from all computers and network systems
  involved in its receipt.
 

 CONFIDENTIALITY NOTICE:  This e-mail and the information transmitted within
 including any attachments is only for the recipient(s) to which it is
 intended and may contain confidential and/or privileged material. Any
 review, retransmission, dissemination or other use of; or taking of any
 action in reliance upon this information by persons or entities other than
 the intended recipient is prohibited. If you received this in error, please
 send the e-mail back by replying to the sender and permanently delete the
 entire message and its attachments from all computers and network systems
 involved in its receipt.

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

RE: maven-dependency-plugin (version 2.1) question

[EJ Ciramella]

I guess I didn't see it explicitly called out in the docs anywhere that the 
copy goal doesn't look up the transitive dependencies.

The full list of dependencies is rather large (I'm still sorting through things 
all marked as compile that could be provided or runtime in some cases).

Can you send along a snippet where this is explicitly called out in the 
documentation?

-Original Message-
From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of 
Anders Hammar
Sent: Tuesday, August 31, 2010 3:34 PM
To: Maven Users List
Subject: Re: maven-dependency-plugin (version 2.1) question

I don't think I follow. Do you want to use the copy goal and have transitive
deps included? That's not possible according to the docs. Why not use the
copy-dependencies goal?

/Anders

On Tue, Aug 31, 2010 at 21:20, EJ Ciramella ecirame...@casenetinc.comwrote:

 That's the inverse of what I want.

 We have this:

 A  depends on   B

 B  depends on   C

 We're not getting C when we use the copy goal, only when we ask for ALL
 dependencies via the copy-dependencies goal.

 Is this expected behavior?

 -Original Message-
 From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On
 Behalf Of Anders Hammar
 Sent: Tuesday, August 31, 2010 2:26 PM
 To: Maven Users List
 Subject: Re: maven-dependency-plugin (version 2.1) question

 You can exclude the transitive deps:

 http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html#excludeTransitive

 /Anders

 On Tue, Aug 31, 2010 at 19:33, EJ Ciramella ecirame...@casenetinc.com
 wrote:

  I've noticed recently that copy-dependencies finds the transitive
  dependencies, but copy does not.
 
  Is this intentional?
 
  We'd like to NOT have to repeat a majority of the dependencies when just
  using copy as the full list of transitive dependencies is bigger than
  what's needed.
 
 
  
  CONFIDENTIALITY NOTICE: This e-mail and the information transmitted
 within
  including any attachments is only for the recipient(s) to which it is
  intended and may contain confidential and/or privileged material. Any
  review, retransmission, dissemination or other use of; or taking of any
  action in reliance upon this information by persons or entities other
 than
  the intended recipient is prohibited. If you received this in error,
 please
  send the e-mail back by replying to the sender and permanently delete the
  entire message and its attachments from all computers and network systems
  involved in its receipt.
 

 CONFIDENTIALITY NOTICE:  This e-mail and the information transmitted within
 including any attachments is only for the recipient(s) to which it is
 intended and may contain confidential and/or privileged material. Any
 review, retransmission, dissemination or other use of; or taking of any
 action in reliance upon this information by persons or entities other than
 the intended recipient is prohibited. If you received this in error, please
 send the e-mail back by replying to the sender and permanently delete the
 entire message and its attachments from all computers and network systems
 involved in its receipt.

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



CONFIDENTIALITY NOTICE:  This e-mail and the information transmitted within 
including any attachments is only for the recipient(s) to which it is intended 
and may contain confidential and/or privileged material. Any review, 
retransmission, dissemination or other use of; or taking of any action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, please send the e-mail 
back by replying to the sender and permanently delete the entire message and 
its attachments from all computers and network systems involved in its receipt.

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