On Thu, Dec 6, 2012 at 4:09 PM, Justin Deoliveira <[email protected]>wrote:
> Second option, the one you propose. Similar to the above, wit the extra
>> baggage in the classpath
>>
>> Third option, do as one (all stores out by default), but put in the
>> extension package all implementations
>> and create a "composite" store and make thing configurable by the admin:
>> a GUI allows to list the implementations and choose which to enable and
>> which leave dormant,
>> this one might have both the internal store and some external ones too.
>>
>> So a single module containing all backend implementations? Not sure how i
> feel about that once other implementations start pilling up that could
> potentially add overhead in terms of dependencies, etc... The composite
> idea makes sense though but should be orthogonal to 1 module vs many
> modules. If i understand it correctly.
>
No indeed in this approach I would leave each store in its own jar, but all
the store jars would end up in the
extension zip file.
Best of both worlds, no extras for custom implementations and everything
(but configurable) for the regular user.
Comes at a price though, the composite store needs to be written.
I might have some time to work on it next year, but not sure exactly when
>
>>> Also there is a test dependency from the core module on the simple
>>> module for testing purposes. I think it probably makes sense to refactor
>>> all the test cases that currently use the simple store into a set
>>> of abstract classes that remain in core. And then simple and default would
>>> both implement all the test cases to get the same coverage. More or less
>>> how we do jdbc datastore testing in GeoTools.
>>>
>>
>> Hmm... don't think this is going to fly, the CSW tests are assuming the
>> CITE test data is available, but
>> one can have it only if you have around a store allowing to choose the
>> input data (the internal one
>> is locked onto the layers instead).
>>
>
> I see. Well what if we built the catalog purely around the CSW cite data,
> similar to how we setup the cite data for testing the other services. Or
> does the cite test data contain more than just "layers" that need to be
> returned?
>
They do contain several types of information and not sure everything can
be mapped to them using
only the internal store.
Have a look here:
https://github.com/geoserver/geoserver/tree/master/src/community/csw/csw-simple-store/src/test/resources/org/geoserver/csw/store/simple
These records have to be produced verbatim for the CITE tests, and the
tests in csw-core have
several expectations on them too (thought not as strict as the CITE tests
themselves)
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
