Re: Dependency plugin unpack plugin dependencies
Hi Alexander, this is an old thread, but no one has replied yet. While I think this is possible – what are you trying to achieve? Or in other words: WHY do you need the dependencies unpacked? What do you do with them? Regards, Ben On 2020/08/19 18:23:06, Alexander Broekhuis wrote: > Hi all, > > I currently have a setup in which I have some custom artifacts that I use > as dependencies and unpack using unpack-dependencies. > This all works great, but now I also have a custom plugin which needs one > of the custom artifacts as dependency. I don't see those dependencies being > unpacked. Is this correct, or am I doing something wrong? > > I know I can add the dependency as "regular" dependency as workaround, but > I'd like to be able to define the plugin in a parent's pluginManagement > with it's dependencies so that dependant project can enable the plugin when > needed without having to define the dependency, or always have it being > unpacked even if not needed. > > Basically my pom looks like this (meta): > > // Those are unpacked as expected > > > > > // Those dependencies are not unpacked > > > > > > > > > -- > Met vriendelijke groet, > > Alexander Broekhuis > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Dependency plugin: tree, CLI substitution error
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 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 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
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
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=revision&revision=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: > > > > > > org.apache.maven.doxia > > doxia-sink-api > > 1.4 > > > > > > org.apache.maven.doxia > > doxia-site-renderer > > 1.4 > > > > > > 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 : > > > > 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 th
Re: dependency plugin fails with >9 threads
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=revision&revision=1591759 Kristian 2014-05-01 21:25 GMT+02:00 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: > > > org.apache.maven.doxia > doxia-sink-api > 1.4 > > > org.apache.maven.doxia > doxia-site-renderer > 1.4 > > > 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 : > > 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
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: org.apache.maven.doxia doxia-sink-api 1.4 org.apache.maven.doxia doxia-site-renderer 1.4 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 : > 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
It makes a lot of sense. Cheers, On 18 April 2014 19:20, MK Tan 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 >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 > > version&lifecycle 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 automatic version resolution
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 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 > version&lifecycle 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 strangeness
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" 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 > >> 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 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
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 > 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 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
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 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
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" 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 versus the reactor
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 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
On 13 February 2012 18:20, 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
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 Fox" 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 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
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" 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 > 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
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 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
Hmm it seems I solved this by adding: clean install to release plugin. But still, should reactor be searched be dependency plugin. On Fri, Jul 30, 2010 at 12:05 PM, Bartosz Baranowski wrote: > 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
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 :
> 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)
>
>> Hi there,
>>
>> I'm facing a strange behavior with the dependency plugin. Here is my
>> configuration
>>
>>
>> org.apache.maven.plugins
>> maven-dependency-plugin
>> 2.1
>>
>>
>> copy-dependencies
>> process-sources
>>
>> copy-dependencies
>>
>>
>> ${basedir}/target/site/demo
>> false
>> true
>> true
>> true
>>
>>
>>
>> unpack
>> process-sources
>>
>> unpack
>>
>>
>>
>>
>> net.sourceforge.floggy
>> floggy-persistence-weaver
>> ${basedir}/target/site
>> schema/*
>>
>>
>>
>>
>>
>>
>>
>> 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
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:
copy-dependencies
process-sources
copy-dependencies
floggy-persistence-weaver
${basedir}/target/site/demo
false
true
true
true
unpack
process-sources
unpack-dependencies
floggy-persistence-weaver
${basedir}/target/site
schema/*
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)
>
> > Hi there,
> >
> > I'm facing a strange behavior with the dependency plugin. Here is my
> > configuration
> >
> >
> > org.apache.maven.plugins
> > maven-dependency-plugin
> > 2.1
> >
> >
> > copy-dependencies
> > process-sources
> >
> > copy-dependencies
> >
> >
> > ${basedir}/target/site/demo
> > false
> > true
> > true
> > true
> >
> >
> >
> > unpack
> > process-sources
> >
> > unpack
> >
> >
> >
> >
> > net.sourceforge.floggy
> > floggy-persistence-weaver
> > ${basedir}/target/site
> > schema/*
> >
> >
> >
> >
> >
> >
> >
> > 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
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)
> Hi there,
>
> I'm facing a strange behavior with the dependency plugin. Here is my
> configuration
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.1
>
>
> copy-dependencies
> process-sources
>
> copy-dependencies
>
>
> ${basedir}/target/site/demo
> false
> true
> true
> true
>
>
>
> unpack
> process-sources
>
> unpack
>
>
>
>
> net.sourceforge.floggy
> floggy-persistence-weaver
> ${basedir}/target/site
> schema/*
>
>
>
>
>
>
>
> 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
On Tue, Jan 26, 2010 at 9:29 AM, Thiago Moreira (timba) 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 "outputFile" parameter not working...
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 "outputFile" parameter not working...
> 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: understanding its output
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 : > > 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 (versi
Re: dependency plugin
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: >> >> >> foo.bar >> myjar >> 1.0.0-SNAPSHOT >> jar >> compile >> >> >> >> org.apache.maven.plugins >> maven-dependency-plugin >> 2.0 >> >> >> getjar >> generate-sources >> >> unpack >> >> >> >> >> foo.bar >> myjar >> jar >> true >> >> target/tmp >> >> >> >> true >> true >> >> >> >> >> >> 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
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: >> >> >> foo.bar >> myjar >> 1.0.0-SNAPSHOT >> jar >> compile >> >> >> >> org.apache.maven.plugins >> maven-dependency-plugin >> 2.0 >> >> >> getjar >> generate-sources >> >> unpack >> >> >> >> >> foo.bar >> myjar >> jar >> true >> >> target/tmp >> >> >> >> true >> true >> >> >> >> >> >> 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
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 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
I see, so what you suggest is add install to the 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
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
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: foo.bar myjar 1.0.0-SNAPSHOT jar compile org.apache.maven.plugins maven-dependency-plugin 2.0 getjar generate-sources unpack foo.bar myjar jar true target/tmp true true 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
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: > > > foo.bar > myjar > 1.0.0-SNAPSHOT > jar > compile > > > > org.apache.maven.plugins > maven-dependency-plugin > 2.0 > > > getjar > generate-sources > > unpack > > > > > foo.bar > myjar > jar > true > > target/tmp > > > > true > true > > > > > > 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
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
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
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
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
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 and version
Just wanted to report back that I finally go this to work by doing
this (thanks for the clues along the way):
org.apache.maven.plugins
maven-war-plugin
${project.build.directory}/dependency
**/*.jar
**/*.jnlp
org.codehaus.mojo
dependency-maven-plugin
process-resources
unpack-dependencies
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: "[8,)" but that did not work.
> > >
> > >
> > > org.codehaus.mojo
> > > dependency-maven-plugin
> > >
> > >
> > >
> > > process-resources
> > >
> > > unpack
> > >
> > >
> > >
> > >
> > >
> > >
> > > com.vzb.impact
> > > webstart-test
> > > 8.1.2
> > > zip
> > >
> > >
> > > ${project.build.directory}/${project.build.finalName} > > outputDirectory>
> > >
> > >
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dependency plugin] Used undeclared dependencies
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
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: "[8,)" but that did not work.
>
>
> org.codehaus.mojo
> dependency-maven-plugin
>
>
>
> process-resources
>
> unpack
>
>
>
>
>
>
> com.vzb.impact
> webstart-test
> 8.1.2
> zip
>
>
> ${project.build.directory}/${project.build.finalName} outputDirectory>
>
>
>
> -
> 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
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: "[8,)" but that did not work.
> >
> >
> > org.codehaus.mojo
> > dependency-maven-plugin
> >
> >
> >
> > process-resources
> >
> > unpack
> >
> >
> >
> >
> >
> >
> > com.vzb.impact
> > webstart-test
> > 8.1.2
> > zip
> >
> >
> > ${project.build.directory}/${project.build.finalName} > outputDirectory>
> >
> >
> >
> > -
> > 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 and version
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: "[8,)" but that did not work.
org.codehaus.mojo
dependency-maven-plugin
process-resources
unpack
com.vzb.impact
webstart-test
8.1.2
zip
${project.build.directory}/${project.build.finalName}
-
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
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
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
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
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
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
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
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
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
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
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
You can use maven-dependency-plugin:2.0-alpha-1-SNAPSHOT or use the dependency-maven-plugin:1.0 unpack goal and just list the artifacts you want to unpack. -Original Message- From: Sommers, Elizabeth [mailto:[EMAIL PROTECTED] Sent: Monday, December 18, 2006 4:10 PM To: Maven Users List (E-mail) Subject: dependency plugin I have just spent a lot of time trying to get the dependency-maven-plugin to excludeScope, or if that won't work - to excludeTransitive. Neither work. Using a simple didn't work either. When I try to use the maven-dependency-plugin I get the The plugin 'org.apache.maven.plugins:maven-dependency-plugin' does not exist or no valid version could be found error Where can I find a WORKING version of this plugin? I need to unpack this beast, but I don't want every transitive dependency that is offered me. Thanks Liz [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency plugin
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 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 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 tags with ? > > 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 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 section as input instead of an > > 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
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 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 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 tags with ? > > 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 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 section as input instead of an > > 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
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 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 tags with ? 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 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 section as input instead of an > list ? > > Thanks for your help, > > Sebastien > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependency plugin
In fact I've already have a pom that describes the dependencies, as they are shared by many modules. Using 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 tags with ? 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 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 section as input instead of an > list ? > > Thanks for your help, > > Sebastien > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency plugin
The main purpose of 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 section as input instead of an list ? Thanks for your help, Sebastien
Re: Dependency plugin support for time check on artifacts?
On 1/24/06, Brian E. Fox <[EMAIL PROTECTED]> wrote: > 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? > Done: http://jira.codehaus.org/browse/MOJO-259. I saw the overwrite option, but as I understand it, if I were to choose SNAPSHOT overwrite, then all SNAPSHOT JARs would be overwritten on every build. What I am looking for is to expand only the JARs that have actually changed since the last build. The project I am working on has fine-grained selection of API/impl(s), i.e. lots-o-dependencies, so it is important to cut down on any expansions that are not absolutely required. BTW, thanks for this plugin, an absolute godsend for what I needed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependency plugin support for time check on artifacts?
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]
