subject:"Re\: dependency plugin"

Re: Dependency plugin unpack plugin dependencies

2020-10-28 Thread Benjamin Marwell

Hi Alexander,

this is an old thread, but no one has replied yet.
While I think this is possible – what are you trying to achieve?
Or in other words: WHY do you need the dependencies unpacked? What do
you do with them?


Regards,
Ben

On 2020/08/19 18:23:06, Alexander Broekhuis  wrote:
> Hi all,
>
> I currently have a setup in which I have some custom artifacts that I use
> as dependencies and unpack using unpack-dependencies.
> This all works great, but now I also have a custom plugin which needs one
> of the custom artifacts as dependency. I don't see those dependencies being
> unpacked.  Is this correct, or am I doing something wrong?
>
> I know I can add the dependency as "regular" dependency as workaround, but
> I'd like to be able to define the plugin in a parent's pluginManagement
> with it's dependencies so that dependant project can enable the plugin when
> needed without having to define the dependency, or always have it being
> unpacked even if not needed.
>
> Basically my pom looks like this (meta):
>
> // Those are unpacked as expected
> 
> 
> 
>
> // Those dependencies are not unpacked
> 
> 
> 
> 
> 
> 
> 
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>

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

RE: Dependency plugin: tree, CLI substitution error

2015-05-31 Thread Dan Rollo

Hi Sander,

That was a big help! Thanks. And yes, surrounding the property in single quotes 
solved the problem. For example: -Dexcludes='${project.groupId}’ 

FWIW, the ${groupId} form did work (so I don’t think BASH was substituting the 
empty string because no such environment variable existed).

Mystery solved, not a maven issue, just my misuse of bash.

Dan


From: Sander Verhagen san...@sanderverhagen.net 
mailto:san...@sanderverhagen.net
Subject: RE: Dependency plugin: tree, CLI substitution error
Date: May 30, 2015 at 2:28:11 AM EDT
To: Maven Users List users@maven.apache.org mailto:users@maven.apache.org


Hi,


Seems like your property is interpreted by BASH, which I don't think is what 
you want.

${BLAH} is a BASH variable, mostly equivalent to $BASH. I think what you meant 
is '${BLAH}', i.e. not substituted by BASH, giving Maven a chance to 
substitute. FYI, you wouldn't want ${BLAH} either (with double quotes BASH 
will still substitute).

${BLAH.BLAH} is an invalid BASH variable, due to the period, hence its balking.

Your ${groupId} probably works in the sense that BASH doesn't complain. I 
don't think that it works in the sense that Maven substitutes it for the actual 
groupId. I don't think that it'll get the chance for that, because likely BASH 
already substitutes it for an empty string (assuming it doesn't know a groupId 
variable in your environment; not entirely sure on basis of the limited 
information given).

Hope this helps.



Sander Verhagen
[  san...@sanderverhagen.net mailto:san...@sanderverhagen.net  ]

RE: Dependency plugin: tree, CLI substitution error

2015-05-30 Thread Sander Verhagen

Hi,


Seems like your property is interpreted by BASH, which I don't think is what 
you want.

${BLAH} is a BASH variable, mostly equivalent to $BASH. I think what you meant 
is '${BLAH}', i.e. not substituted by BASH, giving Maven a chance to 
substitute. FYI, you wouldn't want ${BLAH} either (with double quotes BASH 
will still substitute).

${BLAH.BLAH} is an invalid BASH variable, due to the period, hence its balking.

Your ${groupId} probably works in the sense that BASH doesn't complain. I 
don't think that it works in the sense that Maven substitutes it for the actual 
groupId. I don't think that it'll get the chance for that, because likely BASH 
already substitutes it for an empty string (assuming it doesn't know a groupId 
variable in your environment; not entirely sure on basis of the limited 
information given).

Hope this helps.



Sander Verhagen
[  san...@sanderverhagen.net  ]

NOTICE: my e-mail address has changed. You may still e-mail me at 
verha...@sander.com but you will see me using san...@sanderverhagen.net from 
now on. Feel free to update your address book.

 -Original Message-
 From: Dan Rollo [mailto:danro...@gmail.com]
 Sent: Friday, May 29, 2015 13:32
 To: users@maven.apache.org
 Subject: Dependency plugin: tree, CLI substitution error
 
 I’m using the maven-dependency-plugin to search for SNAPSHOT
 dependencies in a multi-module project. I am filtering out dependencies
 having the same groupId as the maven project. Here’s the command I use:
 
 mvn dependency:tree -Dincludes=:::*-SNAPSHOT -
 Dexcludes=${project.groupId}
 
 Unfortunately, this command produces the error below:
 
 -bash: -Dexcludes=${project.groupId}: bad substitution
 
 
 If I use the “old”, non-prefixed property name as shown below, the command
 works fine:
 
 mvn dependency:tree -Dincludes=:::*-SNAPSHOT -Dexcludes=${groupId}
 
 
 Is this a known issue? I would expect the ${project.groupId}” to work (and I
 think this is the “preferred” property syntax, no?)
 
 The effective pom shows maven-dependency-plugin version 2.8.
 
 More info:
 mvn -version
 Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-
 12-14T12:29:23-05:00) Maven home: /Users/bhamail/devtools/apache-
 maven-3.2.5
 Java version: 1.8.0_40, vendor: Oracle Corporation Java home:
 /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre
 Default locale: en_US, platform encoding: UTF-8 OS name: mac os x,
 version: 10.10.3, arch: x86_64, family: “mac
 
 Thanks!
 Dan
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: dependency plugin fails with 9 threads

2014-05-01 Thread Kristian Rosenvold

It turns out dependency plugin is using an old version of doxia (version
1.0, latest released is 1.4) that has known thread safety issues. You
*might* be able to work around this by adding the following dependencies to
the dependency-plugin in your pom:

dependency
  groupIdorg.apache.maven.doxia/groupId
  artifactIddoxia-sink-api/artifactId
  version1.4/version
/dependency
dependency
  groupIdorg.apache.maven.doxia/groupId
  artifactIddoxia-site-renderer/artifactId
  version1.4/version
/dependency

See
http://blog.sonatype.com/2008/04/how-to-override-a-plugins-dependency-in-mavenif
you're unfamiliar about how to do this. this might work, but might
also
bug out due to some incompatibility between 1.0 and 1.4 of doxia, I did not
try.



Please file an issue under http://jira.codehaus.org/browse/MDEP


Kristian



2014-05-01 16:00 GMT+02:00 Anthony Clark anthonyclar...@gmail.com:

 Hi All,

 I'm trying to improve our build by using parallel threads (i.e. mvn -T #)

 Unfortunately I'm running into an error when I try to use more than 9
 threads on this 24 core server:

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-dependency-plugin:2.8:analyze-report
 (analyze-report)
  on project enterprise-provided: An error has occurred in Dependency
 Analysis report generation. Could not find the
  template 'org/apache/maven/doxia/siterenderer/resources/default-site.vm -
 [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
 goal org.apache.maven.plugins:maven-depen
 dency-plugin:2.8:analyze-report (analyze-report) on project
 enterprise-provided: An error has occurred in Dependenc
 y Analysis report generation.
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at

 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
 at

 org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuild
 er.java:188)
 at

 org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuild
 er.java:184)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at

 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at

 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
 occurred in Dependency Analysis report gene
 ration.
 at

 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:106)
 at

 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
 ... 11 more
 Caused by: org.apache.maven.doxia.siterenderer.RendererException: Could not
 find the template
 'org/apache/maven/doxia/siterenderer/resources/default-site.vm
 at

 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.processTemplate(DefaultSiteRenderer.java:537)
 at

 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.writeTemplate(DefaultSiteRenderer.java:508)
 at

 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.generateDocument(DefaultSiteRenderer.java:485)
 at

 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:97)
 ... 13 more
 [INFO] No sources to compile

 Has anyone run into this before?  I searched the JIRA for the dependency
 plugin and didn't find anything related to this.

 Thanks,

 Anthony Clark (sysadmin tasked with improving a build!)

Re: dependency plugin fails with 9 threads

2014-05-01 Thread Kristian Rosenvold

I fixed the problem on trunk in dependency plugin.

You should be able to modify the deps in your current version to work
around this,
but you need to mimic what I did in the actual fix:

http://svn.apache.org/viewvc?view=revisionrevision=1591759

Kristian



2014-05-01 21:25 GMT+02:00 Kristian Rosenvold kristian.rosenv...@gmail.com
:

 It turns out dependency plugin is using an old version of doxia (version
 1.0, latest released is 1.4) that has known thread safety issues. You
 *might* be able to work around this by adding the following dependencies to
 the dependency-plugin in your pom:

 dependency
   groupIdorg.apache.maven.doxia/groupId
   artifactIddoxia-sink-api/artifactId
   version1.4/version
 /dependency
 dependency
   groupIdorg.apache.maven.doxia/groupId
   artifactIddoxia-site-renderer/artifactId
   version1.4/version
 /dependency

 See
 http://blog.sonatype.com/2008/04/how-to-override-a-plugins-dependency-in-mavenif
  you're unfamiliar about how to do this. this might work, but might also
 bug out due to some incompatibility between 1.0 and 1.4 of doxia, I did not
 try.



 Please file an issue under http://jira.codehaus.org/browse/MDEP


 Kristian



 2014-05-01 16:00 GMT+02:00 Anthony Clark anthonyclar...@gmail.com:

 Hi All,

 I'm trying to improve our build by using parallel threads (i.e. mvn -T #)

 Unfortunately I'm running into an error when I try to use more than 9
 threads on this 24 core server:

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-dependency-plugin:2.8:analyze-report
 (analyze-report)
  on project enterprise-provided: An error has occurred in Dependency
 Analysis report generation. Could not find the
  template 'org/apache/maven/doxia/siterenderer/resources/default-site.vm
 -
 [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
 goal org.apache.maven.plugins:maven-depen
 dency-plugin:2.8:analyze-report (analyze-report) on project
 enterprise-provided: An error has occurred in Dependenc
 y Analysis report generation.
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at

 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
 at

 org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuild
 er.java:188)
 at

 org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuild
 er.java:184)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at

 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at

 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
 occurred in Dependency Analysis report gene
 ration.
 at

 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:106)
 at

 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
 ... 11 more
 Caused by: org.apache.maven.doxia.siterenderer.RendererException: Could
 not
 find the template
 'org/apache/maven/doxia/siterenderer/resources/default-site.vm
 at

 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.processTemplate(DefaultSiteRenderer.java:537)
 at

 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.writeTemplate(DefaultSiteRenderer.java:508)
 at

 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.generateDocument(DefaultSiteRenderer.java:485)
 at

 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:97)
 ... 13 more
 [INFO] No sources to compile

 Has anyone run into this before?  I searched the JIRA for the dependency
 plugin and didn't find anything related to this.

 Thanks,

 Anthony Clark (sysadmin tasked with improving a build!)

Re: dependency plugin fails with 9 threads

2014-05-01 Thread Anthony Clark

Many thanks Kristian!

I am currently dealing with another emergency but as soon as that is over I
will track down the maven plugins directory and make the change.

I'll add the bug in JIRA as soon as I am able.

Thanks again!

Anthony


On Thu, May 1, 2014 at 4:08 PM, Kristian Rosenvold 
kristian.rosenv...@gmail.com wrote:

 I fixed the problem on trunk in dependency plugin.

 You should be able to modify the deps in your current version to work
 around this,
 but you need to mimic what I did in the actual fix:

 http://svn.apache.org/viewvc?view=revisionrevision=1591759

 Kristian



 2014-05-01 21:25 GMT+02:00 Kristian Rosenvold 
 kristian.rosenv...@gmail.com
 :

  It turns out dependency plugin is using an old version of doxia (version
  1.0, latest released is 1.4) that has known thread safety issues. You
  *might* be able to work around this by adding the following dependencies
 to
  the dependency-plugin in your pom:
 
  dependency
groupIdorg.apache.maven.doxia/groupId
artifactIddoxia-sink-api/artifactId
version1.4/version
  /dependency
  dependency
groupIdorg.apache.maven.doxia/groupId
artifactIddoxia-site-renderer/artifactId
version1.4/version
  /dependency
 
  See
 
 http://blog.sonatype.com/2008/04/how-to-override-a-plugins-dependency-in-mavenifyou're
  unfamiliar about how to do this. this might work, but might also
  bug out due to some incompatibility between 1.0 and 1.4 of doxia, I did
 not
  try.
 
 
 
  Please file an issue under http://jira.codehaus.org/browse/MDEP
 
 
  Kristian
 
 
 
  2014-05-01 16:00 GMT+02:00 Anthony Clark anthonyclar...@gmail.com:
 
  Hi All,
 
  I'm trying to improve our build by using parallel threads (i.e. mvn -T
 #)
 
  Unfortunately I'm running into an error when I try to use more than 9
  threads on this 24 core server:
 
  [ERROR] Failed to execute goal
  org.apache.maven.plugins:maven-dependency-plugin:2.8:analyze-report
  (analyze-report)
   on project enterprise-provided: An error has occurred in Dependency
  Analysis report generation. Could not find the
   template 'org/apache/maven/doxia/siterenderer/resources/default-site.vm
  -
  [Help 1]
  org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
 execute
  goal org.apache.maven.plugins:maven-depen
  dency-plugin:2.8:analyze-report (analyze-report) on project
  enterprise-provided: An error has occurred in Dependenc
  y Analysis report generation.
  at
 
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
  at
 
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
  at
 
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
  at
 
 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
  at
 
 
 org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuild
  er.java:188)
  at
 
 
 org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuild
  er.java:184)
  at java.util.concurrent.FutureTask.run(FutureTask.java:262)
  at
  java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
  at java.util.concurrent.FutureTask.run(FutureTask.java:262)
  at
 
 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  at
 
 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  at java.lang.Thread.run(Thread.java:745)
  Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
  occurred in Dependency Analysis report gene
  ration.
  at
 
 
 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:106)
  at
 
 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
  at
 
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
  ... 11 more
  Caused by: org.apache.maven.doxia.siterenderer.RendererException: Could
  not
  find the template
  'org/apache/maven/doxia/siterenderer/resources/default-site.vm
  at
 
 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.processTemplate(DefaultSiteRenderer.java:537)
  at
 
 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.writeTemplate(DefaultSiteRenderer.java:508)
  at
 
 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.generateDocument(DefaultSiteRenderer.java:485)
  at
 
 
 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:97)
  ... 13 more
  [INFO] No sources to compile
 
  Has anyone run into this before?  I searched the JIRA for the dependency
  plugin and didn't find anything related to this.
 
  Thanks,
 
  Anthony Clark (sysadmin tasked with improving a build!)

