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 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. 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. regards Michal > -----Original Message----- > From: Brian Towles [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 31, 2003 7:31 AM > To: Maven Developers List > Cc: [EMAIL PROTECTED] > Subject: Re: EJB plugin modification > > Helps if I attach what I say im going to.. > > On Thu, 2003-07-31 at 00:28, Brian Towles wrote: > > On Wed, 2003-07-30 at 17:56, James CE Johnson wrote: > > > I agree. maven's mode of operation, however, is one artifact per > > > (sub)project. I generally try to work within that philosophy but there > > > are times when it doesn't work for me. For instance, in one subproject > > > we create foo.jar that contains the EJBs; foo.ear that contains > foo.jar > > > and all of its dependencies; foo-client.jar that has only the classes > > > needed by clients of the ejb; foo-mock.jar that contains > > > mockdoclet-generated classes that other subprojects can use in their > > > unit tests. To me, that seems reasonable since all of the artifacts > > > come from the same set of sources and are, in some way, related. > > > > > > > Yeah your right for now im going to leave the ejbjar to be able to do > > what you want it to but supporting a multi-jar install and deploy > > would be a pain. > > > > > > > Ah. Not using ejbc so that's new information. We do use WebLogic > though > > > so I'd really like to see what you've got when you're happy with it. I > > > gather pre-generating the rmi stubs gives you a boost at deployment? > > > Runtime? > > > > I havent used weblogic since the 5.X and early 6.X days, so i cant say > > what the current method of deployment is. Back in 5.X there was not > > autogeneration of stubs on deploy and ejbc had to be run. I would > > assume BEA has made some strides in that. > > > > And since you asked :) > > > > Im actually in a pretty good state. Im using it for jboss projects just > > fine. I need people with different environments to try it out. > > > > Ive attached the patch to 1.0beta10. Im going to wait to submit it > > officially until I can get some more feedback. > > > > You can also just get the modified plugin jar from > > http://www.casadeslug.com/mavenmods/maven-ejb-plugin-1.1-SNAPSHOT.jar > > > > and the modified properties.html docs are here > > http://www.casadeslug.com/mavenmods/docs/properties.html > > > > They look a scary but its not really. > > > > I can only test the JBoss portion of the code out, so if anyone else > > wants to try the other app servers out please do. They should be > > working (not really much to em) but i could have some typos. Any help > > would be appreciated. > > > > > > -=Brian > -- > Brian Towles <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
