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

Kevin Ruland kruland at ku.edu
Fri Sep 9 06:57:11 PDT 2005


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


More information about the Seek-dev mailing list