Re: dependency plugin automatic version resolution

2014-04-18 Thread MK Tan

Maven will use the dependency plugin from the super pom.
Which you can found at
http://maven.apache.org/ref/3.2.1/maven-model-builder/super-pom.html

On Fri, Apr 18, 2014 at 5:09 PM, Cintia Del Rio miladyarte...@gmail.comwrote:

Hi,

I was reading

http://maven.apache.org/guides/introduction/introduction-to-plugin-resolution.html
and

https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-AutomaticPluginVersionResolution

Based on that, I understood that if I call a plugin from CLI without a
version, maven will try to get the latest (and released for maven 3.x)
version available for the running maven.

I understand as well that some plugins are already bind in a certain
versionlifecycle phases.
http://maven.apache.org/ref/3.0.5/maven-core/lifecycles.html

What I don't understand is why dependency:tree is always running version
2.0 (for maven 2.1.0), version 2.1 (for maven 3.0.5) when I don't specify a
version. Maven 3.2.1 will run the latest version, 2.8.
You can see that even the latest version of the plugin requires only maven
2.0.9 (

http://svn.apache.org/viewvc/maven/plugins/tags/maven-dependency-plugin-2.8/pom.xml
).
I've checked the metadata as well, it looks fine (

http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/maven-metadata.xml
).

What lead me to think that some other plugins have the versions hardcoded
in maven. Is that correct? Where can I get the list of those plugins?

Steps to test:
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app
-DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
cd my-app
mvn dependency:tree

I removed my maven settings.xml files before testing, so I don't think it's
something local.

Cheers,

Cintia Del Rio

Re: dependency plugin automatic version resolution

2014-04-18 Thread Cintia Del Rio

It makes a lot of sense.

Cheers,

On 18 April 2014 19:20, MK Tan mktan...@gmail.com wrote:

Maven will use the dependency plugin from the super pom.
Which you can found at
http://maven.apache.org/ref/3.2.1/maven-model-builder/super-pom.html

On Fri, Apr 18, 2014 at 5:09 PM, Cintia Del Rio miladyarte...@gmail.com
wrote:

Hi,

I was reading

http://maven.apache.org/guides/introduction/introduction-to-plugin-resolution.html
and

https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-AutomaticPluginVersionResolution

Based on that, I understood that if I call a plugin from CLI without a
version, maven will try to get the latest (and released for maven 3.x)
version available for the running maven.

I understand as well that some plugins are already bind in a certain
versionlifecycle phases.
http://maven.apache.org/ref/3.0.5/maven-core/lifecycles.html

What I don't understand is why dependency:tree is always running version
2.0 (for maven 2.1.0), version 2.1 (for maven 3.0.5) when I don't
specify a
version. Maven 3.2.1 will run the latest version, 2.8.
You can see that even the latest version of the plugin requires only
maven
2.0.9 (

http://svn.apache.org/viewvc/maven/plugins/tags/maven-dependency-plugin-2.8/pom.xml
).
I've checked the metadata as well, it looks fine (

http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/maven-metadata.xml
).

What lead me to think that some other plugins have the versions
hardcoded
in maven. Is that correct? Where can I get the list of those plugins?

Steps to test:
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app
-DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
cd my-app
mvn dependency:tree

I removed my maven settings.xml files before testing, so I don't think
it's
something local.

Cheers,

Cintia Del Rio

--
---
Sent from TARDIS. Typos might be a timey whyney thingy.
Enviado da TARDIS, podem existir erros devido à diferenças de espaço-tempo.

Cintia Del Rio

Re: dependency plugin strangeness

2014-01-29 Thread Stephen Connolly

The crucial detail was omitted... what version of Maven?

I suspect it could be a transitive dependency with system scope causing a
bug of some sort.

Most likely if you switch to a different version of Maven the command will
work... in which case you might be able to construct a test case to prove a
regression.

Touchstone versions of Maven to try are: 2.2.1, 3.0.4/3.0.5 and 3.1.1

If you see the error on all three then it is something different... but
still an important data point.

More of the stack trace would help... ideally include a line or two above
and below... there is often crucial details therein... if you need to hide
GAV details, change the groupId's to something gibberish, e.g.
com.foobar:foo-manchu:1.0-SNAPSHOT and other dummy GAVs

On 28 January 2014 22:55, Lyons, Roy roy.ly...@cmegroup.com wrote:

So, I tried my google-fu first - and in general my google-fu is very very
strong...

I've been fighting with this multi-module plan for some time now with the
developer who is reporting the issue to me. The issue manifested itself as
part of a Sonar failure... the funny thing is, that the failure was on a
dependenct tree resolution that Sonar was doing - so I had him try the
dependency plugin and perform a dependency:tree

dependency tree failed us... well, it probably isn't dependency plugin's
fault but I am at a loss as to what it is really dying on or why.

I would absolutely love it if someone saw this and said Oh yeah, I know
that issue. Its a real pain. They have XXX defined incorrectly in their
multimodule build so the dependency plugin is in a circular dependency
loop (or something like that). I have no idea if its a dependency loop,
was just an example.

I can't share the poms because its all proprietary closed source stuff
(and I have to be careful about what is shared). If this means that I dont
have enough info to help, I can live with that - and will continue to plow
forwards... I just wanted to see if theres someone on the list who knows
exactly what I should be looking for to help shorten my investigation time.

Here's an example of what dependency:tree is complaining about.

mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X

urls[38] =
file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
Number of foreign imports: 1
import: Entry[import from realm ClassRealm[maven.api, parent: null]]
-

at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.maven.plugin.PluginContainerException: An API
incompatibility was encountered while executing
org.apache.maven.plugins:maven-dependency-plugin:2.8:tree:
java.lang.AbstractMethodError:
org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V

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

Re: dependency plugin strangeness

2014-01-29 Thread Vincent Latombe

Hi,

I have already seen such error.
It is caused by the combination of a managed dependency (through
dependencyManagement) defining a dependency with system scope + Maven 3 +
Sonar. The same with Maven 2.2.1 should work.
Though, I have never seen it directly in a dependency:tree execution; only
through a sonar analysis.

On my side, I got rid of the system scope usages.

Vincent

2014-01-29 Stephen Connolly stephen.alan.conno...@gmail.com

The crucial detail was omitted... what version of Maven?

I suspect it could be a transitive dependency with system scope causing a
bug of some sort.

Most likely if you switch to a different version of Maven the command will
work... in which case you might be able to construct a test case to prove a
regression.

Touchstone versions of Maven to try are: 2.2.1, 3.0.4/3.0.5 and 3.1.1

If you see the error on all three then it is something different... but
still an important data point.

On 28 January 2014 22:55, Lyons, Roy roy.ly...@cmegroup.com wrote:

So, I tried my google-fu first - and in general my google-fu is very very
strong...

I've been fighting with this multi-module plan for some time now with the
developer who is reporting the issue to me. The issue manifested itself
as
part of a Sonar failure... the funny thing is, that the failure was on a
dependenct tree resolution that Sonar was doing - so I had him try the
dependency plugin and perform a dependency:tree

dependency tree failed us... well, it probably isn't dependency plugin's
fault but I am at a loss as to what it is really dying on or why.

I can't share the poms because its all proprietary closed source stuff
(and I have to be careful about what is shared). If this means that I
dont
have enough info to help, I can live with that - and will continue to
plow
forwards... I just wanted to see if theres someone on the list who knows
exactly what I should be looking for to help shorten my investigation
time.

Here's an example of what dependency:tree is complaining about.

mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X

urls[38] =

file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
Number of foreign imports: 1
import: Entry[import from realm ClassRealm[maven.api, parent: null]]
-

org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139)
at

org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.maven.plugin.PluginContainerException: An API
incompatibility was encountered while executing
org.apache.maven.plugins:maven-dependency-plugin:2.8:tree:
java.lang.AbstractMethodError:

org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V

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

Re: dependency plugin strangeness

2014-01-29 Thread Lyons, Roy

After Stephen mentioned trying different versions, I had the developer try
out maven 2.2.1.  I was about to report back that this worked and how
strange it was -- but before sending I saw this email from Vincent.

I'll pass along the system scope issue - perhaps that is the nail in the
coffin.  We reverted with 2.2.1, with instructions to work on making it
3.x compliant in the background.

Thank you for all the input on this issue.  It is very much appreciated.

Thanks,

Roy

On 1/29/14 12:33 PM, Vincent Latombe vincent.lato...@gmail.com wrote:

Hi,

I have already seen such error.
It is caused by the combination of a managed dependency (through
dependencyManagement) defining a dependency with system scope + Maven 3 +
Sonar. The same with Maven 2.2.1 should work.
Though, I have never seen it directly in a dependency:tree execution; only
through a sonar analysis.

On my side, I got rid of the system scope usages.

Vincent


2014-01-29 Stephen Connolly stephen.alan.conno...@gmail.com

 The crucial detail was omitted... what version of Maven?

 I suspect it could be a transitive dependency with system scope causing
a
 bug of some sort.

 Most likely if you switch to a different version of Maven the command
will
 work... in which case you might be able to construct a test case to
prove a
 regression.

 Touchstone versions of Maven to try are: 2.2.1, 3.0.4/3.0.5 and 3.1.1

 If you see the error on all three then it is something different... but
 still an important data point.

 More of the stack trace would help... ideally include a line or two
above
 and below... there is often crucial details therein... if you need to
hide
 GAV details, change the groupId's to something gibberish, e.g.
 com.foobar:foo-manchu:1.0-SNAPSHOT and other dummy GAVs


 On 28 January 2014 22:55, Lyons, Roy roy.ly...@cmegroup.com wrote:

  So, I tried my google-fu first - and in general my google-fu is very
very
  strong...
 
  I've been fighting with this multi-module plan for some time now with
the
  developer who is reporting the issue to me.  The issue manifested
itself
 as
  part of a Sonar failure...  the funny thing is, that the failure was
on a
  dependenct tree resolution that Sonar was doing - so I had him try the
  dependency plugin and perform a dependency:tree
 
  dependency tree failed us...  well, it probably isn't dependency
plugin's
  fault but I am at a loss as to what it is really dying on or why.
 
  I would absolutely love it if someone saw this and said Oh yeah, I
know
  that issue.  Its a real pain.  They have XXX defined incorrectly in
their
  multimodule build so the dependency plugin is in a circular dependency
  loop (or something like that).  I have no idea if its a dependency
loop,
  was just an example.
 
  I can't share the poms because its all proprietary closed source stuff
  (and I have to be careful about what is shared).  If this means that I
 dont
  have enough info to help, I can live with that - and will continue to
 plow
  forwards...  I just wanted to see if theres someone on the list who
knows
  exactly what I should be looking for to help shorten my investigation
 time.
 
  Here's an example of what dependency:tree is complaining about.
 
 
   mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e
-X
 
  urls[38] =
 
 
file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-
collections/3.2.1/commons-collections-3.2.1.jar
  Number of foreign imports: 1
  import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
  -
 
  at
 
 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuil
dPluginManager.java:139)
  at
 
 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.jav
a:209)
  ... 19 more
  Caused by: org.apache.maven.plugin.PluginContainerException: An API
  incompatibility was encountered while executing
  org.apache.maven.plugins:maven-dependency-plugin:2.8:tree:
  java.lang.AbstractMethodError:
 
 
org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.
manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/
maven/artifact/Artifact;)V
 
 
 
 
 
 
  -
  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: dependency plugin strangeness

2014-01-28 Thread Curtis Rueden

Hi Roy,

Can you use a bisect-style debugging approach? Remove half of the modules
from the build and run dependency:tree again. If it works, add half back in
again; if not, remove half of what remains. Etc. Then at least you might
isolate the problem a bit more. It also might make it easier to create a
minimal test case for bug reporting purposes.

Regards,
Curtis
On Jan 28, 2014 4:56 PM, Lyons, Roy roy.ly...@cmegroup.com wrote:

So, I tried my google-fu first - and in general my google-fu is very very
strong...

dependency tree failed us... well, it probably isn't dependency plugin's
fault but I am at a loss as to what it is really dying on or why.

Here's an example of what dependency:tree is complaining about.

mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X

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

Re: dependency plugin versus the reactor

2012-03-28 Thread Stephen Connolly

Iirc the latest version does, but older versions didn't (except with m3
where the older versions might also pull from reactor)

On Wednesday, 28 March 2012, Benson Margulies bimargul...@gmail.com wrote:
 Does dependency:copy (note, not copy-dependencies) interact with the
 reactor? In a multi-module project, can a project consume the output
 of one of its predecessors this way?

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

Re: dependency plugin usage

2012-02-13 Thread Stephen Connolly

On 13 February 2012 18:20,  chad.da...@emc.com wrote:
 I'm wondering what the difference would be between the following two ways of 
 handling copying of a certain type of maven dependency.  The dependency I'm 
 talking about is something like, for instance, a self-extracting installer 
 that I want to bundle with my custom assembly.   I've deployed this installer 
 as a maven artifact.  Initially, I didn't think  of it as a normal maven 
 dependency, since it's not a compile dependency, so I set the build up to use 
 the maven-dependency-plugin:copy mojo.

