[seek-dev] Proposal to repackage the stubs.

[Kevin Ruland]

Jing,

A plan for level two?  I wasn't thinking that far a head, but you're
right we should do so now.  I'll look over those wsdls and see what they
have to say.

I thought of the query.xsd and resultset.xsd as standing alone.  But if
they are only needed within the context of the Query Service, then I
think putting them in the query package is a good idea.

Maybe we need:

o.e.e.querylevelone.stubs
o.e.e.querylevelone.resultset
o.e.e.querylevelone.query

Then the same for queryleveltwo

writing out 'levelone' and 'leveltwo' is rather combersome.  Maybe we
can shorten it to level1, level2

Kevin

Jing Tao wrote:

> Hi, Kevin:
>
> The plan looks good. The only thing I am thinking is why resutset and
> query package is not of queryservice package? Actually those class
> serve for query service. In your plan the package should be:
> o.e.e.resultset, o.e.e.query and  o.e.e.queryservice. Can we do this
> way: o.e.e.queryservice.resultset and o.e.e.queryservice.query?
>
> And now we only implement query service level one, what is your plan
> for level two?
>
> Thanks,
>
> Jing
>
> Jing Tao
> National Center for Ecological
> Analysis and Synthesis (NCEAS)
> 735 State St. Suite 204
> Santa Barbara, CA 93101
>
> On Tue, 13 Sep 2005, Kevin Ruland wrote:
>
>> Date: Tue, 13 Sep 2005 16:52:38 -0500
>> From: Kevin Ruland <kruland at ku.edu>
>> To: seek-dev at ecoinformatics.org
>> Subject: [seek-dev] Proposal to repackage the stubs.
>>
>> Hi all,
>>
>> I would like to propose repackaging the stub and assorted client classes
>> in order to facilitate easier building and developer understanding of
>> the code.
>>
>> Currently, in the package org.ecogrid.ecoinformatics there are 29
>> different java files.  These files are a mixture of axis generated stubs
>> from xsds, hand coded utility classes, and client classes.  Then in
>> o.e.e.stubs there are stubs for at least 3 different wsdls.
>>
>> I suggest we partition these classes into more useful packages along
>> these lines:
>>
>> org.ecogrid.ecoinformatics.resultset - parent package for all stuff
>> related to the resultset.xsd
>> org.ecogrid.ecoinformatics.resultset.stubs - generated classes from
>> resultset.xsd
>> org.ecogrid.ecoinformatics.resultset.util - hand coded utility classes
>> such as: EcogridResultsetParser and EcogridResultsetTransformer.
>>
>> org.ecogrid.ecoinformatics.query - similarly for query.xsd
>> o.e.e.q.stubs
>> o.e.e.q.util
>>
>> org.ecogrid.ecoinformatics.queryservice - parent package for
>> EcoGridQueryInterfaceLevel*.gwsdl generated things.
>> o.e.e.queryservice.bindings - generated code
>> o.e.e.queryservice.service - generated code
>> o.e.e.queryservice.client - hand coded client code
>> EcogridFactoryQueryClient
>>
>> org.ecogrid.ecoinformatics.putservice - for EcoGridPutInterfaceLevel*
>>
>> org.ecogrid.ecoinformatics.authservice - for EcoGridAuthInterfaceLevel*
>>
>> I would not be adverse to having all the wsdl generated code in a single
>> package (rather than have bindings & service sub packages).  Also, the
>> o.e.e.resultset.util code could be put in o.e.e.resultset directly.
>>
>> These changes would make both the build easier to maintain and the
>> overall code base easier to understand.
>>
>> Kevin
>>
>>
>> _______________________________________________
>> Seek-dev mailing list
>> Seek-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev
>>
>>