Fair enough.
(The dependencies of gt-complex and gt-app-schema-resolver are pretty
much the same, and the resolver contains only one package, and they both
provide support for app-schema but can also be used for other things -
that is why I thought it would be convenient.)
I will make the
Niels,
I favour option 3 (new module gt-complex) because it does different
things to gt-app-schema-resolver, which builds no features or types, has
no dependency on gt-app-schema, and concerns itself with finding and
caching XSD documents and making them available to the gt-xsd-core
I am working on this proposal:
http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema
The idea is to split app-schema stuff (as discussed earlier) in to
general complex feature stuff and specific app-schema stuff
But I need to decide on a final
On Fri, Dec 7, 2012 at 7:24 AM, Niels Charlier ni...@scitus.be wrote:
I am working on this proposal:
http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema
The idea is to split app-schema stuff (as discussed earlier) in to general
complex
Is merging into main and also merging gt-app-schema-resolver into main
an option? Does the resolver add any new dependencies?
My preference would be main (1) since that is where all the other
feature stuff lives, but if including the app-schema resolver stuff
there adds overhead or is too
Ah right. Ok thanks Niels. That is indeed a no-go. So i vote for (4) as
well.
On Fri, Dec 7, 2012 at 7:56 AM, Niels Charlier ni...@scitus.be wrote:
Is merging into main and also merging gt-app-schema-resolver into main an
option? Does the resolver add any new dependencies?
My preference
On Fri, Dec 7, 2012 at 3:58 PM, Justin Deoliveira jdeol...@opengeo.orgwrote:
Ah right. Ok thanks Niels. That is indeed a no-go. So i vote for (4) as
well.
Agreed, +1 con option (4)
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
