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