Please check the WHATSNEW file that gets shipped with the Ant distribution. You may specify dependency="none" if you don't need to include every class your ejb refers to in the jar file you are trying to create. This will get rid of your warning.
if you need the bcel library you can download it from the jakarta site. http://jakarta.apache.org/builds/jakarta-bcel/release/v5.0/ You need to unzip the file and copy just the bcel.jar to your ANT_HOME/lib directory. There is full documentation for the <ejbjar> task and it mentions how to use the dependency property. good luck +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ All, I found this blurb in the WHATSNEW file in the binary distribution of Ant 1.5.1 I didn't use the "dependency" to add new files but the <ejbjar> task completed and the jar files looks OK. I am yet to do runtime testing of the jar file. * <ejbjar> now allows control over which additional classes and interfaces are added to the generated EJB jars. A new attribute "dependency" can be defined which controls what classes are added. The addition of classes now uses the Jakarta-BCEL library rather than reflection, meaning bean classes are no longer loaded into Ant's JVM. The default dependency analyzer is known as the ancestor analyzer. It provides the same behaviour as the 1.4.1 version of <ejbjar>. If the BCEL library is not present, a warning will be issued stating the ancestor analyzer is not available. In this case <ejbjar> will continue to function but will not add super classes to the jar. harish -----Original Message----- From: Karen Schaper [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 11:36 AM To: Ant Users List Subject: Upgrade to Ant 1.5 I have upgraded to ant1.5 and some parts of my build script are not working I am getting the following error message Unable to load dependency analyzer: org.apache.tools.ant.util.depend.bcel.AncestorAnalyzer Is there a list of what needs to be modified when upgraded to ant 1.5 from ant 1.4? Thanks Karen -----Original Message----- From: Bwana McCall [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 17, 2002 4:22 PM To: Ant Users List Subject: RE: Looking for a Build Philosophy A great thread indeed! I too have been challenged with the CM role at our company and am looking for ideas on improving our existing philosophy. Much of what was said is what we strive to do including: * Nightly Builds (with automated tests + junit/winrunner reports) "Who broke the build??" Usually the topic of conversation if someone failed to properly compile and integrate their code before commiting to the baseline. This, in my opinion, is a must have for any dev shop. * Unit and Integration Testing Processes. (+1 for Continuous integration! I've just read about this and am really interested) This is an area where we are currently lacking and what Im striving to improve. Many of our developers are different backgrounds and use different techniques, so its going to be a challenge to mold them all into something everyone can use. I have "forcing" anything on anyone, and am always open to compromise on improving processes. * Some kind of Source Control Process which will let you know where and why a code change was made. Change Request, Defect/Issue Fix, Project Plan Task, etc. Anything unique identifier that you can link to that source code file. Most tools include this (ClearCase does I know) but most dont. We use CVS and I've had to write custom perl scripts to handle commit templates to feed our bug tracking / project management systems with code change info. This will tie Source Control into Project Management and help those in charge know what's really going on and why. Some may call it "Big Brother"'ish but too much change is the #1 killer of software projects. As was said on this thread, a lot of this is contingent on the size of your project and development team. I come from a heavy QA background (former analyst/tester, now process engineer/CM) and that really helps with maintaining a high level of integrity with processes. Our developers are resistant to change which doesn't make my job any easier, but hey, if it weren't a challenge, where's my motivation? :) --- "Shackelford, John-Mason" <[EMAIL PROTECTED]> wrote: > You might consider using Cruise Control to automate builds. You can set > Cruise Control to build after any check-in occurs and a specified idle time > on the source control has elapsed. It automatically sends emails to the > build manager and offending developer whenever the build is broken. A > servlet also gives a history of builds and check-ins. I found that this tool > radically altered the way developers in my group worked. Since everything we > did had such an obvious public impact right away (we built after any > check-in and 15 minute idle) everyone was very alert to quality. When one of > us broke something it became a game to get the fix in before the next build. > I think CC is especially helpful on large teams (one project we used CC for > had 200 developers) as it makes everyone feel that their work is a vital > part of the overall success of the project and that can only have a positive > impact. > > +1 for continuous integration > > > John-Mason Shackelford > > Software Developer > NCS Pearson - Measurement Services > 2510 North Dodge St. > Iowa City, IA 52245 > 319-354-9200x6214 > [EMAIL PROTECTED] > > > **************************************************************************** > This email may contain confidential material. > If you were not an intended recipient, > Please notify the sender and delete all copies. > We may monitor email to and from our network. > **************************************************************************** > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > ===== Bwana McCall [EMAIL PROTECTED] [EMAIL PROTECTED] | http://bwana.org YIM: bwanadotorg / AIM: bwanadotorg __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com -- 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]> ************************************************************************** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
