Hi,
something changed in the Repository interface of GeoTools
that broke the build in the GeoServer validation extension.
In particular, the Repository.getFeatureSources() method
seems to be gone (along quite a bit of others I see).
I understand this was an attempt to be useful for Christian
work
I looked deeper at the problem with ValidationRunnable class and the missing
getFeatureSources method from the repository.
The problem here is that the semantics is not clear to me. There are data
store names, ids, namespaces, workspaces, prefixes and I have no idea what
is what for geotools
Bleck - sorry about the trouble Andrea.
getFeatureSources method from the repository.
The problem here is that the semantics is not clear to me. There are data
store names, ids, namespaces, workspaces, prefixes and I have no idea what
is what for geotools and geoserver.
This seems to a be a
Checking the actual compile error from hudson tells a different story:
/home/tomcat/.hudson/jobs/geoserver-1.7.x/workspace/geoserver_17x/web/src/main/java/org/vfny/geoserver/action/validation/ValidationRunnable.java:[140,43]
cannot find symbol
symbol : method getFeatureSources()
location:
app-schema needs a better way of registering DataAccess instances, which
must collaborate with each other to perform feature chaining. At the
moment, we have an AppSchemaDataAccessRegistry. When we understand the
Repository API, we might use it.
Because feature chaining *requires*
At the moment, we have an AppSchemaDataAccessRegistry. When we understand the
Repository API, we might use it.
Sigh! And if we work together it will meet your needs :-)
Because feature chaining *requires* collaboration between DataAccess
instances in different namespaces, and because