The rule of thumb is use dependency:copy if the dependency comes from
outside your reactor, as dependency:copy will not affect the build
order, and you might need to influence the build order. [can always
add a pom typed dependency to force the build order if needed

 This works great.  However, I then started wondering whether I should just 
 declare the dependency in my dependencies and then use the 
 maven-dependency-plugin:copy-dependencies mojo.

this one is equally good, but will (by definition) ensure that the
reactor is built in the correct sequence for dependencies from the
reactor... but in some cases, you may not want this as, by necessity,
listing dependencies can influence the classpath if the dependencies
are of type jar


 Can anyone provide some insight as to whether either way is better or worse?

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

Re: Dependency Plugin behavior changed to copy timestamped snapshot jars

2011-07-18 Thread Reinhard Nägele

I can switch back and forth between versions 2.1, 2.2, and 2.3. With 2.1 
I don't get timestamped snapshots, with 2.2 and 2.3 I do get timestamped 
snapshots for artifacts that don't come from the reactor. The snapshots 
were deployed with Maven 3 to our Nexus server. I think, the fact that 
you get timestamped snapshops depending on whether the artifacts come 
from the reactor or the local repo is something a user wouldn't expect.


I don't think switching to the copy goal is an option. The copy goal 
copies explicitly specified artifacts, whereas I want all dependencies 
to be copied. Or am I missing something here?


Thanks,
Reinhard


Am 16.07.2011 09:08, schrieb Stephen Connolly:

Brian, the changes in 2.2 were in the copy goal. the copy-dependencies goal
is the one being used by Reinhart

Reinhart, are you sure this is a change between 2.2 and 2.1, and nite some
side-effect of having run the install phase on your dependencies locally? if
the artifact is resolved from the reactor or the local repo it will be
-snapshot if resolved from a remote repo which has unique versions true, or
maven 3 was used to deploy, it will be the timestamp.

if the filename is critical to you use the copy goal instead as, since 2.2
that now resolves from the reactor and so can be used in all cases too
(whereas prior to 2.2 if it was a dependency on a reactor module you would
have had to use copy-dependencies)

- 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 16 Jul 2011 00:59, Brian Foxbri...@infinity.nu  wrote:

If the snapshot was resolved from a repo then it will be timestamped,
if it came from the reactor or local repo, then it will be -SNAPSHOT.
The plugin calls into the maven resolution logic so this is core maven
behavior.

In 2.2, resolution from the reactor was introduced for these goals,
previously they would always go to the repository, this could be why
you see a change in the new version.


On Fri, Jul 15, 2011 at 5:28 AM, Reinhard Nägele
reinhard.naeg...@mgm-tp.com  wrote:

Hi all,

We use the dependency plugin's goal copy-dependencies in several

projects.

For snapshot dependencies, it would copy unique snapshot jars until

version

2.1. Since version 2.2, the behavior has changed in that now timestamped
snapshots are copied.

I could not find this change anywhere in the release notes. In fact, it

is

not documented at all, what the correct behavior is supposed to be. Is
anyone aware of this change? Has it happened on purpose or by accident?
Anyway, I'd really like to get the old behavior back. I think this should

be

configurable.

Any opinions or insights?

Thanks,
Reinhard




-
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: Dependency Plugin behavior changed to copy timestamped snapshot jars

2011-07-16 Thread Stephen Connolly

Brian, the changes in 2.2 were in the copy goal. the copy-dependencies goal
is the one being used by Reinhart

Reinhart, are you sure this is a change between 2.2 and 2.1, and nite some
side-effect of having run the install phase on your dependencies locally? if
the artifact is resolved from the reactor or the local repo it will be
-snapshot if resolved from a remote repo which has unique versions true, or
maven 3 was used to deploy, it will be the timestamp.

if the filename is critical to you use the copy goal instead as, since 2.2
that now resolves from the reactor and so can be used in all cases too
(whereas prior to 2.2 if it was a dependency on a reactor module you would
have had to use copy-dependencies)

- 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 16 Jul 2011 00:59, Brian Fox bri...@infinity.nu wrote:
 If the snapshot was resolved from a repo then it will be timestamped,
 if it came from the reactor or local repo, then it will be -SNAPSHOT.
 The plugin calls into the maven resolution logic so this is core maven
 behavior.

 In 2.2, resolution from the reactor was introduced for these goals,
 previously they would always go to the repository, this could be why
 you see a change in the new version.


 On Fri, Jul 15, 2011 at 5:28 AM, Reinhard Nägele
 reinhard.naeg...@mgm-tp.com wrote:
 Hi all,

 We use the dependency plugin's goal copy-dependencies in several
projects.
 For snapshot dependencies, it would copy unique snapshot jars until
version
 2.1. Since version 2.2, the behavior has changed in that now timestamped
 snapshots are copied.

 I could not find this change anywhere in the release notes. In fact, it
is
 not documented at all, what the correct behavior is supposed to be. Is
 anyone aware of this change? Has it happened on purpose or by accident?
 Anyway, I'd really like to get the old behavior back. I think this should
be
 configurable.

 Any opinions or insights?

 Thanks,
 Reinhard




 -
 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: Dependency Plugin behavior changed to copy timestamped snapshot jars

2011-07-15 Thread Brian Fox

If the snapshot was resolved from a repo then it will be timestamped,
if it came from the reactor or local repo, then it will be -SNAPSHOT.
The plugin calls into the maven resolution logic so this is core maven
behavior.

In 2.2, resolution from the reactor was introduced for these goals,
previously they would always go to the repository, this could be why
you see a change in the new version.


On Fri, Jul 15, 2011 at 5:28 AM, Reinhard Nägele
reinhard.naeg...@mgm-tp.com wrote:
 Hi all,

 We use the dependency plugin's goal copy-dependencies in several projects.
 For snapshot dependencies, it would copy unique snapshot jars until version
 2.1. Since version 2.2, the behavior has changed in that now timestamped
 snapshots are copied.

 I could not find this change anywhere in the release notes. In fact, it is
 not documented at all, what the correct behavior is supposed to be. Is
 anyone aware of this change? Has it happened on purpose or by accident?
 Anyway, I'd really like to get the old behavior back. I think this should be
 configurable.

 Any opinions or insights?

 Thanks,
 Reinhard




 -
 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: dependency plugin does not find dependency for release

2010-07-30 Thread Bartosz Baranowski

Hmm it seems I solved this by adding:

preparationGoalsclean install/preparationGoals to release plugin.

But still, should reactor be searched be dependency plugin.


On Fri, Jul 30, 2010 at 12:05 PM, Bartosz Baranowski baran...@gmail.comwrote:

 Hi

 Im having problem with dependency plugin and release process. Stage looks
 like:

 /parent.pom.xml
 /impl/pom.xml
 /doc/pom.xml
 /docs/sources/pom.xml
 /docs/prepare/pom.xml


 On regular mvn install - /docs/sources just creates bundle with files -
 lets say it creates docs-sources-SNAPSHOT.jar.
 /docs/preapre fetches(with dependency) artifact: docs-sources-SNAPSHOT.jar
 and does filters resources, simple.
 With -X I can see artifact: docs-sources-SNAPSHOT.jar in reactor as project
 and maven indicates that it ignores repos and uses local. Fine.
 This works.

 However with mvn release:prepare it fails. Even though artifact:
 docs-sources.jar is in reactor, dependency plugin goes through list of
 repos(failing, since its not released) and than fails, completly ignoring
 reactor. This happens in verify phase, so non snapshot artifacts are not
 present in local repo.

 Has anyone faced somethin like this?


 Apache Maven 2.2.1 (rNON-CANONICAL_2010-04-08_21-32_root; 2010-04-08
 21:32:53+0200)
 Java version: 1.6.0_0
 Java home: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux version: 2.6.31.5-127.fc12.x86_64 arch: amd64 Family:
 unix

Re: Dependency plugin strange behavior

2010-01-28 Thread Brian Fox

I would phrase it differently:

The copy/unpack goals where designed to manipulate files that aren't
normal classpath dependencies of your project such as zips. The
plugin does its own resolution of these artifacts, but doesn't support
ranges or artifacts in the reactor.

The xxx-dependencies goals are designed to manipulate files that ARE
listed in your dependency list and it relies on Maven Core resolving
the artifacts prior to the plugin execution.

2010/1/26 Stephen Connolly stephen.alan.conno...@gmail.com:
 dependency:unpack works on artifacts that are not produced as part of your
 build and are not listed as dependencies, as a result you must specify the
 full GAV coordinates to resolve the artifact, and if you are foolish enough
 to use it for an artifact that is produced as part of the same build that
 your project is part of, then you will not be able to release that
 multi-module project with the maven-release-plugin.

 dependency:unpack-dependencies works on artifacts that are produced in the
 reactor (i.e. all the projects in the multi-module build that your project
 is part of).

 This same pairing exists with dependency:copy vs
 dependency:copy-dependencies

 -Stephen

 2010/1/26 Thiago Moreira (timba) tmoreira2...@gmail.com

  Hi there,

  I'm facing a strange behavior with the dependency plugin. Here is my
 configuration

 plugin
  groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
  version2.1/version
 executions
 execution
  idcopy-dependencies/id
 phaseprocess-sources/phase
  goals
 goalcopy-dependencies/goal
 /goals
  configuration
 outputDirectory${basedir}/target/site/demo/outputDirectory
  overWriteReleasesfalse/overWriteReleases
 overWriteSnapshotstrue/overWriteSnapshots
  overWriteIfNewertrue/overWriteIfNewer
 excludeTransitivetrue/excludeTransitive
  /configuration
 /execution
 execution
  idunpack/id
 phaseprocess-sources/phase
  goals
 goalunpack/goal
 /goals
  configuration
 artifactItems
 artifactItem
  groupIdnet.sourceforge.floggy/groupId
 artifactIdfloggy-persistence-weaver/artifactId
  outputDirectory${basedir}/target/site/outputDirectory
 includesschema/*/includes
  /artifactItem
 /artifactItems
   /configuration
  /execution
 /executions
 /plugin

  For the copy-dependencies execution it works fine but for the unpack
 execution it claims that cannot revolve the dependency
 net.sourceforge.floggy:floggy-persistence-weaver BUT this dependency is
 declared at dependencies section and it is a sibling project of the current
 one in a multi module project. The only difference that I can observe is
 that in one execution (unpack ID) I made an explicit reference to the
 dependency.
  Any clue why? Any workaround?

  Thanks

  Thiago Moreira



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

Re: Dependency plugin strange behavior

2010-01-26 Thread Wendy Smoak

On Tue, Jan 26, 2010 at 9:29 AM, Thiago Moreira (timba)
tmoreira2...@gmail.com wrote:
  For the copy-dependencies execution it works fine but for the unpack
 execution it claims that cannot revolve the dependency
 net.sourceforge.floggy:floggy-persistence-weaver BUT this dependency is
 declared at dependencies section and it is a sibling project of the current
 one in a multi module project. The only difference that I can observe is
 that in one execution (unpack ID) I made an explicit reference to the
 dependency.
  Any clue why? Any workaround?

What command are you executing, and in what directory/at what level in
the project?

-- 
Wendy

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

Re: Dependency plugin strange behavior

2010-01-26 Thread Stephen Connolly

dependency:unpack works on artifacts that are not produced as part of your
build and are not listed as dependencies, as a result you must specify the
full GAV coordinates to resolve the artifact, and if you are foolish enough
to use it for an artifact that is produced as part of the same build that
your project is part of, then you will not be able to release that
multi-module project with the maven-release-plugin.

dependency:unpack-dependencies works on artifacts that are produced in the
reactor (i.e. all the projects in the multi-module build that your project
is part of).

This same pairing exists with dependency:copy vs
dependency:copy-dependencies

-Stephen

2010/1/26 Thiago Moreira (timba) tmoreira2...@gmail.com

  Hi there,

  I'm facing a strange behavior with the dependency plugin. Here is my
 configuration

 plugin
  groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
  version2.1/version
 executions
 execution
  idcopy-dependencies/id
 phaseprocess-sources/phase
  goals
 goalcopy-dependencies/goal
 /goals
  configuration
 outputDirectory${basedir}/target/site/demo/outputDirectory
  overWriteReleasesfalse/overWriteReleases
 overWriteSnapshotstrue/overWriteSnapshots
  overWriteIfNewertrue/overWriteIfNewer
 excludeTransitivetrue/excludeTransitive
  /configuration
 /execution
 execution
  idunpack/id
 phaseprocess-sources/phase
  goals
 goalunpack/goal
 /goals
  configuration
 artifactItems
 artifactItem
  groupIdnet.sourceforge.floggy/groupId
 artifactIdfloggy-persistence-weaver/artifactId
  outputDirectory${basedir}/target/site/outputDirectory
 includesschema/*/includes
  /artifactItem
 /artifactItems
   /configuration
  /execution
 /executions
 /plugin

  For the copy-dependencies execution it works fine but for the unpack
 execution it claims that cannot revolve the dependency
 net.sourceforge.floggy:floggy-persistence-weaver BUT this dependency is
 declared at dependencies section and it is a sibling project of the current
 one in a multi module project. The only difference that I can observe is
 that in one execution (unpack ID) I made an explicit reference to the
 dependency.
  Any clue why? Any workaround?

  Thanks

  Thiago Moreira

Re: Dependency plugin strange behavior

2010-01-26 Thread Thiago Moreira (timba)

  Hi Stephen,

  Thank you for the explanation. The documentation is not clear about which
dependency the plugin will work on (from the repository or produced by the
build). For those of you interested in the configuration that fixed my issue
here it go:

   execution
idcopy-dependencies/id
 phaseprocess-sources/phase
goals
goalcopy-dependencies/goal
 /goals
configuration
excludeArtifactIdsfloggy-persistence-weaver/excludeArtifactIds
 outputDirectory${basedir}/target/site/demo/outputDirectory
overWriteReleasesfalse/overWriteReleases
 overWriteSnapshotstrue/overWriteSnapshots
overWriteIfNewertrue/overWriteIfNewer
 excludeTransitivetrue/excludeTransitive
/configuration
 /execution
execution
idunpack/id
 phaseprocess-sources/phase
goals
goalunpack-dependencies/goal
 /goals
configuration
includeArtifactIdsfloggy-persistence-weaver/includeArtifactIds
 outputDirectory${basedir}/target/site/outputDirectory
includesschema/*/includes
   /configuration
/execution

  Thanks!

  Thiago Moreira

On Tue, Jan 26, 2010 at 3:18 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 dependency:unpack works on artifacts that are not produced as part of your
 build and are not listed as dependencies, as a result you must specify the
 full GAV coordinates to resolve the artifact, and if you are foolish enough
 to use it for an artifact that is produced as part of the same build that
 your project is part of, then you will not be able to release that
 multi-module project with the maven-release-plugin.

 dependency:unpack-dependencies works on artifacts that are produced in the
 reactor (i.e. all the projects in the multi-module build that your project
 is part of).

 This same pairing exists with dependency:copy vs
 dependency:copy-dependencies

 -Stephen

 2010/1/26 Thiago Moreira (timba) tmoreira2...@gmail.com

   Hi there,
 
   I'm facing a strange behavior with the dependency plugin. Here is my
  configuration
 
  plugin
   groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-dependency-plugin/artifactId
   version2.1/version
  executions
  execution
   idcopy-dependencies/id
  phaseprocess-sources/phase
   goals
  goalcopy-dependencies/goal
  /goals
   configuration
  outputDirectory${basedir}/target/site/demo/outputDirectory
   overWriteReleasesfalse/overWriteReleases
  overWriteSnapshotstrue/overWriteSnapshots
   overWriteIfNewertrue/overWriteIfNewer
  excludeTransitivetrue/excludeTransitive
   /configuration
  /execution
  execution
   idunpack/id
  phaseprocess-sources/phase
   goals
  goalunpack/goal
  /goals
   configuration
  artifactItems
  artifactItem
   groupIdnet.sourceforge.floggy/groupId
  artifactIdfloggy-persistence-weaver/artifactId
   outputDirectory${basedir}/target/site/outputDirectory
  includesschema/*/includes
   /artifactItem
  /artifactItems
/configuration
   /execution
  /executions
  /plugin
 
   For the copy-dependencies execution it works fine but for the unpack
  execution it claims that cannot revolve the dependency
  net.sourceforge.floggy:floggy-persistence-weaver BUT this dependency is
  declared at dependencies section and it is a sibling project of the
 current
  one in a multi module project. The only difference that I can observe is
  that in one execution (unpack ID) I made an explicit reference to the
  dependency.
   Any clue why? Any workaround?
 
   Thanks
 
   Thiago Moreira

Re: dependency plugin outputFile parameter not working...

2009-04-30 Thread Wayne Fay

 mvn dependency:tree -DoutputFile:C:\TMP\out.txt

Why not just use mvn dependency:tree  c:\tmp\out.txt?

Wayne

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

Re: dependency plugin outputFile parameter not working...

2009-04-30 Thread solo1970


Because the I end up with other outputs I don't need, like

Reactor Summary, BUILD SUCCESSFUL,

Sonia



Wayne Fay wrote:
 
 mvn dependency:tree -DoutputFile:C:\TMP\out.txt
 
 Why not just use mvn dependency:tree  c:\tmp\out.txt?
 
 Wayne
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 

-- 
View this message in context: 
http://www.nabble.com/dependency-plugin-%22outputFile%22-parameter-not-working...-tp23319273p23320191.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: Dependency Plugin: understanding its output

2009-04-01 Thread Mark Hobson

It means that the transitive version would have been 5.0.0.CR1 but
4.0.4 was explicitly asked for in the project's dependency management
block.

Mark

2009/4/1 Melanie S tech...@yahoo.com:

 When I run the dependency plug-in (mvn dependency:tree), I get an output  
 such as the following:

 [INFO] (...)
 [INFO] [dependency:tree]
 [INFO] org.jboss.seam.example.seamspace:seamspace-ear:ear:1.0-SNAPSHOT
 [INFO] +- commons-digester:commons-digester:jar:1.8:compile
 [INFO] |  \- commons-beanutils:commons-beanutils:jar:1.7.0:compile
 [INFO] +- org.richfaces.framework:richfaces-api:jar:3.3.0.GA:compile
 [INFO] +- org.jboss.el:jboss-el:jar:1.0_02.CR3:compile
 [INFO] +- org.jboss.seam:jboss-seam:ejb:2.1.2-SNAPSHOT:compile
 [INFO] +- 
 org.jboss.seam.example.seamspace:seamspace-web:war:1.0-SNAPSHOT:compile
 [INFO] +- 
 org.jboss.seam.example.seamspace:seamspace-ejb:ejb:1.0-SNAPSHOT:compile
 [INFO] |  +- org.drools:drools-core:jar:4..0.4:compile (version managed from 
 5.0.0.CR1)

 I have difficulties trying to understand what the output text version 
 managed from 5.0.0.CR1 exactly means.  My ejb artifact 
 org.jboss.seam.example.seamspace:seamspace-ejb:ejb:1.0  has declared a 
 dependency on org.drools:drools-core:jar:5.0.0.CR:compile (with the version 
 5.0.0.CR stated).  But for the ear artifact, which depends on the ejb 
 artifact, there is a dependency on drools-core version 4.0.4 shown. So 
 possibly there is a dependency conflict somewhere.

 In order to be able to analyze the problem, I'd just like to understand what 
 the output text version managed from 5.0.0.CR1 means. I've searched the 
 Maven docs, but found no explanation anywhere. Can anyone help me?

 Thanks in advance,

 Melanie





 Following below is the full dependency tree:

 INFO] Scanning for projects...
 [INFO] Reactor build order:
 [INFO]   Seamspace
 [INFO]   Seamspace :: EJB
 [INFO]   Seamspace :: Web
 [INFO]   Seamspace :: EAR
 [INFO] Searching repository for plugin with prefix: 'dependency'.
 [INFO] 
 
 [INFO] Building Seamspace
 [INFO]    task-segment: [dependency:tree]
 [INFO] 
 
 [INFO] [dependency:tree]
 [INFO] org.jboss.seam.example.seamspace:root:pom:1.0-SNAPSHOT
 [INFO] \- org.testng:testng:jar:jdk15:5.8:test
 [INFO]    \- junit:junit:jar:3.8.1:test
 [INFO] 
 
 [INFO] Building Seamspace :: EJB
 [INFO]    task-segment: [dependency:tree]
 [INFO] 
 
 [INFO] [dependency:tree]
 [INFO] org.jboss.seam.example.seamspace:seamspace-ejb:ejb:1.0-SNAPSHOT
 [INFO] +- org.drools:drools-core:jar:5.0.0.CR1:compile
 [INFO] |  +- org.mvel:mvel2:jar:2.0.8pre1:compile
 [INFO] |  +- org.drools:drools-api:jar:5.0.0.CR1:compile
 [INFO] |  \- joda-time:joda-time:jar:1.6:compile
 [INFO] +- org.drools:drools-compiler:jar:5.0.0.CR1:compile
 [INFO] |  +- org.antlr:antlr-runtime:jar:3.1.1:compile
 [INFO] |  +- org.eclipse.jdt:core:jar:3.4.2.v_883_R34x:compile
 [INFO] |  \- janino:janino:jar:2.5.15:compile
 [INFO] +- javax.faces:jsf-api:jar:1.2_09-BETA1:provided
 [INFO] +- org.jboss.seam:jboss-seam:ejb:2.1.2-SNAPSHOT:provided
 [INFO] +- org.hibernate:hibernate-validator:jar:3.0.0.GA:provided
 [INFO] |  \- org.hibernate:hibernate:jar:3.2.4.sp1:provided
 [INFO] |     +- javax.transaction:jta:jar:1.0.1B:provided
 [INFO] |     +- asm:asm-attrs:jar:1.5.3:provided
 [INFO] |     +- dom4j:dom4j:jar:1.6.1-brew:provided (version managed from 
 1.6.1)
 [INFO] |     +- antlr:antlr:jar:2.7.6:provided
 [INFO] |     +- cglib:cglib:jar:2.1_3:provided
 [INFO] |     \- asm:asm:jar:1.5.3:provided
 [INFO] +- javax.ejb:ejb-api:jar:3.0:provided
 [INFO] +- javax.persistence:persistence-api:jar:1.0:provided
 [INFO] \- org.testng:testng:jar:jdk15:5.8:test
 [INFO]    \- junit:junit:jar:3.8.1:test
 [INFO] 
 
 [INFO] Building Seamspace :: Web
 [INFO]    task-segment: [dependency:tree]
 [INFO] 
 
 [INFO] [dependency:tree]
 [INFO] org.jboss.seam.example.seamspace:seamspace-web:war:1.0-SNAPSHOT
 [INFO] +- org.richfaces.ui:richfaces-ui:jar:3.3.0.GA:compile
 [INFO] +- org.richfaces.framework:richfaces-impl:jar:3.3.0.GA:compile
 [INFO] +- javax.persistence:persistence-api:jar:1.0:provided
 [INFO] +- org.jboss.seam:jboss-seam:ejb:2.1.2-SNAPSHOT:provided
 [INFO] +- javax.servlet:servlet-api:jar:2.5:provided
 [INFO] +- com.sun.facelets:jsf-facelets:jar:1.1.15.B1:compile
 [INFO] +- org.jboss.seam:jboss-seam-ui:jar:2.1.2-SNAPSHOT:compile
 [INFO] +- 
 org.jboss.seam.example.seamspace:seamspace-ejb:jar:1.0-SNAPSHOT:provided
 [INFO] |  +- org.drools:drools-core:jar:4.0.4:provided (version managed from 
 5.0.0.CR1)
 [INFO] |  |  \- org.mvel:mvel14:jar:1.2.21:provided
 [INFO] |

