On 18 Oct 07, at 10:40 PM 18 Oct 07, Brett Porter wrote:
rock on.
How are you going to implement? I'm presuming you also don't want
to download the previous artifact, so either will trust the
metadata, or maybe have a wagon.exists() method check that can HEAD
the file on HTTP and
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
+1
Emmanuel
Daniel Kulp a écrit :
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 can use it.
Staging areas:
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
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 ignore
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/07,
+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-win
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
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:59 AM,
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
+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 can use
I think that's a reasonable assumption. The worst cases I can think of:
- it deploys again if the metadata is missing or is missing the
version, no worse than now
- it doesn't deploy again if the metadata thinks it is there and it
isn't (which we can state clearly with a message so there'll
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-win strategy.
Since the codebase has changed a lot, I expect some regressions
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
scopeimport/scope.
2. scopeimport/scope could be used on a dependency in
dependencyManagement that is not a pom.
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:
20 matches
Mail list logo
