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 [EMAIL PROTECTED] Cortex eBusiness http://www.cortexebusiness.com.au > -----Original Message----- > From: Sylvain Rey [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, 9 January 2001 11:17 > To: [EMAIL PROTECTED] > 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 > >