RE: dependency plugin

2008-09-13 Thread Brian E. Fox

The unpack goal doesn't look in the reactor for the dependencies. You
should use the unpack-dependencies dependencies instead since this lets
maven resolve it for the plugin. There are enough filters available that
you can get just the one you're after.

-Original Message-
From: Build Guy [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 12, 2008 10:11 PM
To: Maven Users List
Subject: Re: dependency plugin

well, the whole point is that... If module A's jar is a dependency thats

needed for compilation of Module B.
I don't need to use the install goal. Module B finds the Module A jar 
when building from the parent.

How ever. If I further want to do something with Module A's jar in 
Module B. Like extract it using dependency unpack.
I can't, unless I 1st run install goal from Module A. But this means the

release plugin won't properly work from the parent pom unless I release 
Module A and B individually.

Here's what my project looks like:
-parent pom
  | - Module A (produces Jar)
  | - Module B (includes jar)

I'm wondering if this is just a limitation of the dependency plugin..
:-/

I've been struggling with this for quite some time.
Thought? thanks!

Taras

Dan Tran wrote:
 did you use install goal ?

 -D

 On Fri, Sep 12, 2008 at 6:54 PM, Build Guy [EMAIL PROTECTED] wrote:

 Can some one please shine some light on the following scenario..

 I have parent pom and 2 modules.
 Module A produces a jar file
 Module B has Module A's jar as dependency, but it uses the dependency
plugin
 to unpack it.

 If I run mvn package from the parent. Module B's dependency plugin is
always
 trying to take the jar from the repository, not from Module A's
target
 So my build fails with [INFO] Unable to find artifact.

 I always have to run mvn install on Module A before using Module B.
Quite
 tedious..
 And I do have the jar listed in Module B as a dependency and then
again in
 he plugin like so:

 dependency
  groupIdfoo.bar/groupId
  artifactIdmyjar/artifactId
  version1.0.0-SNAPSHOT/version
  typejar/type
  scopecompile/scope
 /dependency

 plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-dependency-plugin/artifactId
  version2.0/version
  executions
  execution
  idgetjar/id
  phasegenerate-sources/phase
  goals
  goalunpack/goal
  /goals
  configuration
  artifactItems
  artifactItem
  groupIdfoo.bar/groupId
  artifactIdmyjar/artifactId
  typejar/type
  overWritetrue/overWrite
  outputDirectory
  target/tmp
  /outputDirectory
  /artifactItem
  /artifactItems
  overWriteReleasestrue/overWriteReleases
  overWriteSnapshotstrue/overWriteSnapshots
  /configuration
  /execution
  /executions
 /plugin

 Any thoughts?
 Thanks!

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

2008-09-13 Thread Brian Fox

It is this goal in the dependency plugin, but in general when working  
with multimodule builds, you should just do install. Other plugins can  
have the same problems.


Sent from my iPhone

On Sep 12, 2008, at 10:10 PM, Build Guy [EMAIL PROTECTED] wrote:

well, the whole point is that... If module A's jar is a dependency  
thats

needed for compilation of Module B.
I don't need to use the install goal. Module B finds the Module A jar
when building from the parent.

How ever. If I further want to do something with Module A's jar in
Module B. Like extract it using dependency unpack.
I can't, unless I 1st run install goal from Module A. But this means  
the
release plugin won't properly work from the parent pom unless I  
release

Module A and B individually.

Here's what my project looks like:
-parent pom
  | - Module A (produces Jar)
  | - Module B (includes jar)

I'm wondering if this is just a limitation of the dependency  
plugin.. :-/


I've been struggling with this for quite some time.
Thought? thanks!

Taras

Dan Tran wrote:
 did you use install goal ?

 -D

 On Fri, Sep 12, 2008 at 6:54 PM, Build Guy [EMAIL PROTECTED] wrote:

 Can some one please shine some light on the following scenario..

 I have parent pom and 2 modules.
 Module A produces a jar file
 Module B has Module A's jar as dependency, but it uses the  
dependency plugin

 to unpack it.

 If I run mvn package from the parent. Module B's dependency  
plugin is always
 trying to take the jar from the repository, not from Module A's  
target

 So my build fails with [INFO] Unable to find artifact.

 I always have to run mvn install on Module A before using Module  
B. Quite

 tedious..
 And I do have the jar listed in Module B as a dependency and then  
again in

 he plugin like so:

 dependency
  groupIdfoo.bar/groupId
  artifactIdmyjar/artifactId
  version1.0.0-SNAPSHOT/version
  typejar/type
  scopecompile/scope
 /dependency

 plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-dependency-plugin/artifactId
  version2.0/version
  executions
  execution
  idgetjar/id
  phasegenerate-sources/phase
  goals
  goalunpack/goal
  /goals
  configuration
  artifactItems
  artifactItem
  groupIdfoo.bar/groupId
  artifactIdmyjar/artifactId
  typejar/type
  overWritetrue/overWrite
  outputDirectory
  target/tmp
  /outputDirectory
  /artifactItem
  /artifactItems
  overWriteReleasestrue/overWriteReleases
  overWriteSnapshotstrue/overWriteSnapshots
  /configuration
  /execution
  /executions
 /plugin

 Any thoughts?
 Thanks!

  
-

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




  
-

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

2008-09-12 Thread Dan Tran

did you use install goal ?

-D

On Fri, Sep 12, 2008 at 6:54 PM, Build Guy [EMAIL PROTECTED] wrote:
 Can some one please shine some light on the following scenario..

 I have parent pom and 2 modules.
 Module A produces a jar file
 Module B has Module A's jar as dependency, but it uses the dependency plugin
 to unpack it.

 If I run mvn package from the parent. Module B's dependency plugin is always
 trying to take the jar from the repository, not from Module A's target
 So my build fails with [INFO] Unable to find artifact.

 I always have to run mvn install on Module A before using Module B. Quite
 tedious..
 And I do have the jar listed in Module B as a dependency and then again in
 he plugin like so:

 dependency
  groupIdfoo.bar/groupId
  artifactIdmyjar/artifactId
  version1.0.0-SNAPSHOT/version
  typejar/type
  scopecompile/scope
 /dependency

 plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-dependency-plugin/artifactId
  version2.0/version
  executions
  execution
  idgetjar/id
  phasegenerate-sources/phase
  goals
  goalunpack/goal
  /goals
  configuration
  artifactItems
  artifactItem
  groupIdfoo.bar/groupId
  artifactIdmyjar/artifactId
  typejar/type
  overWritetrue/overWrite
  outputDirectory
  target/tmp
  /outputDirectory
  /artifactItem
  /artifactItems
  overWriteReleasestrue/overWriteReleases
  overWriteSnapshotstrue/overWriteSnapshots
  /configuration
  /execution
  /executions
 /plugin

 Any thoughts?
 Thanks!

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

2008-09-12 Thread Build Guy

well, the whole point is that... If module A's jar is a dependency thats 
needed for compilation of Module B.
I don't need to use the install goal. Module B finds the Module A jar 
when building from the parent.


How ever. If I further want to do something with Module A's jar in 
Module B. Like extract it using dependency unpack.
I can't, unless I 1st run install goal from Module A. But this means the 
release plugin won't properly work from the parent pom unless I release 
Module A and B individually.


Here's what my project looks like:
-parent pom
 | - Module A (produces Jar)
 | - Module B (includes jar)

I'm wondering if this is just a limitation of the dependency plugin.. :-/

I've been struggling with this for quite some time.
Thought? thanks!

Taras

Dan Tran wrote:

did you use install goal ?

-D

On Fri, Sep 12, 2008 at 6:54 PM, Build Guy [EMAIL PROTECTED] wrote:
  

Can some one please shine some light on the following scenario..

I have parent pom and 2 modules.
Module A produces a jar file
Module B has Module A's jar as dependency, but it uses the dependency plugin
to unpack it.

If I run mvn package from the parent. Module B's dependency plugin is always
trying to take the jar from the repository, not from Module A's target
So my build fails with [INFO] Unable to find artifact.

I always have to run mvn install on Module A before using Module B. Quite
tedious..
And I do have the jar listed in Module B as a dependency and then again in
he plugin like so:

dependency
 groupIdfoo.bar/groupId
 artifactIdmyjar/artifactId
 version1.0.0-SNAPSHOT/version
 typejar/type
 scopecompile/scope
/dependency

plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 version2.0/version
 executions
 execution
 idgetjar/id
 phasegenerate-sources/phase
 goals
 goalunpack/goal
 /goals
 configuration
 artifactItems
 artifactItem
 groupIdfoo.bar/groupId
 artifactIdmyjar/artifactId
 typejar/type
 overWritetrue/overWrite
 outputDirectory
 target/tmp
 /outputDirectory
 /artifactItem
 /artifactItems
 overWriteReleasestrue/overWriteReleases
 overWriteSnapshotstrue/overWriteSnapshots
 /configuration
 /execution
 /executions
/plugin

Any thoughts?
Thanks!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

2008-09-12 Thread Wendy Smoak

On Fri, Sep 12, 2008 at 7:10 PM, Build Guy [EMAIL PROTECTED] wrote:

 But this means the
 release plugin won't properly work from the parent pom unless I release
 Module A and B individually.

Not necessarily.  You can configure the release plugin to run all the
way through install in the prepare phase.  (By default it only goes
through integration-test, which is before install.)

-- 
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

2008-09-12 Thread Build Guy

I see, so what you suggest is add install to the goals conf of the 
release plugin?


Cheers

Wendy Smoak wrote:

On Fri, Sep 12, 2008 at 7:10 PM, Build Guy [EMAIL PROTECTED] wrote:

  

But this means the
release plugin won't properly work from the parent pom unless I release
Module A and B individually.



Not necessarily.  You can configure the release plugin to run all the
way through install in the prepare phase.  (By default it only goes
through integration-test, which is before install.)

  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

2008-09-12 Thread Dan Tran

I am not sure why you are reluctant to run install goal?  This sort of
thing works
for me every day.  Have you try cut release from the parent pom?

-D


On Fri, Sep 12, 2008 at 7:31 PM, Build Guy [EMAIL PROTECTED] wrote:
 I see, so what you suggest is add install to the goals conf of the release
 plugin?

 Cheers

 Wendy Smoak wrote:

 On Fri, Sep 12, 2008 at 7:10 PM, Build Guy [EMAIL PROTECTED] wrote:



 But this means the
 release plugin won't properly work from the parent pom unless I release
 Module A and B individually.


 Not necessarily.  You can configure the release plugin to run all the
 way through install in the prepare phase.  (By default it only goes
 through integration-test, which is before install.)




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

2008-07-21 Thread Infinity

Whether you use assembly or dependency, you will still need to list  
the version of the artifact. If you put the version in  
dependencyManagement, you can skip the version in the plugin config  
for dependency


Sent from my iPhone

On Jul 18, 2008, at 5:48 PM, Kathryn Huxtable [EMAIL PROTECTED] 
 wrote:



Use the assembly plugin instead. It's very customizable and can likely
do what you want.

-K

On Jul 18, 2008, at 7:43 AM, Laura Lozano wrote:

 Hello,

 I'm using the dependency plugin in order to copy the dependencies
 from the
 repository to a target platform. The problem is that I need to copy
 also
 some artifacts that are not dependencies and using copy I have to
 specify
 the version, this is not very useful becasuse when the version
 changes the
 pom also has to be updated to copy the new version in the target
 directory.
 Is there any way more general to copy artifacts that are not
 dependencies in
 the target direcotry whitouth specify the version?

 Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

2008-07-18 Thread Kathryn Huxtable

Use the assembly plugin instead. It's very customizable and can likely  
do what you want.


-K

On Jul 18, 2008, at 7:43 AM, Laura Lozano wrote:


Hello,

I'm using the dependency plugin in order to copy the dependencies  
from the
repository to a target platform. The problem is that I need to copy  
also
some artifacts that are not dependencies and using copy I have to  
specify
the version, this is not very useful becasuse when the version  
changes the
pom also has to be updated to copy the new version in the target  
directory.
Is there any way more general to copy artifacts that are not  
dependencies in

the target direcotry whitouth specify the version?

Thank you.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dependency plugin

2008-02-28 Thread Shakun Gupta


Wayne,
This is an annoyance. Actually I do not want to keep the jars in my 
project directory. I am using the dependency plugin for copying the 
third party jars to a directory where i am testing my app. So, I just 
need to run this plugin only when there is and addition to my dependency 
list.


Regards,
Shakun

Wayne Fay wrote:

Is this really a problem for you, or just an annoyance?

Wayne

On 2/27/08, Shakun Gupta [EMAIL PROTECTED] wrote:
  

Hi All,
I am using the dependency plugin to copy all the dependencies to an
output directory. But, the dependencies are also copied in my
target/dependency directory, i.e., the default directory for this
plugin. Can you please suggest how to avoid this.

Regards,
Shakun

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dependency plugin

2008-02-27 Thread Wayne Fay

Is this really a problem for you, or just an annoyance?

Wayne

On 2/27/08, Shakun Gupta [EMAIL PROTECTED] wrote:
 Hi All,
 I am using the dependency plugin to copy all the dependencies to an
 output directory. But, the dependencies are also copied in my
 target/dependency directory, i.e., the default directory for this
 plugin. Can you please suggest how to avoid this.

 Regards,
 Shakun

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dependency plugin] Used undeclared dependencies

