That helps, Jim. I agree that, while in many cases one <javac> is
sufficient for building all Java components (just as one <ejbjar> is
*almost* sufficient for building all EJB components), things get trickier
for deployment. It may be that you simply can't avoid having multiple build
files, but there some things you might try which've worked well for me.
If your deployment directory structure is generally the same among your
various deployments, but only the deployed components change (eg., you
deploy one set of EJBS for configuration A, and another for configuration
B), you might try using one <copy> task along with an "includesfile" that
specifies the components to be deployed. You can then specify this file as
a command-line property. For example:
ant -Ddeploy.includes=configA_includes.txt deploy
where configA_includes.txt contains the patterns that match to the
components that need to be deployed.
Obviously, if your various configurations have different structures, this
probably won't work.
Also, for different Weblogic versions, you could have a target for each.
Each one (in this case, 5.1 and 6.0) could use the "if" attribute and a
judicious choice of properties. For example:
<target name="ejbs51"
depends="classes"
if="ejbc.51">
...
</target>
<target name="ejbs60"
depends="classes"
if="ejbc.60"
...
</target>
<target name="deploy"
depends="ejbs51,ejbs60, ...">
...
</target>
>From the command-line, you would use:
ant -Dejbs.51=true deploy
or
ant -Dejbs.60=true deploy
Or, you could use some other target to set these properties. Actually, you
can get fairly creative with this sort of thing. One limitation is that the
"if" attribute doesn't check the value of the property, only if it's been
set, so it supports somewhat squirrelly behavior, such as setting ejbs.51 to
false,true,foobar,etc., all have the same effect. Also, you could
conceivably run both targets, with unpredictable results.
An alternative would be to deliberately run both targets for both Weblogic
versions, building both types of beans, but then only deploying the
particular set you want.
In practice, I routinely run into situations which at first make me think
I'll need multiple build files, but further investigation always reveals
that to not be true.
Of course, your results may vary. :)
Cheers,
David
-----Original Message-----
From: Jim Jackl-Mochel [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 11, 2001 10:41 AM
To: [EMAIL PROTECTED]
Subject: RE: recursive ant build: recommendation?
Sure,
It boils down to the fact that the single ANT file becomes a
contended resource for almost _all_ package rearrangements, deployment
configuration
changes, other infrastructure changes , etc..
As an example of the last. While putting together the deployment process for
several
different appservers from the same source I ran into the differences between
the weblogic
5.1 and 6.0 ejbc tools (and other deployment tools). Because I couldn't
conditionally
execute different versions of the targets based on the version of the
appserver selected I
had to make a bunch of complex changes to the ANT files for several days
that left the
single ANT file unavailable for normal configuration changes.
We have to keep track of the fact that with component based applications
deployment is just as much
of a part of the process as compilation. What that means to me for now is
that I have to plan on the
build system changing rapidly over time as we add in responsibilities to the
process.
A similar drastic change performed after I had refactored out the targets
into separate
files took a matter of less than a day to test and deploy. At the very least
I would
argue that this demonstrates the desirability of separating the target
definitions from
the main body of the ANT files.
Even with a revision control system that allows simultaneous check out the
problems
are more likely to crop up than otherwise. Changes to the build process or
configuration
are likelier to collide with other changes of like type than any source code
changes.
Does this help explain wheer I am coming from ?
Jim JM
> -----Original Message-----
> From: Ventimiglia, David [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 11, 2001 1:07 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: recursive ant build: recommendation?
>
>
> >I have already seen first hand what happens when a single ANT
> file or even
> a
> >single set of ANT files (all
> >at the top level) are used to handle this kind of interrelated
> projects. It
> >is not pretty, especially when
> >combined with an "exclusive check out" revision control system...
>
> Hi Jim,
>
> Can you elaborate on the problems you've had using a single Ant
> build file?
> Thanks
>
> Cheers,
> David
