Re: [DISCUSS] Extend Mojo API to allow for resolution of multiple dependency scopes

On 2-Aug-09, at 2:40 PM, Benjamin Bentmann wrote: Brian Fox wrote: In the dependency and enforcer plugins where I potentially need everything, I just ask for test to be resolved and then i pick the elements i need. Yeah, I know, the problem I described is not impossible to solve. All I wo

Yves Van Steen is out of the office.

I will be out of the office starting 03/08/2009 and will not return until 14/08/2009. I will respond to your message when I return.

Re: [DISCUSS] Extend Mojo API to allow for resolution of multiple dependency scopes

On Mon, Aug 3, 2009 at 7:10 AM, Benjamin Bentmann wrote: > Brian Fox wrote: > >> In the dependency and enforcer plugins where I potentially need >> everything, I just ask for test to be resolved and then i pick the >> elements i need. > > Yeah, I know, the problem I described is not impossible to s

Re: [DISCUSS] Extend Mojo API to allow for resolution of multiple dependency scopes

Brian Fox wrote: In the dependency and enforcer plugins where I potentially need everything, I just ask for test to be resolved and then i pick the elements i need. Yeah, I know, the problem I described is not impossible to solve. All I wondered is whether this pattern does not give evidence

Re: [DISCUSS] Extend Mojo API to allow for resolution of multiple dependency scopes

In the dependency and enforcer plugins where I potentially need everything, I just ask for test to be resolved and then i pick the elements i need. On Sun, Aug 2, 2009 at 2:28 PM, Benjamin Bentmann wrote: > Brian Fox wrote: > >> I think those bugs may be due to the plugin using the runtime scope >

Re: [DISCUSS] Extend Mojo API to allow for resolution of multiple dependency scopes

Brian Fox wrote: I think those bugs may be due to the plugin using the runtime scope not the runtime classpath? The runtime classpath should include the compile scope artifacts. Let my try to describe the problem in more detail. Assume the following POM snippet for the project that wants to e

Re: svn commit: r800032 - in /maven/plugins/trunk/maven-linkcheck-plugin: pom.xml src/main/java/org/apache/maven/plugins/linkcheck/LinkcheckReport.java

Hi Vincent, Think about plugins which use ${project.reporting.outputDirectory} in there conf. A properly [0] implemented reporting plugin must not use this value during the site lifecycle. But you're right, updating the model is more robust as it captures the buggy plugins as well. Benjam

Re: svn commit: r800032 - in /maven/plugins/trunk/maven-linkcheck-plugin: pom.xml src/main/java/org/apache/maven/plugins/linkcheck/LinkcheckReport.java

Hi Benjamin, 2009/8/2 Benjamin Bentmann : > This also requires to bump the on Maven, e.g. older Maven > versions don't support MavenProject.clone() and will die with a linkage > error upon executing the mojo. Right and it is why I bump to 2.0.9 dep! > Consider to output the error message at err

Re: svn commit: r800032 - in /maven/plugins/trunk/maven-linkcheck-plugin: pom.xml src/main/java/org/apache/maven/plugins/linkcheck/LinkcheckReport.java

Hi Vincent, Author: vsiveton Date: Sun Aug 2 11:24:25 2009 New Revision: 800032 URL: http://svn.apache.org/viewvc?rev=800032&view=rev Log: o using maven 2.0.9 This also requires to bump the on Maven, e.g. older Maven versions don't support MavenProject.clone() and will die with a linkage

Re: svn commit: r799840 - in /maven/plugins/trunk/maven-linkcheck-plugin: pom.xml src/main/java/org/apache/maven/plugins/linkcheck/LinkcheckReport.java

Hi Benjamin, 2009/8/1 Benjamin Bentmann : > Keep in mind that the JVM might be running much longer than the Maven build, > e.g. when Maven is embedded in an IDE or CI server. Therefore I suggest to > delete the temp file not via a shutdown hook but explicitly once the mojo is > done with it (e.g.