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

[Jing Tao]

Hi, Kevin:

It is good idea to clean up build.xml in ecogrid. It is in my list for a 
long time, but haven't done yet :(

The reason there are so many build files is: I developed build.xml 
for Metacat, but if we want use it to build other service such as digir or 
srb we need to changed lots of properties in build.xml. And the those 
propertis are very fix for each ecogrid service, so person just copied the 
original file and modified some properties and check it into cvs for next 
usage.

I took a look at build file and it looks good. However, I didn't found 
client target. I guess it is convenient to have client target for developer to test.

Thanks for the effort.

Jing

Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101

On Thu, 8 Sep 2005, Kevin Ruland wrote:

> Date: Thu, 08 Sep 2005 13:46:01 -0500
> From: Kevin Ruland <kruland at ku.edu>
> To: seek-dev at ecoinformatics.org
> Subject: [seek-dev] potential unified ant build file for seek/ecogrid
> 
> 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
>
>
>