Right... i guess it would help to know what the classpath overhead is in terms of additional dependencies, etc... of the internal store is. As far as i can see it looks to be pretty minimal, no additional libs and just a handful of classes.@Niels: do I have that right?
Yes, i only depends on what core and api depends.
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.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?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 <tel:%2B39%200584%20962313> fax: +39 0584 1660272 <tel:%2B39%200584%201660272> mob: +39 339 8844549 <tel:%2B39%20%C2%A0339%208844549> http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial.
------------------------------------------------------------------------------ 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
