Open fabiosimeoni opened 9 years ago
It sounds good, i like the idea to have all grab
and push
methods in a single Glues
but indeed keeping all post-processing methods clustered by source/theme, as we have now.
pushed it, please check it out. any question is welcome here. will close when you give the thumbs up.
I've investigated how to add a loadFeatures
from local GML
file in Commons
. At now, reading GML requires to have access to the featureType
. Considering the need to have atomic grab
/ push
methods, and possible to face ows server unavailability, we should have the capacity to read local GML files vs. the GeoAPI, to reuse for post-processing and pushing. At now it's not possible with Geotk
, but they reported they are working on a GMLFeatureStore
that would be make this possible.
the
dsl
initially implemented ingrade-glue
is now generalised and extracted into standalone client API for java clients,grade-upload
. We need now to further refactor to use it.also, the current distribution of tests across source files hides the overall integration picture. Id' like to move all tests to
Glues
, as per the original design, and maintain separate fils for source-specific post-processing steps invoked directly from the tests inGlues
. These files can go in anaux
package.finally, the use of constants and utils can be more systematic and symmetric across sources. I'm including that too in the refactoring.