From: "Zack Grossbart" <[EMAIL PROTECTED]> To: "Ant-Dev" <[EMAIL PROTECTED]> Sent: Tuesday, August 28, 2001 9:04 PM Subject: The EJB-JAR task and the SilverStream server. > Hi, > > I was looking at the EJB-JAR task and its sub-tasks, and I had a couple of > questions. Most of the tasks for the application servers concern themselves > with stub generation and the generation of server specific files, but not > with the actual deployment. Since most of these application servers deploy > with a "copy these files to this directory" type of procedure I'm assuming > that these tasks are meant to be used in conjunction with the copy task. Is > this true?
The <ejbjar> task is for putting together jar files suitable for deployment, i.e. with all the required files, both standard and vendor-specific. The task does not do deployment. In my development environment, I have a separate install Ant script which takes these jars anmd puts them in the right place. For production code, it is different and the jars are packaged up as solaris packages for deployment. I don't see that there is an advantage in having this task do everything - better to build the process from multiple smaller process components. > > None of the existing deployers call code outside of Ant, and only the > iPlanet code calls to an external executable. This must means that the code > for generating deployment information and stubs that I would expect to live > with each of the servers has been replicated in Ant. Is this the case? No, not really. The <ejbjar> task normally invokes the vendor's supplied tools to build the final EJB jar. So it is not replication as such. In addition the task adds other value in determining what has changed and what needs to be updated. I know many app server are moving to an "automatic" type of deployment. I have added support for that mode in the <weblogic> element (noejbc attribute). In any case, my personal preference is to run this step in the development phase and discover my errors then rather than during the deployment phase. YMMV. > > I am interested in providing support for deploying EJBs to the SilverStream > application server. The SilverStream deployment is very black box. It > provides an executable that takes a server name, an EJB Jar, and an XML file > that is a set of server specific information called a deployment plan. All > of the stub generation and the copying of files is done behind the scenes > within this executable. This scheme appears to be very different from the > scheme supported by the other application servers. The SilverStream > deployment scheme is more suitable to the Execute task then the deployment > tasks, I think :). OK, I don't know silverstream but if you can't prepare a jar before deployment, if it really behind the scenes, then all you would use <ejbjar> for would be to pull together the EJB jar to feed into the black box. > > Does anybody have any advice about this? Given the required changes to > support client inter-operability in EJB 2.0, does anybody have any ideas how > this deployment scheme will change? Are there any plans to support > deploying other types of J2EE modules (application clients, WARs, EARs, > Connectors)? Currently Ant tasks don't really support deployment (except <copy> :-) ). They produce the components, EJB jars, EARs, WARs, etc) . Conor
