> -----Original Message----- > From: Brian Towles [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 31, 2003 5:57 PM > To: Maven Developers List > Subject: RE: EJB plugin modification > > > > On Thu, 2003-07-31 at 03:54, Michal Maczka wrote: > > 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 > > > > 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 > > > > 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. > > Im actually in complete agreement with you that this should be the > proper way to do it. But there are several issues that I see > that prevent it. > > First, there is the Ant ejbjar task itself. > > Re-codeing all off the work done by the Weblogic or Websphere ant > subtasks into a > jelly enviroment would be a royal pain. >
I don't say that ant task(s) shouldn't be used at all What I say is: if ant tasks are used it should be something this like: <ejbjar> (jboss plugin) </jboss> </ejbjar> <ejbjar> (Weblogic plugin) </Weblogic> </ejbjar> etc in place of <ejbjar> (ejb plugin) <jboss/> <weblogic/> <bees/> <jonas/> <jrun/> .... <ejbjar> xxx.jboss=false xxx.jweblogic=false ... xxx.jrun=true which is simply very very bad. > > I really dislike the desing of ant ejb-jar task. > > > http://cvs.apache.org/viewcvs.cgi/*checkout*/ant/src/main/org/apac > he/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. > > Its not only serching for behavioral properties. It does this for > code reuse. > The base level generic jar for all of the ant ejbjar tasks are > the same. Why recode > everything when you can just use what you did before. Base OO design. > > Secondly, reinventing the wheel is a bad thing IMHO. Maven already > uses ant as a basis for the underlying tool, using the tools > provided just > makes sense. The ejbjar task is a known quantity and well proven > in the Ant world. > ditto In addition I strongly believe that layering like: [java] [ant] [maven] [gui] [maven][gui] is better and this is what really can stimulate code reuse and certainly it is not: [ant] [maven] [gui] or [ant] [gui] You can do things programmatically in java with Ant, but Ant was not created for that. But writing Ant task for existing Bean is a matter of seconds. So is writing a jelly tag lib. The same lesson was learnt with XDoclet. XDoclet 1.x was not adopted by any IDE nor never was IDE friendly basically because it was impossible to use it without Ant. AFAIK XDoclet 2 will be free from this defect. I have nothing against Ant (still use it for more complicated builds). I just have an opinion that some things can be done in better way without it. And if we will do them in Java there is 0.0001 % of the chance that they will be reused by Ant and much higher chance that they will be reused by some other tools. [...] Michal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
