uDig should use the GeoTools catalog instead of it's own - Research needed

Richard Gould added a comment - 18/Jul/06 6:06 PM Possible areas for problems: Geotools catalog is java 1.4 based, so it might quite painful changing uDig code over to this Several class names and method names have changed, but only slightly. Some of the abstract classes in uDig have been split into both an interface and an abstract class. The impact from this should be minimum. Resolve.members class does not mention that the returned List should contain Resolves. Could possibly break some assumptions in uDig. GeoTools catalog lacks equivalents for ICatalog.createTemporaryResource and ICatalog.getTemproraryDescriptorClasses(), but it does provide a "user data" map. Looks like a Javadoc review is needed for GeoTools catalog

Jody Garnett added a comment - 22/Nov/06 2:34 PM GeotoolsAdapters includes wrappers to let you host a GeoTools Service and GeoResource in a uDig catalog ... The method names have been changed to allow our implementation to implement the GeoTools interfaces; there is one conflict over the use of URI (rather then URL) as an identifier. URI has been a problem in the past (on windows boxes) as the Java implementation of file.toURL().toURI() is not valid in may cases (such as a " " in the path name). This is a well understood problem and we should capture a utility method as part of IService (so subclasses can have easy acess to it).

Jody Garnett added a comment - 14/Mar/09 10:36 PM bug brought forward to UDIG1.2.M4 visibility

Jody Garnett added a comment - 04/Apr/10 6:55 AM GeoTools catalog implementation has been withdrawn; GeoServer has created their own using a nice strict api (with both hibernate and xml backends for storage). Due to difference in license we cannot proceed with collaboration in this area and this issue won't be fixed.