Am 07/02/16 um 16:59 schrieb Robert Scholte:
>
> I agree that this should have been commons-io:2.4, but it matches the
> documentation (g:a is unique and nearest wins). I expect that the problem
> lies in the way Aether is used.
> I assume that first the complete dependency graph is collected
On Sat, 02 Jul 2016 16:31:41 +0200, Christian Schulte
wrote:
Am 07/02/16 um 15:25 schrieb Robert Scholte:
Hi,
It is very likely that a previous version of maven-shared-utils did not
depend on commons-io, which made it required to specify commons-io with
the test-scope for this project.
Th
Am 07/02/16 um 15:25 schrieb Robert Scholte:
> Hi,
>
> It is very likely that a previous version of maven-shared-utils did not
> depend on commons-io, which made it required to specify commons-io with
> the test-scope for this project.
That's what I assume as well.
> With this in mind it see
Hi,
there's this basic rule: always specify your direct dependencies if you
use them in your code, never rely on transitive dependencies.
So in this case commons-io is not directly used by the main classes, but
it is by the test-classes.
It is very likely that a previous version of maven-shar
Hi,
On 7/1/16 9:03 PM, Christian Schulte wrote:
Am 07/01/16 um 20:11 schrieb Karl Heinz Marbaise:
Hi,
wouldn't it make sense to create a branch for Maven 3.5.0 ? And
summarize all changes there ? Makes it more clear ?
Cause there are some issues fixed related to JIRA...for 3.5.0 ?
WDYT ?
Am 07/01/16 um 20:11 schrieb Karl Heinz Marbaise:
> Hi,
>
> wouldn't it make sense to create a branch for Maven 3.5.0 ? And
> summarize all changes there ? Makes it more clear ?
>
> Cause there are some issues fixed related to JIRA...for 3.5.0 ?
>
> WDYT ?
>
>
Already done. That's the MNG-60
Hi,
wouldn't it make sense to create a branch for Maven 3.5.0 ? And
summarize all changes there ? Makes it more clear ?
Cause there are some issues fixed related to JIRA...for 3.5.0 ?
WDYT ?
Kind regards
Karl Heinz Marbaise
On 7/1/16 9:16 AM, Christian Schulte wrote:
Hi,
I am currently s
Not sure I completely understand the question, but we've always said that
you shouldn't use another plugin as a dependency. Re-usable logic should be
kept in a library instead.
/Anders
On Fri, Jul 1, 2016 at 9:16 AM, Christian Schulte wrote:
> Hi,
>
> I am currently stumbling upon the following
Hi,
I am currently stumbling upon the following issue. Maven resolves
plugins as if they were a direct dependency of Maven core. That means it
will not consider any 'test' or 'provided' scope dependencies of plugins
when building plugin runtime classpaths. I am not sure if this is the
correct way
on this or planned
to be done on this, or if this was considered something outside the scope of
the Maven eclipse plugin project.
Thank you
Yours
Misha Koshelev
--
View this message in context:
http://maven.40175.n5.nabble.com/mvn-eclipse-plugin-resolution-installation-of-Eclipse-plug-ins-from
olved this problem? I am
> assuming
> > that I picked up the codehaus plugin transitively, since I don't have any
> > direct dependencies on it (yet).
>
> You shouldn't have had a problem if the plugin was declared in your
> project's pom. I'm guessing it
since I don't have any
> direct dependencies on it (yet).
You shouldn't have had a problem if the plugin was declared in your
project's pom. I'm guessing it wasn't declared and so Maven picked up
the Mojo version via the plugin resoluti
element:
>
>
> http://maven.apache.org/ref/2.0.8/maven-settings/settings.html#class_settings
>
> By the way, the Codehaus apt plugin now supersedes Tobago's plugin:
>
> https://issues.apache.org/jira/browse/TOBAGO-656
>
> Cheers,
>
> Mark
>
> 2008/6/18 Evan
: Maven Developers List
Subject: Re: Plugin resolution
2008/6/18 Brian E. Fox <[EMAIL PROTECTED]>:
> The order is first pluginGroups, then apache, then mojo.
Mojo is built-in? That seems a bit counter-intuitive.
Mark
---
2008/6/18 Brian E. Fox <[EMAIL PROTECTED]>:
> The order is first pluginGroups, then apache, then mojo.
Mojo is built-in? That seems a bit counter-intuitive.
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comman
The order is first pluginGroups, then apache, then mojo.
-Original Message-
From: Mark Hobson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2008 4:23 AM
To: Maven Developers List
Subject: Re: Plugin resolution
Hi Evan,
It sounds like you've picked up the apt-maven-plugin ov
en-settings/settings.html#class_settings
By the way, the Codehaus apt plugin now supersedes Tobago's plugin:
https://issues.apache.org/jira/browse/TOBAGO-656
Cheers,
Mark
2008/6/18 Evan Worley <[EMAIL PROTECTED]>:
> Hey All,
>
> I have a general question about the plugin resol
Hey All,
I have a general question about the plugin resolution policy.
For a while now, we've been using the maven-apt-plugin (
http://myfaces.apache.org/tobago/tobago-tool/maven-apt-plugin/index.html).
To invoke the plugin directly, we would just run "mvn apt:execute".
Som
20, 2007 12:48 PM
To: Maven Developers List
Subject: RE: Plugin Resolution Bug?
Go ahead and open one, then let me know what it is. I did the code for
2.0.7 so I'll check it out before we do 2.0.8
-Original Message-
From: Jan Nielsen [mailto:[EMAIL PROTECTED]
Sent: Saturday, Octob
Go ahead and open one, then let me know what it is. I did the code for
2.0.7 so I'll check it out before we do 2.0.8
-Original Message-
From: Jan Nielsen [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 20, 2007 11:26 AM
To: Maven Developers List
Subject: Re: Plugin Resolutio
roups you have defined, then
> maven, then codehaus.
>
> -Original Message-
> From: Jan Nielsen [mailto:[EMAIL PROTECTED]
> Sent: Saturday, October 20, 2007 10:44 AM
> To: Maven Developers List
> Subject: Re: Plugin Resolution Bug?
>
> Yes; thanks, Wayne - Marco
In 2.0.7, it should first look in pluginGroups you have defined, then
maven, then codehaus.
-Original Message-
From: Jan Nielsen [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 20, 2007 10:44 AM
To: Maven Developers List
Subject: Re: Plugin Resolution Bug?
Yes; thanks, Wayne - Marco
Yes; thanks, Wayne - Marco from Triemax mentioned that this
fully-qualified form should work, and it does:
mvn triemax:jalopy-maven:format
So, that's my current work-around. But really, despite the unfortunate
name clash on "jalopy" it seems to me that this should work with a
properly defined p
Try using the "full name" of the plug-in, something along these lines:
mvn clean triemax:jalopy-maven-plugin:1.0:format
If you couldn't tell, that's groupId:artifactId:version:mojo.
Wayne
On 10/17/07, Jan Nielsen <[EMAIL PROTECTED]> wrote:
> I have configured our local repository as a single rep
I have configured our local repository as a single repository,
mirroring all repository requests, and I have configured the plugin
groups to use "triemax":
triemax
internal-repository
Maven Repository Manager
http://it.access.dev/repository
*
Howe
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 10:35 PM
To: Maven Developers List
Subject: Re: plugin resolution
It seems the search order is back to front, we had the same problem with
Jetty.
- Brett
On 13/09/2006, at 12:26 PM
It seems the search order is back to front, we had the same problem
with Jetty.
- Brett
On 13/09/2006, at 12:26 PM, Brian E. Fox wrote:
I'm trying to test the new version of maven-dependency-plugin by
executing a simpler CLI invocation like: mvn dependency:resolve. For
some reason, mvn keeps
I'm trying to test the new version of maven-dependency-plugin by
executing a simpler CLI invocation like: mvn dependency:resolve. For
some reason, mvn keeps finding the mojo version dependency-maven-plugin
and executing that. Any idea why it's not picking up the correct one in
my local repo?
Than
[ http://jira.codehaus.org/browse/MNG-489?page=all ]
Brett Porter closed MNG-489:
Resolution: Fixed
> trim plugin resolution to those needed, to avoid unnecessary dep resolution
> for unused p
trim plugin resolution to those needed, to avoid unnecessary dep resolution for
unused plugins
--
Key: MNG-489
URL: http://jira.codehaus.org/browse/MNG-489
Project: Maven 2
30 matches
Mail list logo
