I see. So what you'd suggest we move a bunch of that stuff in to gt-main.
I have to have a look at which part will still remain. Perhaps too
little to keep in a separate package. Maybe we should still move that
stuff into gt-appschema-resolver but keep the name?
On 12/12/2012 01:56 PM, Andrea Aime wrote:
On Wed, Dec 12, 2012 at 12:47 PM, Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>> wrote:
[INFO] org.geotools:gt-complex:jar:9-SNAPSHOT
[INFO] +- org.geotools:gt-app-schema-resolver:jar:9-SNAPSHOT:compile
[INFO] | +- org.geotools.xsd:gt-xsd-core:jar:9-SNAPSHOT:compile
[INFO] | | +- org.geotools:gt-graph:jar:9-SNAPSHOT:compile
[INFO] | | | \- org.geotools:gt-main:jar:9-SNAPSHOT:compile
[INFO] | | | +- org.geotools:gt-api:jar:9-SNAPSHOT:compile
[INFO] | | | | \-
org.geotools:gt-referencing:jar:9-SNAPSHOT:compile
[INFO] | | | | +- java3d:vecmath:jar:1.3.2:compile
[INFO] | | | | +-
commons-pool:commons-pool:jar:1.5.4:compile
[INFO] | | | | +-
org.geotools:gt-metadata:jar:9-SNAPSHOT:compile
[INFO] | | | | | \-
org.geotools:gt-opengis:jar:9-SNAPSHOT:compile
[INFO] | | | | | \-
net.java.dev.jsr-275:jsr-275:jar:1.0-beta-2:compile
[INFO] | | | | \- jgridshift:jgridshift:jar:1.0:compile
[INFO] | | | +- com.vividsolutions:jts:jar:1.12:compile
[INFO] | | | \- jdom:jdom:jar:1.0:compile
[INFO] | | +- picocontainer:picocontainer:jar:1.2:compile
[INFO] | | | \- xml-apis:xml-apis:jar:1.3.04:compile (version
managed from 1.0.b2)
[INFO] | | +- xerces:xercesImpl:jar:2.7.1:compile
[INFO] | | +- xml-apis:xml-apis-xerces:jar:2.7.1:compile
[INFO] | | +- commons-jxpath:commons-jxpath:jar:1.3:compile
[INFO] | | +-
commons-collections:commons-collections:jar:3.1:compile
[INFO] | | +- org.eclipse.emf:common:jar:2.6.0:compile
[INFO] | | +- org.eclipse.emf:ecore:jar:2.6.1:compile
[INFO] | | \- org.eclipse.xsd:xsd:jar:2.6.0:compile
[INFO] | \- org.apache.xml:xml-commons-resolver:jar:1.2:compile
[INFO] +- xpp3:xpp3_min:jar:1.1.4c:compile
[INFO] +- javax.media:jai_core:jar:1.1.3:compile
[INFO] \- junit:junit:jar:4.4:test
Eh, as I suspected, very tightly married to XML things, which is
something I hope
complex features remain free of.
Don't get me wrong, being able to parse a feature type from a XSD is a
very good feature, but these large set of dependencies should not be
forced
into whoever uses complex features.
Is there a way to cut it so that generic complex feature stuff is on
one side,
and XML and XSD specific support is on the other?
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
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
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
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
