Return-Path: Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 11733 invoked from network); 9 Jan 2001 00:39:46 -0000 Received: from cortex-gw.magna.com.au (HELO smtp.cortexebusiness.com.au) (203.174.140.214) by h31.sny.collab.net with SMTP; 9 Jan 2001 00:39:46 -0000 Received: (from daemon@localhost) by smtp.cortexebusiness.com.au (8.10.0/8.10.0) id f090dpF06373 for ; Tue, 9 Jan 2001 11:39:51 +1100 (EST) Received: from UNKNOWN(192.168.1.8), claiming to be "monkey.prod.thespot.com.au" via SMTP by ripley, id smtpdAAAGVaGwm; Tue Jan 9 11:39:17 2001 Received: (from daemon@localhost) by monkey.prod.thespot.com.au (8.10.0/8.10.0) id f090dGI07108 for ; Tue, 9 Jan 2001 11:39:16 +1100 (EST) Received: from UNKNOWN(192.168.1.9), claiming to be "chunky.devl.ebinteractive.com.au" via SMTP by monkey, id smtpdAAAYtaO3n; Tue Jan 9 11:39:07 2001 Received: from snotty (snotty.devl.ebinteractive.com.au [192.168.1.32]) by chunky.devl.ebinteractive.com.au (8.10.0/8.10.0) with SMTP id f090d7B15998 for ; Tue, 9 Jan 2001 11:39:07 +1100 (EST) From: "Conor MacNeill" To: Subject: RE: Ejbjar - support classes and more (updating core classes only) Date: Tue, 9 Jan 2001 11:39:53 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Sylvain, For the weblogic element in ant 1.3 alpha, there is a flag, presently undocumented, called rebuild. If you set this to false, the ejbjar task will go through certain hoops to try and avoid rebuilding things it doesn't need to. When I have more time, I'll see if it matches your criteria below but perhaps you'd like to try the latest code. I plan a major documentation update for ejbjar so this feature will then be documented. Cheers Conor -- Conor MacNeill conor@cortexebusiness.com.au Cortex eBusiness http://www.cortexebusiness.com.au > -----Original Message----- > From: Sylvain Rey [mailto:ramsey@bluedot.com] > Sent: Tuesday, 9 January 2001 11:17 > To: ant-user@jakarta.apache.org > Subject: Ejbjar - support classes and more (updating core classes only) > > > Hi everybody, > > Since the subject of support classes in EJB jars is raised again, I would > like to stress what may be a new point here. > > Maybe it doesn't make any sense, I don't know exactly. Any > feedback would be > greatly appreciated. > > Building a new ejb jar file takes a long time compared to just > compiling the > core classes of the EJB (there is no comparison for me). > Therefore, when changing the core classes of an EJB, I don't call ejbjar > again for an already existing jar. I just compile the updated classes and > update the jar with them (using the "exec" task calling the "jar" > command as > the "jar" task can't update directly). > This work only if you don't change any method signature in your > EJB or don't > add/remove any method, of course. Weblogic would complain with a > marshalling/unmarshalling exception (in the best case). All this seems > logical for me. > > Therefore, my ant script makes a check with an uptodate task, > testing if the > interface classes of my EJBs are newer than the old jar files. If > true, ant > recompiles the all EJB. If not, it just recompile the core classes and > update them in the jar. > > This "algorithm" is quite painfull to put into a build file. For > each EJB, I > have > 1st target: test if jar is older than the compiled classes > 2nd target: if result of 1 is true, test if we can make a "quick > compile" by > testing if jar is older than the interface classes (basically Server and > ServerHome classes for this bean) > 3rd target: if result of 2 is false, make a quick build: just update the > compiled core classes and the support classes also > 4th target: if result of 2 is true, make a full build: call ejbjar task, > then update the new jar with the support classes > > If I hadn't any trouble with support classes and this "quick compile" > feature, the part of the script would be a simple ejbjar call, let's say > about ten lines. In this case, it is more than 50 lines for each bean I'm > building this way. > > My questions: > Does the method I use sounds relevant to you or is there something I'm > missing ? > If it is relevant, would it be valuable to include this quite simple > algorithm into the ejbjar task (somethingg like an "onlyUpdateIfPossible > parameter") ? > > Sylvain > >