Eddie, The short answer is to use the 1.5 alpha since it addresses this specific problem. I understand this causes you some other problems. I'd like to know more about these. At the moment, ejbjar is trying to include all required classes in the jar by determining the classes referenced by the bean classes. This is more than the 1.4.1 version does - it just tries to add the super interfaces and superclasses.
I realize many people work by having minimal beans and incorporating a support class jar. I'm looking for suggestions on what can and should be done here. We could add another option to ejbjar to allow for the following behaviours 1. Include just the bean classes and interfaces 2. Include the super classes / super interfaces (1.4.1 style) 3. Include the referenced classes to generate a "complete" jar (current nightly build behaviour) 4. Generate (or add to) an additional support jar containing the additional classes The <support> tag behavour would be affected by this option. I'm really looking for feedback on what ejbjar should look like in 1.5 and what it should support not just in this area but more generally too. Conor > -----Original Message----- > From: Eddie Bernard [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 27 February 2002 10:23 AM > To: 'Ant Users List' > Subject: RE: Getting Local interfaces into an EJB using <ejbjar> > > > Not trying to pester, but does anyone have any insight or > thoughts on this? > I'm sure *someone* has experienced this same problem before? > > > -----Original Message----- > From: Eddie Bernard [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 25, 2002 4:39 PM > To: '[EMAIL PROTECTED]' > Subject: Getting Local interfaces into an EJB using <ejbjar> > > > Has anyone else encountered this problem? > > I have several EJBs that use local interfaces as prescribed by the J2EE (a > link to the tutorial explanation: > http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts6.html#62983). > > In my build file, I use the following: > > <ejbjar srcdir="${opel.build}" > descriptordir="${opel.build}" > classpath="${opel.classpath}" > naming="ejb-name" > manifest="${opel.home}/MANIFEST.MF" > flatdestdir="true"> > <weblogic destdir="${opel.release}" > keepgeneric="false" > rebuild="false" > wlclasspath="${wls.classpath};${opel.build}" > noEJBC="${opel.noejbc}" > newCMP="false"> > </weblogic> > <dtd publicId="-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans > 2.0//EN" > location="${opel.home}/ejb-jar_2_0.dtd"/> > <include name="**/ejb-jar.xml"/> > <exclude name="**/*weblogic*.xml"/> > </ejbjar> > > With this, it generates the EJBs but does not include the Local interfaces > in the corresponding jar. The only way that I can get this to > work is using > the nested <support> element to include these classes, but since > this target > iterates to create all EJBs it "bloats" every EJB jar with > unnecessary Local > interface classes. > > I'm currently using Ant 1.4.1 and I've tried using Ant 1.5 builds > to do the > same, but 1.5 actually attempts to include extraneous support > classes in the > EJB jar. This, again, is bloating since I create a support > classes jar file > which contains all pertinent support classes any EJB may need to > reference. > > The local interfaces are declared correctly in the deployment descriptors > (both generic and Weblogic-specific). So, my assumption is that the task > should be "smart" enough to include the local interface classes > pertinent to > the EJB jar it's creating during this step. > > Does anybody have any ideas on this? > > > > Cheers! > Eddie > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
