[seek-dev] potential unified ant build file for seek/ecogrid

[Kevin Ruland]

Jing et al,

The build system in seek/projects/ecogrid is rather messy.  It has way
too many build.xml files to make it easy to determine what is required
to build the system.  I noticed that many of the build*.xml file share
quite a bit of common -- targets, properties, etc.  In order to bring
some order to this, I tried to create what I think can be a unified
build for the different services.  One only needs to set a property to
control which service is to be built.

In order to construct this build.xml file, I started with my
hacked-to-work build_digir.xml and attempted to abstract some of its
crazyness.  I did not spend any time looking at buildsrb.xml
build_reg.xml, build_lsid.xml or build.xml.  I might have missed
something critical in those files.  Hopefully, this setup will prove
adequate for all the services -- perhaps with some additional tweaking.

The attached build.xml file requires a simple build.properties file
which contains three required properties:

ogsa.root=/opt/globus
tomcat.root=/opt/jakarta-tomcat-4.1.31
target=digir

The first two are pretty obvious because they point to the base
directory of installed packages.  The 'target' property should determine
which service to construct.  I have only set it up for 'digir' right now.

In the build.xml file are two places where service specific
configuration can occur.

The target setProperties defers to service specific targets to set
properties for each service.  These targets are supposed to only set
properties to control the remainder of the build process.  setProperties
is a dependency for compileServer and compileStubs.

The target copyWebappJars defers to service specific targets.  This
target is envoked after constructing the server jar and stub jar but
before constructing the gar file.  The intention is to copy into the
${build.lib} directory any supplemental jars required by the webapp for
deployment.  The digir service required commons-httpclient jar file
which is contained in the globus build system but is not installed in
tomcat by globus.  I've used this target to copy the globus'
commons-httpclient jar file into ${build.lib} prior to gar-ring.

I made a fairly significant change by renaming the gar file produced
from
'org.ecoinformatics.ecogrid.EcoGridQueryInterfaceLevelOne.DigirImpl.gar'
to the much shorter 'DigirImpl.gar'.  The reason for this is when globus
constructs the undeployment descriptor it names it based on the part of
the filename before the first '.'.  Since for all the services this
produces an undeployment named 'org-undeploy.wsdd' this can cause
troubles if one intends to deploy multiple services on the same host. 
With the shorter name, globus constructs the descriptor named
'DigirImpl-undeploy.wsdd'.  This also means that the build.xml file
knows what the gar.id is when envoking the undeploy target in
build-services.xml.

What do you think of this?

Kevin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_new.xml
Type: text/xml
Size: 10291 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-dev/attachments/20050908/9f0c9bd0/build_new.xml