2007-11-22 Thread Wim Deblauwe

Thanks, added that extra dependency and now the warning is gone.

regards,

Wim

2007/11/21, [EMAIL PROTECTED] [EMAIL PROTECTED]:

 AFAIK, this shows the dependencies from which your code is using classes,
 but which are not declared in your pom file, but by another dependency.

 ie.

 You - Project A - Project B

 And one of your classes imports something from Project B. This will
 compile.

 Project A releases a new versions, which is not dependend anymore on
 Project B.

 You update the version of Project A to the new version, et voila, your
 code is not compiling anymore.

 It is better to declare all your dependencies your project uses, even if
 there are already included in one of your dependencies.

 Hth,

 Nick Stolwijk


 -Original Message-
 From: Wim Deblauwe [mailto:[EMAIL PROTECTED]
 Sent: Wed 11/21/2007 4:32 PM
 To: Maven Users List
 Subject: [dependency plugin] Used undeclared dependencies

 Why does the dependency plugin gives Used undeclared dependencies? What
 is
 the reason or how does maven know this?

 I looked at the docs (
 http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
 ),
 but it did not give much info on why you get this and what you can do
 about
 it.

 This is the output:
 [INFO] [dependency:analyze]
 [INFO] Used declared dependencies:
 [INFO]net.java.dev.glazedlists:glazedlists_java15:jar:1.7.0:compile
 [INFO]net.java.dev.timingframework:timingframework:jar:1.0:compile
 [INFO]com.jidesoft:jide-oss:jar:2.1.3.04:compile
 [INFO]log4j:log4j:jar:1.2.14:compile
 [INFO]org.swinglabs:swing-worker:jar:1.1:compile
 [INFO]com.jgoodies:looks:jar:2.1.2:compile
 [INFO]com.thoughtworks.xstream:xstream:jar:1.2.1:compile
 [INFO]org.swinglabs:swingx:jar:0.9:compile
 [INFO]org.testng:testng:jar:jdk15:5.1:test
 [INFO] Used undeclared dependencies:
 [WARNING]com.jhlabs:filters:jar:2.0.235:compile
 [INFO] Unused declared dependencies:
 [INFO]None
 [WARNING] Potential problems discovered.
 [INFO] Found Resolved Dependency / DependencyManagement mismatches:
 [INFO]Nothing in DepMgt.

 Additionally, the docs show a target called dependency:tree but this
 does
 not seem to work.

 regards,

 Wim

 --
 Vigilog - an open source log file viewer: http://vigilog.sourceforge.net
 Blog: http://www.jroller.com/page/Fester




-- 
Vigilog - an open source log file viewer: http://vigilog.sourceforge.net
Blog: http://www.jroller.com/page/Fester

RE: [dependency plugin] Used undeclared dependencies

2007-11-21 Thread nicklist

AFAIK, this shows the dependencies from which your code is using classes, but 
which are not declared in your pom file, but by another dependency. 

ie.

You - Project A - Project B

And one of your classes imports something from Project B. This will compile.

Project A releases a new versions, which is not dependend anymore on Project B.

You update the version of Project A to the new version, et voila, your code is 
not compiling anymore.

It is better to declare all your dependencies your project uses, even if there 
are already included in one of your dependencies.

Hth,

Nick Stolwijk


-Original Message-
From: Wim Deblauwe [mailto:[EMAIL PROTECTED]
Sent: Wed 11/21/2007 4:32 PM
To: Maven Users List
Subject: [dependency plugin] Used undeclared dependencies
 
Why does the dependency plugin gives Used undeclared dependencies? What is
the reason or how does maven know this?

I looked at the docs (
http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html),
but it did not give much info on why you get this and what you can do about
it.

This is the output:
[INFO] [dependency:analyze]
[INFO] Used declared dependencies:
[INFO]net.java.dev.glazedlists:glazedlists_java15:jar:1.7.0:compile
[INFO]net.java.dev.timingframework:timingframework:jar:1.0:compile
[INFO]com.jidesoft:jide-oss:jar:2.1.3.04:compile
[INFO]log4j:log4j:jar:1.2.14:compile
[INFO]org.swinglabs:swing-worker:jar:1.1:compile
[INFO]com.jgoodies:looks:jar:2.1.2:compile
[INFO]com.thoughtworks.xstream:xstream:jar:1.2.1:compile
[INFO]org.swinglabs:swingx:jar:0.9:compile
[INFO]org.testng:testng:jar:jdk15:5.1:test
[INFO] Used undeclared dependencies:
[WARNING]com.jhlabs:filters:jar:2.0.235:compile
[INFO] Unused declared dependencies:
[INFO]None
[WARNING] Potential problems discovered.
[INFO] Found Resolved Dependency / DependencyManagement mismatches:
[INFO]Nothing in DepMgt.

Additionally, the docs show a target called dependency:tree but this does
not seem to work.

regards,

Wim

-- 
Vigilog - an open source log file viewer: http://vigilog.sourceforge.net
Blog: http://www.jroller.com/page/Fester

Re: dependency plugin and version

2007-11-21 Thread deckrider

Just wanted to report back that I finally go this to work by doing
this (thanks for the clues along the way):

plugins
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
  webResources
resource
  !-- this is relative to the pom.xml directory --
  directory${project.build.directory}/dependency/directory
  includes
include**/*.jar/include
include**/*.jnlp/include
  /includes
/resource
  /webResources
/configuration
  /plugin
  plugin
groupIdorg.codehaus.mojo/groupId
artifactIddependency-maven-plugin/artifactId
executions
  execution
!--
  Copy the webstart bundle in as a resource
  before packaging starts.
--
phaseprocess-resources/phase
goals
  goalunpack-dependencies/goal
/goals
  /execution
/executions
  /plugin
/plugins


On Nov 19, 2007 4:19 PM, deckrider [EMAIL PROTECTED] wrote:
 Ok, I got this to include only what I want by changing the phase from
 'process-resources' to 'package'.  However, because of the
 dependencies, the jars are placed under WEB-INF/lib in the war file,
 which is not correct.


 On Nov 19, 2007 3:53 PM, deckrider [EMAIL PROTECTED] wrote:
  Hmm, I'm having trouble getting 'unpack-dependencies' to work the way
  I want.  It seems that much more is included in my war file than
  'unpack' would give (and unpack would give exactly what I wanted).
 
  Originally I was trying to follow this:
 
  http://mojo.codehaus.org/webstart-maven-plugin-parent/webstart-maven-plugin/examples/war_bundle_1.html
 
  But I would like to use = 8.0.0 rather than hard coding 8.1.3 and
  incrementing for each version.
 
 
  On Nov 19, 2007 3:00 PM, Brian E. Fox [EMAIL PROTECTED] wrote:
   The dependency plugin doesn't support versions in the copy/unpack goals.
   You could try the unpack-dependencies goal instead since that allows
   maven core to resolve it. You would then use the filters to get only the
   file you want.
  
  
   -Original Message-
   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
   deckrider+mvn
   Sent: Monday, November 19, 2007 2:25 PM
   To: users@maven.apache.org
   Subject: dependency plugin and version
  
   Hi, is there a way I can change version below to take the latest
   greater than 8.0.0 instead of hard-coding the version as I do below?
   I tried using:  version[8,)/version but that did not work.
  
 plugin
   groupIdorg.codehaus.mojo/groupId
   artifactIddependency-maven-plugin/artifactId
   executions
 execution
   !--
 Copy the webstart bundle in as a resource
 before packaging starts.
   --
   phaseprocess-resources/phase
   goals
 goalunpack/goal
   /goals
 /execution
   /executions
   configuration
 artifactItems
   artifactItem
 groupIdcom.vzb.impact/groupId
 artifactIdwebstart-test/artifactId
 version8.1.2/version
 typezip/type
   /artifactItem
  
   outputDirectory${project.build.directory}/${project.build.finalName}/
   outputDirectory
   /configuration
 /plugin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: dependency plugin and version

2007-11-19 Thread Brian E. Fox

The dependency plugin doesn't support versions in the copy/unpack goals.
You could try the unpack-dependencies goal instead since that allows
maven core to resolve it. You would then use the filters to get only the
file you want.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
deckrider+mvn
Sent: Monday, November 19, 2007 2:25 PM
To: users@maven.apache.org
Subject: dependency plugin and version

Hi, is there a way I can change version below to take the latest
greater than 8.0.0 instead of hard-coding the version as I do below?
I tried using:  version[8,)/version but that did not work.

  plugin
groupIdorg.codehaus.mojo/groupId
artifactIddependency-maven-plugin/artifactId
executions
  execution
!--
  Copy the webstart bundle in as a resource
  before packaging starts.
--
phaseprocess-resources/phase
goals
  goalunpack/goal
/goals
  /execution
/executions
configuration
  artifactItems
artifactItem
  groupIdcom.vzb.impact/groupId
  artifactIdwebstart-test/artifactId
  version8.1.2/version
  typezip/type
/artifactItem

outputDirectory${project.build.directory}/${project.build.finalName}/
outputDirectory
/configuration
  /plugin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin and version

2007-11-19 Thread deckrider

Hmm, I'm having trouble getting 'unpack-dependencies' to work the way
I want.  It seems that much more is included in my war file than
'unpack' would give (and unpack would give exactly what I wanted).

Originally I was trying to follow this:

http://mojo.codehaus.org/webstart-maven-plugin-parent/webstart-maven-plugin/examples/war_bundle_1.html

But I would like to use = 8.0.0 rather than hard coding 8.1.3 and
incrementing for each version.

On Nov 19, 2007 3:00 PM, Brian E. Fox [EMAIL PROTECTED] wrote:
 The dependency plugin doesn't support versions in the copy/unpack goals.
 You could try the unpack-dependencies goal instead since that allows
 maven core to resolve it. You would then use the filters to get only the
 file you want.


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
 deckrider+mvn
 Sent: Monday, November 19, 2007 2:25 PM
 To: users@maven.apache.org
 Subject: dependency plugin and version

 Hi, is there a way I can change version below to take the latest
 greater than 8.0.0 instead of hard-coding the version as I do below?
 I tried using:  version[8,)/version but that did not work.

   plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIddependency-maven-plugin/artifactId
 executions
   execution
 !--
   Copy the webstart bundle in as a resource
   before packaging starts.
 --
 phaseprocess-resources/phase
 goals
   goalunpack/goal
 /goals
   /execution
 /executions
 configuration
   artifactItems
 artifactItem
   groupIdcom.vzb.impact/groupId
   artifactIdwebstart-test/artifactId
   version8.1.2/version
   typezip/type
 /artifactItem

 outputDirectory${project.build.directory}/${project.build.finalName}/
 outputDirectory
 /configuration
   /plugin

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-- 
ASCII ribbon campaign:
()  against HTML email
/\  against Microsoft attachments
Information:  http://www.expita.com/nomime.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin and version

2007-11-19 Thread deckrider

Ok, I got this to include only what I want by changing the phase from
'process-resources' to 'package'.  However, because of the
dependencies, the jars are placed under WEB-INF/lib in the war file,
which is not correct.

On Nov 19, 2007 3:53 PM, deckrider [EMAIL PROTECTED] wrote:
 Hmm, I'm having trouble getting 'unpack-dependencies' to work the way
 I want.  It seems that much more is included in my war file than
 'unpack' would give (and unpack would give exactly what I wanted).

 Originally I was trying to follow this:

 http://mojo.codehaus.org/webstart-maven-plugin-parent/webstart-maven-plugin/examples/war_bundle_1.html

 But I would like to use = 8.0.0 rather than hard coding 8.1.3 and
 incrementing for each version.


 On Nov 19, 2007 3:00 PM, Brian E. Fox [EMAIL PROTECTED] wrote:
  The dependency plugin doesn't support versions in the copy/unpack goals.
  You could try the unpack-dependencies goal instead since that allows
  maven core to resolve it. You would then use the filters to get only the
  file you want.
 
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
  deckrider+mvn
  Sent: Monday, November 19, 2007 2:25 PM
  To: users@maven.apache.org
  Subject: dependency plugin and version
 
  Hi, is there a way I can change version below to take the latest
  greater than 8.0.0 instead of hard-coding the version as I do below?
  I tried using:  version[8,)/version but that did not work.
 
plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIddependency-maven-plugin/artifactId
  executions
execution
  !--
Copy the webstart bundle in as a resource
before packaging starts.
  --
  phaseprocess-resources/phase
  goals
goalunpack/goal
  /goals
/execution
  /executions
  configuration
artifactItems
  artifactItem
groupIdcom.vzb.impact/groupId
artifactIdwebstart-test/artifactId
version8.1.2/version
typezip/type
  /artifactItem
 
  outputDirectory${project.build.directory}/${project.build.finalName}/
  outputDirectory
  /configuration
/plugin
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 



 --
 ASCII ribbon campaign:
 ()  against HTML email
 /\  against Microsoft attachments
 Information:  http://www.expita.com/nomime.html




-- 
ASCII ribbon campaign:
()  against HTML email
/\  against Microsoft attachments
Information:  http://www.expita.com/nomime.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: dependency-plugin without forking

2007-07-25 Thread William Ferguson

Thanks Brian, that works nicely. Looking forward to it being released.
Though I did think it kind of strange that it still provided this
warning if the build is not forked, which it doesn't appear to be:

[WARNING] Removing: just-analyze from forked lifecycle, to prevent
recursive invocation.


Nor did I understand what this message means:

[INFO] No goals needed for project - skipping

Any ideas?


William
 

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 24 July 2007 11:36 PM
To: Maven Users List
Subject: [***POSSIBLE SPAM***] - RE: dependency-plugin without forking -
Email has different SMTP TO: and MIME TO: fields in the email addresses

Actually in the unreleased snapshot, there is a goal called (i think)
just-analyze that does exactly what you ask ;-)
 



From: William Ferguson [mailto:[EMAIL PROTECTED]
Sent: Tue 7/24/2007 12:21 AM
To: Maven Users List
Subject: dependency-plugin without forking



Is it possible execute dependency:analyze without having the
dependency-plugin fork the build?

We'd really like to have dependency:analyze execute as part of every
build, but having all the phases execute twice is not going to be
acceptable. Is there a way to stop the depdendency-plugin from causing
the phases to execute again?

We are using maven-dependency-plugin:2.0-alpha-4 and maven-2.0.7

William

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency-plugin without forking

2007-07-25 Thread William Ferguson

Hi Eric,

The use case is that we would like to ensure that the dependencies are
the minimal set of the appropriate dependencies as an integral part of
our build. Ie part of our quality bar.

But looks like I'm not alone, as Brian pointed out
dependency-plugin:2.0-alpha-5-SNAPSHOT has the just-analyze Mojo which
does exactly what I need.

William

-Original Message-
From: Eric Redmond [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 24 July 2007 11:22 PM
To: Maven Users List
Subject: [***POSSIBLE SPAM***] - Re: dependency-plugin without forking -
Email has different SMTP TO: and MIME TO: fields in the email addresses

dependency:analyze is meant to help people check their project
dependencies occasionally and fix accordingly? What use-case do you have
for requiring it to run every time? If you just want a print-out, there
is always the dependency report.

Eric

On 7/23/07, William Ferguson [EMAIL PROTECTED] wrote:

 Is it possible execute dependency:analyze without having the 
 dependency-plugin fork the build?

 We'd really like to have dependency:analyze execute as part of every 
 build, but having all the phases execute twice is not going to be 
 acceptable. Is there a way to stop the depdendency-plugin from causing

 the phases to execute again?

 We are using maven-dependency-plugin:2.0-alpha-4 and maven-2.0.7

 William

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
Eric Redmond
http://blog.propellors.net

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency-plugin without forking

2007-07-25 Thread Eric Redmond


In that case - I would imagine that the plugin should cause the build to
fail if it does not meet certain metrics - if the new goal does not do this,
it'd be a useful addition.

Eric

On 7/24/07, William Ferguson [EMAIL PROTECTED] wrote:


Hi Eric,

The use case is that we would like to ensure that the dependencies are
the minimal set of the appropriate dependencies as an integral part of
our build. Ie part of our quality bar.

But looks like I'm not alone, as Brian pointed out
dependency-plugin:2.0-alpha-5-SNAPSHOT has the just-analyze Mojo which
does exactly what I need.

William

-Original Message-
From: Eric Redmond [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 24 July 2007 11:22 PM
To: Maven Users List
Subject: [***POSSIBLE SPAM***] - Re: dependency-plugin without forking -
Email has different SMTP TO: and MIME TO: fields in the email addresses

dependency:analyze is meant to help people check their project
dependencies occasionally and fix accordingly? What use-case do you have
for requiring it to run every time? If you just want a print-out, there
is always the dependency report.

Eric

On 7/23/07, William Ferguson [EMAIL PROTECTED] wrote:

 Is it possible execute dependency:analyze without having the
 dependency-plugin fork the build?

 We'd really like to have dependency:analyze execute as part of every
 build, but having all the phases execute twice is not going to be
 acceptable. Is there a way to stop the depdendency-plugin from causing

 the phases to execute again?

 We are using maven-dependency-plugin:2.0-alpha-4 and maven-2.0.7

 William

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
Eric Redmond
http://blog.propellors.net

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Eric Redmond
http://blog.propellors.net

Re: dependency-plugin without forking

2007-07-24 Thread Eric Redmond


dependency:analyze is meant to help people check their project dependencies
occasionally and fix accordingly? What use-case do you have for requiring it
to run every time? If you just want a print-out, there is always the
dependency report.

Eric

On 7/23/07, William Ferguson [EMAIL PROTECTED] wrote:


Is it possible execute dependency:analyze without having the
dependency-plugin fork the build?

We'd really like to have dependency:analyze execute as part of every
build, but having all the phases execute twice is not going to be
acceptable. Is there a way to stop the depdendency-plugin from causing
the phases to execute again?

We are using maven-dependency-plugin:2.0-alpha-4 and maven-2.0.7

William

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Eric Redmond
http://blog.propellors.net

RE: dependency-plugin without forking

2007-07-24 Thread Brian E. Fox

Actually in the unreleased snapshot, there is a goal called (i think) 
just-analyze that does exactly what you ask ;-)

From: William Ferguson [mailto:[EMAIL PROTECTED]
Sent: Tue 7/24/2007 12:21 AM
To: Maven Users List
Subject: dependency-plugin without forking

Is it possible execute dependency:analyze without having the
dependency-plugin fork the build?

We'd really like to have dependency:analyze execute as part of every
build, but having all the phases execute twice is not going to be
acceptable. Is there a way to stop the depdendency-plugin from causing
the phases to execute again?

We are using maven-dependency-plugin:2.0-alpha-4 and maven-2.0.7

William

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

2007-03-14 Thread Carlos Sanchez


Brian, you need to notify repository@apache.org when you do this kind
of changes.
You removed it from apache but it was already in central and all the mirrors.
I moved it out of the way now


On 3/13/07, Brian E. Fox [EMAIL PROTECTED] wrote:

Hi Sorry about that. Alpha-2 was not supposed to be on central yet. I
have updated the metadata files by hand to make it go away...it will
take a few hours to rsync to the repo. The good news is that alpha-2 is
staged and being voted on. Baring any sudden issues, it should be
released in ~60hrs from now.

-Original Message-
From: Sommers, Elizabeth [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 13, 2007 9:11 AM
To: Maven Users List (E-mail)
Subject: dependency plugin


We woke up this morning to find that the dependency plugin was changed
on 3/12/07.  We wouldn't have noticed except that we got the error
below.
We solved our problem by versioning the plugin in our pom to 2.0-alpha-1
, but I figure others might be running into this today.

Thanks
Liz
[EMAIL PROTECTED]

-
this realm =
app0.child-container[org.apache.maven.plugins:maven-dependency-plugin]
urls[0] =
file:/c:/SB/.m2/repository/org/apache/maven/plugins/maven-dependency-plu
gin/2.0-alpha-2/maven-dependency-plugin-2.0-alpha-
2.jar
Number of imports: 0


this realm = plexus.core.maven
urls[0] = file:/c:/opt/maven2/lib/commons-cli-1.0.jar
urls[1] = file:/c:/opt/maven2/lib/doxia-sink-api-1.0-alpha-7.jar
urls[2] = file:/c:/opt/maven2/lib/jsch-0.1.24.jar
urls[3] = file:/c:/opt/maven2/lib/maven-artifact-2.0.4.jar
urls[4] = file:/c:/opt/maven2/lib/maven-artifact-manager-2.0.4.jar
urls[5] = file:/c:/opt/maven2/lib/maven-core-2.0.4.jar
urls[6] = file:/c:/opt/maven2/lib/maven-error-diagnostics-2.0.4.jar
urls[7] = file:/c:/opt/maven2/lib/maven-model-2.0.4.jar
urls[8] = file:/c:/opt/maven2/lib/maven-monitor-2.0.4.jar
urls[9] = file:/c:/opt/maven2/lib/maven-plugin-api-2.0.4.jar
urls[10] = file:/c:/opt/maven2/lib/maven-plugin-descriptor-2.0.4.jar
urls[11] =
file:/c:/opt/maven2/lib/maven-plugin-parameter-documenter-2.0.4.jar
urls[12] = file:/c:/opt/maven2/lib/maven-plugin-registry-2.0.4.jar
urls[13] = file:/c:/opt/maven2/lib/maven-profile-2.0.4.jar
urls[14] = file:/c:/opt/maven2/lib/maven-project-2.0.4.jar
urls[15] = file:/c:/opt/maven2/lib/maven-reporting-api-2.0.4.jar
urls[16] = file:/c:/opt/maven2/lib/maven-repository-metadata-2.0.4.jar
urls[17] = file:/c:/opt/maven2/lib/maven-settings-2.0.4.jar
urls[18] =
file:/c:/opt/maven2/lib/plexus-interactivity-api-1.0-alpha-4.jar
urls[19] = file:/c:/opt/maven2/lib/wagon-file-1.0-alpha-7.jar
urls[20] =
file:/c:/opt/maven2/lib/wagon-http-lightweight-1.0-alpha-6.jar
urls[21] = file:/c:/opt/maven2/lib/wagon-provider-api-1.0-alpha-6.jar
urls[22] = file:/c:/opt/maven2/lib/wagon-ssh-1.0-alpha-7.jar
urls[23] = file:/c:/opt/maven2/lib/wagon-ssh-external-1.0-alpha-6.jar
Number of imports: 0


this realm = plexus.core
urls[0] =
file:/c:/opt/maven2/core/plexus-container-default-1.0-alpha-9.jar
urls[1] = file:/c:/opt/maven2/core/plexus-utils-1.1.jar
Number of imports: 0
-
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-2:unpack':
Un able to find the mojo
'org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-2:unpack' in
the plugin 'org.apache.maven.plugins:
maven-dependency-plugin'
org/codehaus/plexus/archiver/ArchiverException

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: dependency plugin

2007-03-14 Thread Brian E. Fox

Ok thanks. Is it only the removal of the folder that doesn't get
synched? I manually updated the metadata, and that must sync out right? 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Wednesday, March 14, 2007 1:49 PM
To: Maven Users List
Cc: repository@apache.org
Subject: Re: dependency plugin

Brian, you need to notify repository@apache.org when you do this kind of
changes.
You removed it from apache but it was already in central and all the
mirrors.
I moved it out of the way now


On 3/13/07, Brian E. Fox [EMAIL PROTECTED] wrote:
 Hi Sorry about that. Alpha-2 was not supposed to be on central yet. I 
 have updated the metadata files by hand to make it go away...it will 
 take a few hours to rsync to the repo. The good news is that alpha-2 
 is staged and being voted on. Baring any sudden issues, it should be 
 released in ~60hrs from now.

 -Original Message-
 From: Sommers, Elizabeth [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, March 13, 2007 9:11 AM
 To: Maven Users List (E-mail)
 Subject: dependency plugin


 We woke up this morning to find that the dependency plugin was changed

 on 3/12/07.  We wouldn't have noticed except that we got the error 
 below.
 We solved our problem by versioning the plugin in our pom to 
 2.0-alpha-1 , but I figure others might be running into this today.

 Thanks
 Liz
 [EMAIL PROTECTED]

 -
 this realm =
 app0.child-container[org.apache.maven.plugins:maven-dependency-plugin]
 urls[0] =
 file:/c:/SB/.m2/repository/org/apache/maven/plugins/maven-dependency-p
 lu
 gin/2.0-alpha-2/maven-dependency-plugin-2.0-alpha-
 2.jar
 Number of imports: 0


 this realm = plexus.core.maven
 urls[0] = file:/c:/opt/maven2/lib/commons-cli-1.0.jar
 urls[1] = file:/c:/opt/maven2/lib/doxia-sink-api-1.0-alpha-7.jar
 urls[2] = file:/c:/opt/maven2/lib/jsch-0.1.24.jar
 urls[3] = file:/c:/opt/maven2/lib/maven-artifact-2.0.4.jar
 urls[4] = file:/c:/opt/maven2/lib/maven-artifact-manager-2.0.4.jar
 urls[5] = file:/c:/opt/maven2/lib/maven-core-2.0.4.jar
 urls[6] = file:/c:/opt/maven2/lib/maven-error-diagnostics-2.0.4.jar
 urls[7] = file:/c:/opt/maven2/lib/maven-model-2.0.4.jar
 urls[8] = file:/c:/opt/maven2/lib/maven-monitor-2.0.4.jar
 urls[9] = file:/c:/opt/maven2/lib/maven-plugin-api-2.0.4.jar
 urls[10] = file:/c:/opt/maven2/lib/maven-plugin-descriptor-2.0.4.jar
 urls[11] =
 file:/c:/opt/maven2/lib/maven-plugin-parameter-documenter-2.0.4.jar
 urls[12] = file:/c:/opt/maven2/lib/maven-plugin-registry-2.0.4.jar
 urls[13] = file:/c:/opt/maven2/lib/maven-profile-2.0.4.jar
 urls[14] = file:/c:/opt/maven2/lib/maven-project-2.0.4.jar
 urls[15] = file:/c:/opt/maven2/lib/maven-reporting-api-2.0.4.jar
 urls[16] = file:/c:/opt/maven2/lib/maven-repository-metadata-2.0.4.jar
 urls[17] = file:/c:/opt/maven2/lib/maven-settings-2.0.4.jar
 urls[18] =
 file:/c:/opt/maven2/lib/plexus-interactivity-api-1.0-alpha-4.jar
 urls[19] = file:/c:/opt/maven2/lib/wagon-file-1.0-alpha-7.jar
 urls[20] =
 file:/c:/opt/maven2/lib/wagon-http-lightweight-1.0-alpha-6.jar
 urls[21] = file:/c:/opt/maven2/lib/wagon-provider-api-1.0-alpha-6.jar
 urls[22] = file:/c:/opt/maven2/lib/wagon-ssh-1.0-alpha-7.jar
 urls[23] = file:/c:/opt/maven2/lib/wagon-ssh-external-1.0-alpha-6.jar
 Number of imports: 0


 this realm = plexus.core
 urls[0] =
 file:/c:/opt/maven2/core/plexus-container-default-1.0-alpha-9.jar
 urls[1] = file:/c:/opt/maven2/core/plexus-utils-1.1.jar
 Number of imports: 0
 -
 [INFO]
 --
 --
 [ERROR] BUILD ERROR
 [INFO]
 --
 -- [INFO] Internal error in the plugin manager executing goal
 'org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-2:unpack':
 Un able to find the mojo
 'org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-2:unpack' 
 in the plugin 'org.apache.maven.plugins:
 maven-dependency-plugin'
 org/codehaus/plexus/archiver/ArchiverException

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

2007-03-14 Thread Carlos Sanchez


metadata is updated, everything else stays unmodified after sync

On 3/14/07, Brian E. Fox [EMAIL PROTECTED] wrote:

Ok thanks. Is it only the removal of the folder that doesn't get
synched? I manually updated the metadata, and that must sync out right?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Wednesday, March 14, 2007 1:49 PM
To: Maven Users List
Cc: repository@apache.org
Subject: Re: dependency plugin

Brian, you need to notify repository@apache.org when you do this kind of
changes.
You removed it from apache but it was already in central and all the
mirrors.
I moved it out of the way now


On 3/13/07, Brian E. Fox [EMAIL PROTECTED] wrote:
 Hi Sorry about that. Alpha-2 was not supposed to be on central yet. I
 have updated the metadata files by hand to make it go away...it will
 take a few hours to rsync to the repo. The good news is that alpha-2
 is staged and being voted on. Baring any sudden issues, it should be
 released in ~60hrs from now.

 -Original Message-
 From: Sommers, Elizabeth [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, March 13, 2007 9:11 AM
 To: Maven Users List (E-mail)
 Subject: dependency plugin


 We woke up this morning to find that the dependency plugin was changed

 on 3/12/07.  We wouldn't have noticed except that we got the error
 below.
 We solved our problem by versioning the plugin in our pom to
 2.0-alpha-1 , but I figure others might be running into this today.

 Thanks
 Liz
 [EMAIL PROTECTED]

 -
 this realm =
 app0.child-container[org.apache.maven.plugins:maven-dependency-plugin]
 urls[0] =
 file:/c:/SB/.m2/repository/org/apache/maven/plugins/maven-dependency-p
 lu
 gin/2.0-alpha-2/maven-dependency-plugin-2.0-alpha-
 2.jar
 Number of imports: 0


 this realm = plexus.core.maven
 urls[0] = file:/c:/opt/maven2/lib/commons-cli-1.0.jar
 urls[1] = file:/c:/opt/maven2/lib/doxia-sink-api-1.0-alpha-7.jar
 urls[2] = file:/c:/opt/maven2/lib/jsch-0.1.24.jar
 urls[3] = file:/c:/opt/maven2/lib/maven-artifact-2.0.4.jar
 urls[4] = file:/c:/opt/maven2/lib/maven-artifact-manager-2.0.4.jar
 urls[5] = file:/c:/opt/maven2/lib/maven-core-2.0.4.jar
 urls[6] = file:/c:/opt/maven2/lib/maven-error-diagnostics-2.0.4.jar
 urls[7] = file:/c:/opt/maven2/lib/maven-model-2.0.4.jar
 urls[8] = file:/c:/opt/maven2/lib/maven-monitor-2.0.4.jar
 urls[9] = file:/c:/opt/maven2/lib/maven-plugin-api-2.0.4.jar
 urls[10] = file:/c:/opt/maven2/lib/maven-plugin-descriptor-2.0.4.jar
 urls[11] =
 file:/c:/opt/maven2/lib/maven-plugin-parameter-documenter-2.0.4.jar
 urls[12] = file:/c:/opt/maven2/lib/maven-plugin-registry-2.0.4.jar
 urls[13] = file:/c:/opt/maven2/lib/maven-profile-2.0.4.jar
 urls[14] = file:/c:/opt/maven2/lib/maven-project-2.0.4.jar
 urls[15] = file:/c:/opt/maven2/lib/maven-reporting-api-2.0.4.jar
 urls[16] = file:/c:/opt/maven2/lib/maven-repository-metadata-2.0.4.jar
 urls[17] = file:/c:/opt/maven2/lib/maven-settings-2.0.4.jar
 urls[18] =
 file:/c:/opt/maven2/lib/plexus-interactivity-api-1.0-alpha-4.jar
 urls[19] = file:/c:/opt/maven2/lib/wagon-file-1.0-alpha-7.jar
 urls[20] =
 file:/c:/opt/maven2/lib/wagon-http-lightweight-1.0-alpha-6.jar
 urls[21] = file:/c:/opt/maven2/lib/wagon-provider-api-1.0-alpha-6.jar
 urls[22] = file:/c:/opt/maven2/lib/wagon-ssh-1.0-alpha-7.jar
 urls[23] = file:/c:/opt/maven2/lib/wagon-ssh-external-1.0-alpha-6.jar
 Number of imports: 0


 this realm = plexus.core
 urls[0] =
 file:/c:/opt/maven2/core/plexus-container-default-1.0-alpha-9.jar
 urls[1] = file:/c:/opt/maven2/core/plexus-utils-1.1.jar
 Number of imports: 0
 -
 [INFO]
 --
 --
 [ERROR] BUILD ERROR
 [INFO]
 --
 -- [INFO] Internal error in the plugin manager executing goal
 'org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-2:unpack':
 Un able to find the mojo
 'org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-2:unpack'
 in the plugin 'org.apache.maven.plugins:
 maven-dependency-plugin'
 org/codehaus/plexus/archiver/ArchiverException

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: dependency plugin

2007-03-13 Thread Brian E. Fox

Hi Sorry about that. Alpha-2 was not supposed to be on central yet. I
have updated the metadata files by hand to make it go away...it will
take a few hours to rsync to the repo. The good news is that alpha-2 is
staged and being voted on. Baring any sudden issues, it should be
released in ~60hrs from now. 

-Original Message-
From: Sommers, Elizabeth [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 13, 2007 9:11 AM
To: Maven Users List (E-mail)
Subject: dependency plugin


We woke up this morning to find that the dependency plugin was changed
on 3/12/07.  We wouldn't have noticed except that we got the error
below.
We solved our problem by versioning the plugin in our pom to 2.0-alpha-1
, but I figure others might be running into this today.

Thanks
Liz
[EMAIL PROTECTED]

-
this realm =
app0.child-container[org.apache.maven.plugins:maven-dependency-plugin]
urls[0] =
file:/c:/SB/.m2/repository/org/apache/maven/plugins/maven-dependency-plu
gin/2.0-alpha-2/maven-dependency-plugin-2.0-alpha-
2.jar
Number of imports: 0


this realm = plexus.core.maven
urls[0] = file:/c:/opt/maven2/lib/commons-cli-1.0.jar
urls[1] = file:/c:/opt/maven2/lib/doxia-sink-api-1.0-alpha-7.jar
urls[2] = file:/c:/opt/maven2/lib/jsch-0.1.24.jar
urls[3] = file:/c:/opt/maven2/lib/maven-artifact-2.0.4.jar
urls[4] = file:/c:/opt/maven2/lib/maven-artifact-manager-2.0.4.jar
urls[5] = file:/c:/opt/maven2/lib/maven-core-2.0.4.jar
urls[6] = file:/c:/opt/maven2/lib/maven-error-diagnostics-2.0.4.jar
urls[7] = file:/c:/opt/maven2/lib/maven-model-2.0.4.jar
urls[8] = file:/c:/opt/maven2/lib/maven-monitor-2.0.4.jar
urls[9] = file:/c:/opt/maven2/lib/maven-plugin-api-2.0.4.jar
urls[10] = file:/c:/opt/maven2/lib/maven-plugin-descriptor-2.0.4.jar
urls[11] =
file:/c:/opt/maven2/lib/maven-plugin-parameter-documenter-2.0.4.jar
urls[12] = file:/c:/opt/maven2/lib/maven-plugin-registry-2.0.4.jar
urls[13] = file:/c:/opt/maven2/lib/maven-profile-2.0.4.jar
urls[14] = file:/c:/opt/maven2/lib/maven-project-2.0.4.jar
urls[15] = file:/c:/opt/maven2/lib/maven-reporting-api-2.0.4.jar
urls[16] = file:/c:/opt/maven2/lib/maven-repository-metadata-2.0.4.jar
urls[17] = file:/c:/opt/maven2/lib/maven-settings-2.0.4.jar
urls[18] =
file:/c:/opt/maven2/lib/plexus-interactivity-api-1.0-alpha-4.jar
urls[19] = file:/c:/opt/maven2/lib/wagon-file-1.0-alpha-7.jar
urls[20] =
file:/c:/opt/maven2/lib/wagon-http-lightweight-1.0-alpha-6.jar
urls[21] = file:/c:/opt/maven2/lib/wagon-provider-api-1.0-alpha-6.jar
urls[22] = file:/c:/opt/maven2/lib/wagon-ssh-1.0-alpha-7.jar
urls[23] = file:/c:/opt/maven2/lib/wagon-ssh-external-1.0-alpha-6.jar
Number of imports: 0


this realm = plexus.core
urls[0] =
file:/c:/opt/maven2/core/plexus-container-default-1.0-alpha-9.jar
urls[1] = file:/c:/opt/maven2/core/plexus-utils-1.1.jar
Number of imports: 0
-
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-2:unpack':
Un able to find the mojo
'org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-2:unpack' in
the plugin 'org.apache.maven.plugins:
maven-dependency-plugin'
org/codehaus/plexus/archiver/ArchiverException

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Dependency plugin and build-classpath goal issue

2007-01-24 Thread Brian E. Fox

Hi Gerald,
I'm hoping to finish up the 3-4 remaining issues in alpha-2 and call
another release in the next few weeks. The Maven Devs have decided to
always publish the latest version of the sites. The drawback is that
sometimes new goals are listed that haven't been released. The upshot is
that the sites can be corrected and updated more often. If we had to
wait for a release to publish the site, then there would be no way to
make any other changes to it. There is a tag @since that is supposed to
show up on the site to tell you about parameters and goals, but it
appears that the latest site plugin isn't generating it correctly.

-Original Message-
From: Nunn, Gerald [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 24, 2007 10:00 AM
To: Maven User List
Subject: Dependency plugin and build-classpath goal issue

Hi,

I'm trying to use the maven-dependency-plugin to build a classpath using
the build-classpath goal as documented here
http://maven.apache.org/plugins/maven-dependency-plugin/build-classpath-
mojo.html. However, when I try to execute this goal I get an error that
says that no such goal exists. Looking into it further I found that the
goal was added to 2.0-alpha-2 whereas the version in the central
repository is 2.0-alpha-1. Does anyone know of a repository with a
working 2.0-alpha-2 release, building it from source looks non-trivial
due to dependencies on other snapshot versions.

As an aside, why publish a site with goals that don't exist for a
non-public version? Shouldn't the plugin documentation on the site
reflect the currently widely available version not the soon to be
forthcoming version?

Thanks,

Gerald


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: dependency plugin

2006-11-09 Thread Sebastien Brunot

In fact I've already have a pom that describes the dependencies, as they
are shared by many modules. Using artifactItems on this pom with
unpack-dependencies will help me, except that I don't want the
transitive dependencies from the pom dependencies to be copied... Can I
use some sorts of exclusions tags with artifactItem ?

Thanks for your help,

Sebastien 

-Original Message-
From: Dan Tran [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 08, 2006 7:18 PM
To: Maven Users List
Subject: Re: dependency plugin

The main purpose of artifactItems is so that we dont need to use
dependencies elements.

perhaps, you need
http://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependenc
ies-mojo.html

-D



On 11/8/06, Sebastien Brunot [EMAIL PROTECTED] wrote:

 Hi all,

 is it possible to parameterize the dependency plugin unpack goal so 
 that it uses a pom dependencies section as input instead of an 
 artifactItems list ?

 Thanks for your help,

 Sebastien



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

2006-11-09 Thread Dan Tran


artifactItem does not support transitive dependencies.  so no need for
exclusion.
But you need to specify every item.

-D


On 11/9/06, Sebastien Brunot [EMAIL PROTECTED] wrote:


In fact I've already have a pom that describes the dependencies, as they
are shared by many modules. Using artifactItems on this pom with
unpack-dependencies will help me, except that I don't want the
transitive dependencies from the pom dependencies to be copied... Can I
use some sorts of exclusions tags with artifactItem ?

Thanks for your help,

Sebastien

-Original Message-
From: Dan Tran [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 08, 2006 7:18 PM
To: Maven Users List
Subject: Re: dependency plugin

The main purpose of artifactItems is so that we dont need to use
dependencies elements.

perhaps, you need
http://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependenc
ies-mojo.html

-D



On 11/8/06, Sebastien Brunot [EMAIL PROTECTED] wrote:

 Hi all,

 is it possible to parameterize the dependency plugin unpack goal so
 that it uses a pom dependencies section as input instead of an
 artifactItems list ?

 Thanks for your help,

 Sebastien



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: dependency plugin

2006-11-09 Thread Sebastien Brunot

I think I didn't manage to express clearly my concern: I have a pom
artifact that declare a list of (many) dependencies (let's name it the
optimized-3dparties-dependencies pom). In another module (actually an
EAR module), I want to pack the list of artifact declared in
optimized-3dparties-dependencies and build a single jar that contains
everything. I don't want transitivity on the dependencies declared in
optimized-3dparties-dependencies. So I was wondering how to do this
without re declaring my dependencies in an artifactItems tag.

Do you think it is possible with the existing plugins ?

Thanks for your help,

Sebastien

-Original Message-
From: Dan Tran [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 09, 2006 11:17 AM
To: Maven Users List
Subject: Re: dependency plugin

artifactItem does not support transitive dependencies.  so no need for
exclusion.
But you need to specify every item.

-D


On 11/9/06, Sebastien Brunot [EMAIL PROTECTED] wrote:

 In fact I've already have a pom that describes the dependencies, as 
 they are shared by many modules. Using artifactItems on this pom 
 with unpack-dependencies will help me, except that I don't want the 
 transitive dependencies from the pom dependencies to be copied... Can 
 I use some sorts of exclusions tags with artifactItem ?

 Thanks for your help,

 Sebastien

 -Original Message-
 From: Dan Tran [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 08, 2006 7:18 PM
 To: Maven Users List
 Subject: Re: dependency plugin

 The main purpose of artifactItems is so that we dont need to use 
 dependencies elements.

 perhaps, you need
 http://maven.apache.org/plugins/maven-dependency-plugin/unpack-depende
 nc
 ies-mojo.html

 -D



 On 11/8/06, Sebastien Brunot [EMAIL PROTECTED] wrote:
 
  Hi all,
 
  is it possible to parameterize the dependency plugin unpack goal so 
  that it uses a pom dependencies section as input instead of an 
  artifactItems list ?
 
  Thanks for your help,
 
  Sebastien
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

2006-11-09 Thread Dan Tran


not possible.

I have similar usecase and ended up to use artifactItems.  Btw
in artifactItem you dont need to define version, it will be looked in your
dependency list.

-D


On 11/9/06, Sebastien Brunot [EMAIL PROTECTED] wrote:


I think I didn't manage to express clearly my concern: I have a pom
artifact that declare a list of (many) dependencies (let's name it the
optimized-3dparties-dependencies pom). In another module (actually an
EAR module), I want to pack the list of artifact declared in
optimized-3dparties-dependencies and build a single jar that contains
everything. I don't want transitivity on the dependencies declared in
optimized-3dparties-dependencies. So I was wondering how to do this
without re declaring my dependencies in an artifactItems tag.

Do you think it is possible with the existing plugins ?

Thanks for your help,

Sebastien

-Original Message-
From: Dan Tran [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 09, 2006 11:17 AM
To: Maven Users List
Subject: Re: dependency plugin

artifactItem does not support transitive dependencies.  so no need for
exclusion.
But you need to specify every item.

-D


On 11/9/06, Sebastien Brunot [EMAIL PROTECTED] wrote:

 In fact I've already have a pom that describes the dependencies, as
 they are shared by many modules. Using artifactItems on this pom
 with unpack-dependencies will help me, except that I don't want the
 transitive dependencies from the pom dependencies to be copied... Can
 I use some sorts of exclusions tags with artifactItem ?

 Thanks for your help,

 Sebastien

 -Original Message-
 From: Dan Tran [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 08, 2006 7:18 PM
 To: Maven Users List
 Subject: Re: dependency plugin

 The main purpose of artifactItems is so that we dont need to use
 dependencies elements.

 perhaps, you need
 http://maven.apache.org/plugins/maven-dependency-plugin/unpack-depende
 nc
 ies-mojo.html

 -D



 On 11/8/06, Sebastien Brunot [EMAIL PROTECTED] wrote:
 
  Hi all,
 
  is it possible to parameterize the dependency plugin unpack goal so
  that it uses a pom dependencies section as input instead of an
  artifactItems list ?
 
  Thanks for your help,
 
  Sebastien
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

2006-11-08 Thread Dan Tran


The main purpose of artifactItems is so that we dont need to use
dependencies elements.

perhaps, you need
http://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependencies-mojo.html

-D



On 11/8/06, Sebastien Brunot [EMAIL PROTECTED] wrote:


Hi all,

is it possible to parameterize the dependency plugin unpack goal so that
it uses a pom dependencies section as input instead of an
artifactItems list ?

Thanks for your help,

Sebastien

RE: Dependency plugin support for time check on artifacts?

2006-01-24 Thread Brian E. Fox

Certainly. I have already undertaken a major refactoring of the code
because it had growing pains. Go ahead and submit the patch and I'll
include it with the refactor. BTW, the svn version 1.1 can control
SNAPSHOT and release overwrites separately...maybe that's all you need? 

-Original Message-
From: Sasvata Chatterjee [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 24, 2006 6:03 PM
To: Maven Users List
Subject: Dependency plugin support for time check on artifacts?

I am using the dependency plugin as the last step in a multiproject
build.  However when one or more dependent JARs are rebuilt, they are
not being expanded.  It is an either/or choice right now, to either
overwrite for all JARs, or to delete the marker dir.

Instead of checking if the marker exists, I tried a small change in
DependencyUtils to check if the artifact is newer  than the marker. 
This works great.  Works for the copy mojo as well.

Would this be an acceptable enhancement to the plugin? If so, I'll write
a JIRA issue and attach a patch.

Thanks,
Shash

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

58 matches

Mail list logo