Stephane Bailliez wrote: >
Could you please give me a valid argument that force you to do this to test *your* task ?!
Is it too much to ask people dropping your jar task in ANT_HOME/lib and use a taskdef like it is done in many places around ? Is Turbine delivering its own Ant distribution for Torque tasks ? Is Velocity delivering its own Ant dist for Texen task ?
I have seen newbie developpers delivering stuff similarly in a company. Update, fixes and such were done via email. No label set. No tag in the jar. Nothing. Pretty easy to figure what code is a build using.
I'm totally against this practice. This is a big -1 from me.
Stephane, lets not assume the worst :-). Maybe Cyrille didn't think about the best way to package this up. Then again, you may not realize that what is being proposed here is a new component of the <ejbjar> task and it is not easy to provide it as a standalone package. It requires a modification of the standard, optional <ejbjar> task. It may have been sufficient to provide a new optional.jar to allow users to test it.
This flows on from the discussion we have been having about plug-in interfaces in tasks that are extensible such as <ejbjar>. It is not impossible nor difficult to provide such pluggability to <ejbjar> if you are prepared to support tasks which can programtically determine their allowed nested elements. Unfortunately not everyone supports such capability.
Anyway, Cyrille was specifically asked by Steve to gather some feedback from Jonas users before the changes could be committed.
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
