> -----Original Message----- > From: James CE Johnson [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 31, 2003 2:44 PM > To: [EMAIL PROTECTED] > Subject: RE: EJB plugin modification > > Hi Michal, > > My $.02 worth... I'm biased towards invoking xdoclet, however, which is a > slightly different focus than Brian (I think) so my replies may not be > 100% compatible with yours. > > > Hi Brian! > > > > I don't like the idea of making fatter ejb:plugin > > and putting there a logic which is particular to some application > > server. > > > > IMHO the correct workflow which should be supported by ejb plugin looks > > like follows: > > > > a) gather all the files which will be packaged in ejb-jar in one place > > (equivalent of war:webapp) > > b) archive this directory (equivalent of war:war) > > > > > > Now other plugins like xdoclet/jboss/websphere/whatever > > I'm not seeing any plugins that invoke xdoclet's <ejbdoclet> tag. I really > think it makes sense to have an ejb:ejbdoclet goal in the ejb plugin to > invoke that. > > Why? A couple of reasons: > > 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. 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). I really dislike the desing of ant ejb-jar task. http://cvs.apache.org/viewcvs.cgi/*checkout*/ant/src/main/org/apache/tools/a nt/taskdefs/optional/ejb/EjbJar.java?rev=1.45 The parent tag knows about existence of server specific Tasks. The reason for that is that in ant world tasks have no idea where to search for behavioral properties so they simply inherit them from parent tag. So this is somehow justified. But with Maven we are at least one step further and the design can be cleaner and simply much better (my personal opinion). I don't see any reason why we should mimic wrong design in Maven when we can do a lot better. > b) I suppose we could create a maven-xdoclet-plugin to do the invocation > but, really, <ejbdoclet> is *only* for generating the ejb-related files > so IMO it just makes sense that it would be a part of the ejb plugin. > > > > > Will be able to easily run pre/post goals for steps "a" and "b" and > > decorate them accordingly to their needs > > > > And those plugins can deliver higher level methods like: > > > > jboss:ejb weblogic:ejb > > > > which will create ejb jar for jboss/weblogic and reuse maven-ejb plugin > > In my experience (using only jboss and weblogic) there's not really a > difference in the ejb jar creation process. There *is* a difference in > some of the files contained in there but those are (typically) generated > by xdoclet or hand-coded into src/ejb/foo. > > > > > So basically maven-ejb plugin IMHO should be used as a tag library which > > can be extended/overridden and should not contain container specific > > logic. > > I hope to submit (to jira) my ejb:ejbdoclet goal today. I would appreciate > your thoughts on whehter or not its appropriate for the ejb plugin or, if > not, where it might make sense to be. > > 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. 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 am not using any EJB container at the moment. Not many active Maven developers do. 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
