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 just tried to implement this reflection-based option.
My tasks added in the plugin context by a custom plugin are not retrieved in
the war plugin.
In fact, the pluginContext Map is a different object reference in the two
plugins.
Isn't the pluginContext designed to share datas between plugins ?
I am currently working with the maven-model project and have found an
issue in the generated RepositoryBase class. It seems the "equals"
method violates the contract of "equals" by immediately casting the
input parameter to RepositoryBase. This causes a ClassCastException if
anything besides a Repo
actually I rolled back my workaround files must not be locked, test is
right and code needs to be fixed
On 10/19/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> that won't help either, you are not checking the return value of
> renameTo that obviously fails as delete does
> I have made the test ig
This is a not uncommon issue raised on the Users list, so I'm happy to
see you addressing it, Jason. The general suggestion until now has
been "run Archiva or similar" or "run cron every hour to set -r on all
artifacts in your repo" but a "native Maven solution" will be much
nicer.
Wayne
On 10/19
+1
--
Olivier
2007/10/19, Stephane Nicoll <[EMAIL PROTECTED]>:
>
> Hi,
>
> I'd like to release maven war plugin 2.1-alpha-1. This version brings
> a complete refactoring of the packaging as well as the overlay
> mechanism. One can now specify the order in which overlays are applied
> in a "first-
that won't help either, you are not checking the return value of
renameTo that obviously fails as delete does
I have made the test ignore the error deleting so i can build but
there's an underlying problem that the files are locked after the
container is disposed.
On 10/19/07, [EMAIL PROTECTED] <[
I don't know that confluence was designed for debates so I am posting
this here.
Mark, while I appreciate your feedback I have to take issue with the -1.
In all the groups that I work with that use Maven every single one of
the Configuration Management teams that manages the projects requires
Looks like these were still outstanding and sitting in my task list
(the first one was done though).
Other opinions on the last one before I file them all?
- Brett
On 24/09/2007, at 5:59 AM, Christian Edward Gruber wrote:
+1, except for the last one, but only +0 for that.
Christian.
On 23
Yes, just now... did I miss something?
On 19/10/2007, at 10:14 PM, olivier lamy wrote:
have you tried the current trunk ?
;-)
--
Olivier
2007/10/19, Brett Porter <[EMAIL PROTECTED]>:
Looks like these were still outstanding and sitting in my task list
(the first one was done though).
Other
have you tried the current trunk ?
;-)
--
Olivier
2007/10/19, Brett Porter <[EMAIL PROTECTED]>:
>
> Looks like these were still outstanding and sitting in my task list
> (the first one was done though).
>
> Other opinions on the last one before I file them all?
>
> - Brett
>
> On 24/09/2007, at 5
I just realize that for plugins to share components, we need to consider
classloaders issues : a WarPackagingTask created wy a plugin and passed in
the plugin context is not assignable to WarPackagingTask class in the war
plugin classloader, due to per-plugin classloaders.
Would it be possible to
An option would be to use reflection to avoid classloaders issues :
Create a ReflectWarPackagingTask that invokes performPackaging by
reflection, so that the passed-by-plugin-context tasks are not casted into
WarPackagingTask.
Nico.
2007/10/19, nicolas de loof <[EMAIL PROTECTED]>:
>
> I just re
+1.
--
Olivier
2007/10/18, Daniel Kulp <[EMAIL PROTECTED]>:
>
>
> The Continuum crew had a bunch of good suggestions to make the generated
> NOTICE files more organized and more readable as well as reproduceable.
> (sorted instead of random map ordering) I'd like to get this released
> so they c
The side effects I am aware of are:
1. Someone already specified a pom as a dependency in dependencyManagement
(I can't imagine why, but it is possible). This was mitigated by using
import.
2. import could be used on a dependency in
dependencyManagement that is not a pom. The code detects that an
I need to think about this some more, but at first blush it could be useful. I
need to think about any possible side effects.
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Friday, October 19, 2007 11:08 AM
To: Maven Developers List
Subject: Re: [codehaus-confluence
16 matches
Mail list logo
