The more I think of it, the more I dislike this solution, actually. It
simply doesn't address the larger problem, as Raphael inadvertently
pointed out. ;-)
The only trouble with strict ordering comes with the syntax, and dealing
with the various layers of inheritance and injection. Plugin bindings
can come from:
1. packaging lifecycle mapping
2. parent POM
3. profiles
4. POM
5. (am I missing something?)
So, any syntax would have to support this layering in a way that
wouldn't be overly confusing.
FWIW, I think I have a band-aid on my client's project that will work
for the time being. I'd much rather see this stuff fixed correctly soon,
rather than have 10,000 lifecycle phases to support for backward
compatibility later on...
-john
Jesse McConnell wrote:
+1 on this, with a caveat....it is a huge slippery slope that I think we
ought to be really clear on...especially since Raphaël already took us down
the slope some more :P
I am +1 for adding these in to address the immediate need with the
understanding that that is it and revisit the issue for the next layer of
complexity with some type of ordering maybe..
Providing a mechansim of strict execution ordering inside of a lifecycle
phase could address this.. Custom lifecycle phases and goals declared in
the pom that can be bound by plugins inside of the pom? (icky) Otherwise it
is just too easy to keep adding on layers of pre and post processing :)
my 2cents
--
to address the axistools pluign, we have discussed this on irc before. it
is completely reasonable to compile some classes, generate a wsdl off of
those classes for something like a server side wrapping of webservices and
then want to generate the client code off of that wsdl..
but what we decided at the time was that it was also ok to just embed that
wsdl into the final jar and then in another project process that wsdl out of
the dependency jar and generate the client code...perhaps that can be
revisited, but the idea of having to support a compile -> generate sources
-> compile cycle is not one that has been addressed completely. Especially
since I have personally written 4 plugins that needed this type of cycle
already, and just swiped code out of the compiler mojo to do it :P
jesse
On 2/17/06, Piéroni Raphaël <[EMAIL PROTECTED]> wrote:
+1
can you add a post-compile-generate-resources phase ? sometimes a resource
is generated (wsdl file) after the compile phase.
for example, the axistool plugin needs for the classes to be generated in
order to generated the wsdl files from them. and the plugin also try to
add
it to the resources.
Raphaël
2006/2/17, Emmanuel Venisse <[EMAIL PROTECTED]>:
+1
Emmanuel
John Casey a écrit :
Hi,
I'd like to add pre/post phases for all of the major lifecycle phases
that don't already have it. I'm starting to see cases where a
particular
packaging maps multiple mojos to the same lifecycle phase, and this
means we cannot control that phase through the old
suppress-and-augment
approach anymore. I'll give you an example:
Say I have two mojos bound to the package phase, for lack of a better
place. The first takes the tested code, and assembles the directory
structure for the archive. The second creates the archive. If I want
to
replace the first step, I can add a 'skip' flag to it, but I *cannot*
bind a new mojo in its place; any new binding will be added after the
second step. Obviously, it makes no sense to prepare an archive
directory structure *after* the archive is created.
This is not the first time we've discussed this sort of thing. We have
pre/post phases for setup and tear-down of integration tests, and
should
probably have something similar for unit tests...not to mention,
install, deploy...
It doesn't seem like a good idea to continue addressing this problem
an
issue at a time in successive Maven releases. Why not make a
reasonable
concession to these use cases, and add pre/post phases to each major
lifecycle phase (those which are themselves pre/post phases are not
what
I consider major).
I'd like to get this into 2.0.3, since it affects some work I'm doing
for a client.
What do you all think?
-john
---------------------------------------------------------------------
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]
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
