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

[Bing Zhu]

The 'EcogridQueryClient' was modified long ago to handle both
factory and non-factory ecogrid service with following syntax.
  $java [-DFACTORY=no] EcogridQueryClient query local_filename GSH

(This is documented in displaying Usage in the code.)

The default is for factory service. e.g.
   $ java EcogridQueryClient query local_filename GSH

In case for a non-factory service,
    $ java -DFACTORY=no EcogridQueryClient query local_filename GSH

BTW, the ecogrid client package, organized before workshop and targeted to
be released to users has followings.
  EcogridQueryClient
  EcogridAuthClient
  EcogridPutClient
  EcogridRegistryClient

Documents with descriptions of these clients, syntax and examples
for systems within Ecogrid are:
  Ecogrid.readme.txt
  Metacat.readme.txt
  SRB.readme.txt
  DiGIR.readme.txt
  registry.readme.txt
.

These documents are all in Ecogrid cvs place at /seek/projects/ecogrid/docs.


Bing



-----Original Message-----
From: seek-dev-bounces at ecoinformatics.org
[mailto:seek-dev-bounces at ecoinformatics.org]On Behalf Of Kevin Ruland
Sent: Friday, September 09, 2005 6:57 AM
To: Kevin Ruland
Cc: seek-dev at ecoinformatics.org
Subject: Re: [seek-dev] potential unified ant build file for
seek/ecogrid



Jing,

I now have commit privs in ecogrid and have committed this as
build_new.xml.  After it has been verified to generate the proper code,
I suggest we mv it to build.xml and remove the other build files (like
build_digir.xml).

I have set it up to include all the client/*.class files in the stub
jar.  It can be broken out if anybody objects.

Also, I have noticed in the client source directory there are two
different "client" java classes, one including "Factory" in its name, on
one without.  After hacking the kepler code some, I noticed that
EcogridQueryClient is no used -- I suspect it was an older client code.
Rather than keeping dead code in the repository, I suggest it be removed
(Attic'd).

Kevin

Kevin Ruland wrote:

>Jing,
>
>I try to follow this tenet, "Minimize resource requirements of the
>client."  It is very generate but has a couple of implications.
>
>1)  Write client code in a way to minimize external requirements such as
>additional jar files and classes.
>
>2)  Attempt to ease the programmer's burdon for coding and deployment.
>
>#1 implies that we should not require lots of additional things for the
>client code.  This includes such things as the additional client code
>required for Digir (I'm working on this now) and attempt to write code
>which operates with multiple versions of 3rd party jars.
>
>#2 means make the api as easy as possible and try to reduce the jar
>count required for deployment.
>
>Reducing the jar count helps in a few ways.  It makes the software
>easier to use because the client code doesn't need to track multiple
>jars.  It also makes the application faster because the class loader
>doesn't have as many jar files to scan through in order to find a
>particular class.
>
>If can can deliver a single client side jar which contains all the
>required goodies (EcogridFactory*.class) and all the stubs I think that
>would be useful.  I would support having a different seperation based on
>more functional lines:  Query stub classes + Query client class in one
>jar, Registry stub classes + Registry classes in another jar, etc.
>
>As for the webapp having one additional class in a jar file, the overall
>impact of that is rather minimal.  In addition, it is not uncommon for
>the server side code to require the client code anyway (EJB is like
>this, but here it is not, of course.)
>
>Kevin
>
>Jing Tao wrote:
>
>
>
>>Hi, Kevin:
>>
>>The only reason i think, that client class is not in the stub jar is
>>we don't want to put the client class into web app though it wouldn't
>>hurt anything. I am not quite sure which way is better: seperate stub
>>and client jar files, but have two jar files; or merge stub and client
>>into same jar, but client class will go to web apps. At that time, we
>>chose the first option. What is your opinion?
>>
>>Thanks,
>>
>>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 16:51:28 -0500
>>>From: Kevin Ruland <kruland at ku.edu>
>>>To: Jing Tao <tao at nceas.ucsb.edu>
>>>Cc: seek-dev at ecoinformatics.org
>>>Subject: Re: [seek-dev] potential unified ant build file for
>>>seek/ecogrid
>>>
>>>
>>>Jing,
>>>
>>>Couple of things.  I don't seem to have commit privs on
>>>seek/projects/ecogrid so it won't get in there by me.  And I did see
>>>that Digir had a clientJar task and I'm attempting to add that now.
>>>However, after I remove all the yucky digir stuff  from that jar, about
>>>the only thing left will be EcogridFactoryQueryClient.class.  Is there
>>>any reason this file cannot be bundled up with the stubs jar, since
>>>kepler needs to have the stubs too?  It of course won't hurt the web app
>>>at all to have it in there.
>>>
>>>Kevin
>>>
>>>Jing Tao wrote:
>>>
>>>
>>>
>>>>Sure, I will add metacat to it.
>>>>
>>>>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:
>>>>
>>>>
>>>>
>_______________________________________________
>Seek-dev mailing list
>Seek-dev at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev
>
>
_______________________________________________
Seek-dev mailing list
Seek-dev at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev