So if i understand how to fix my trouble with the axistools plugin :
To summarize my problem :
My problem is to add a new resource after compilation.
I had this problem because i want to create and API for web service and
generate the wsdl from that API.
Then use that API in the client side and server side and also use the
generated wsdl to generate java files.
There's now 2 ways : the wsdl file is added in the jar of the api or the
wsdl file is attached as a classifier to the api.jar
To fix the problem :
- allow the adding of resource post compilation (to have the wsdl in the
jar)
- move the generate-resources phase after compilation (as it is not
needed to compile, the only constraint is to have the resource well
placed before testing)
- create a new packaging (say axis-api) for axistools which binds the
generate-resource phase between compilation and test
The third one has my preference.
Maybe a way to get rid of the phases proliferation is to make
proliferate the packagings.
Therefore, the complexity of the phases are hidden in the
plugins-packaging and not shown in the pom which add the confusion to
the users.
Is that makes sense ?
Raphaël
John Casey a écrit :
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 :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
