[seek-dev] Proposal to repackage the stubs.
kruland at ku.edu
Tue Sep 13 18:11:21 PDT 2005
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:
Then the same for queryleveltwo
writing out 'levelone' and 'leveltwo' is rather combersome. Maybe we
can shorten it to level1, level2
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?
> 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
>> org.ecogrid.ecoinformatics.resultset.util - hand coded utility classes
>> such as: EcogridResultsetParser and EcogridResultsetTransformer.
>> org.ecogrid.ecoinformatics.query - similarly for query.xsd
>> 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
>> 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.
>> Seek-dev mailing list
>> Seek-dev at ecoinformatics.org
More information about the Seek-dev