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

[Kevin Ruland]

Jing,

Alas, digir didn't have a client target....  I'm very certain we're
going to have some other issues which we might have to address through
filesets or something.

I did run into one very wierd thing lately -- after switching back and
forth between the new build script and the build_digir.xml.  For some
unknown reason, now in the generateWSDLfromGWSDL target, when executing
the generateBinding I now need to have the property binding.protocol set
to http.  I don't see it set in any of the other build files.  Hmmm.....

I'll commit this thing as build_new.xml, and perhaps you can take a stab
at setting up metacat to use it.  If you run into anything significant,
just let me know.

Kevin

Jing Tao wrote:

> 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
>>
>>
>>