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 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. 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. > Also properties like: > maven.ejb.support.0.includes > > are not really compatible with other properties used in maven. > Only plugin which uses them which I am aware of is auto-generated xdoclet > plugin > And it uses them because ... it is auto-generated. > I am rather against them. I dont like these either but im having to work within the maven plugin famework. The real limitation is the properties files and no ability to nest. If this was xml there would be no issue. But the flat layout of the properties file kills off a major way to implement repeating items. Xdoclet does it for the same reason not because the plugin is auto-generated I tried to think of other ways. One option was to create and xml file and somehow parse it. (ugly, nasty, more work, and not withing maven framework). Another was to to have tokenized the the variables in the value of the properties. It ends up looking something like this: maven.ejb.dtd.publicIds=-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN,-//JBoss//DTD JBOSS//EN maven.ejb.dtd.locations=${maven.src.dir}/conf/dtd/ejb-jar_2_0.dtd,${maven.src.dir}/conf/dtd/jboss_3_2.dtd (*shutter*) Just not practical or really maintainable to the user. -=Brian -- Brian Towles <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
