>> >> a) Because it can generate code for multiple appservers it doesn't >> make >> sense to invoke it in a container-specific plugin. >> > > IMHO it does make sense.
But my point is that the <ejbdoclet> task is *mostly* the same for any appserver. Its only when you add the subtasks that it gets appserver specific. Do you want to have a jboss:ejbdoclet and a weblogic:ejbdoclet goal when both of them are going to be 80% the same? Or maybe I'm confused or maybe we're talking about two different things. I should be posting my patch soon, maybe you can guide me in the right direction once you see it. > > It almost makes no difference if you type > > maven ejb:jar > or > maven jboss:ejb-jar > > And maven ejb:jar can briefly do entire work if it can be decorated at > appropratie call-back points (read: drop dependency on ant). Right. That makes sense. Where I'm struggling is with code reuse of the <ejbdoclet> task (for instance). > > My opinion is: we should support automated management of plugins ASAP > And let people/small communities maintain their own plugins. > > BTW: Who says there should be only one ejb plugin? > > I am using XDoclet every day and from this point of view > It would better for me if it were included in maven distribution. Likewise. I'd rather "generalize" the plugins I've created locally and make them available to the community at large. That way more people get the benefit the plugins and the plugins get more useful. > > But from the point of view of Maven it is not a good thing. > Basically in plugins we have thousand of lines of code which are not > tested and this is getting out of control. I guess I was assuming that the folks contributing the plugins are actually *using* them. Of course, when maven's internals change in a way that can break jelly scripts contributors may not realize it immediately. > I am not using any EJB container at the moment. Not many active Maven > developers do. I can't say. Has anybody done a poll? Does it really matter anyway? > Probably Vincent has the biggest experience here but he is also probably > not using every possible application server. > So nobody will be able to test your even code manually (saying nothing > about automated tests). And once this code sits in our CVS we should > maintain it, manages bugs etc. IMHO Maven developers should not take > such responsibility. > > Michal > > P.S. > > Still go ahead with your patches ... it's fine if they are in JIRA. Coming soon :-) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
