ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Elliott <>
Subject RE: Ejbjar - support classes and more (updating core classes only )
Date Tue, 09 Jan 2001 18:36:29 GMT

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


Conor MacNeill
Cortex eBusiness

> -----Original Message-----
> From: Sylvain Rey []
> Sent: Tuesday, 9 January 2001 11:17
> To:
> 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

View raw message