Hi Ben. I think you are into proposal territory - ie a modification that would impact our build process.
I like the idea of an alternative to storing stuff in svn we have now: - http://svn.osgeo.org/geotools/branches/2.6.x/modules/ogc Would you be able to migrate the existing schemas? While it is amusing to watch these get versioned with the library; it would be nicer if they were under there own namespace with version numbers matching the specification represented. I would however still like the code (well schemas) in this case to be somewhere under the control of the the geotools project. That is if we are publishing to the osgeo repository it would be good to actually be able to point at the code involved and have anyone be able to build from scratch and/or deploy it. Justin had an idea of setting up code outside of the library for maven build plugins; the idea of managing schemas would also fall under this. So yeah write it up as a proposal; and I would like to see a plan for treating the existing filter, wfs, wps, etc in a similar manner. Indeed my concern is that the library is consistent. Jody On 17/05/2010, at 7:03 PM, Ben Caradoc-Davies wrote: > Jody, > > I have 10 jar files containing various suites of application schemas (at this > time mostly GeoSciML 2.0 and dependencies) that I would like to have > available at GeoTools test time. These are as-published schemas, packaged in > an implementation-neutral structure. I'd like to upload them onto the osgeo > maven repo, but I thought I'd better ask first. > > GeoTools unit tests are supposed to use only data available offline; the idea > is that my new app-schema-resolver is smart enough to pick these up off the > classpath if they are present. This is much, much, *much* better than the > current anti-pattern of storing extended families of schemas in GeoTools svn, > and will allow us to readily upgrade our unit tests, and avoid obsolete cruft > in svn. We'll keep the cruft in maven repos, where it belongs. ;-) > > The benefits are: > (1) Dependency management for schemas. > (2) Assurance that schemas are the published version, not locally modified > copies. > > I am not aware of anyone else bundling schemas in maven artifacts in this > manner (other than those shipped with GeoTools, which have often been > modified), so I have used the publishers' host-names-reversed for the > artifacts. I have identified myself as the packager in the poms. Artifact > naming is guided by XML namespaces, to permit coexistence. > > Any objections? > > The pom files for these artifacts record the dependencies between them. Here > is a snippet of the dependency:tree from a module using > org.geosciml:geosciml-2.0:jar:2.0.2-1 in its test phase. > > [INFO] +- org.geosciml:geosciml-2.0:jar:2.0.2-1:test > [INFO] | +- net.opengis.schemas:gml-3.1:jar:3.1.1-1:test > [INFO] | | \- net.opengis.schemas:xlink:jar:1.0.0-1:test > [INFO] | +- net.opengis.schemas:sampling-1.0:jar:1.0.0-1:test > [INFO] | | +- net.opengis.schemas:om-1.0:jar:1.0.0-1:test > [INFO] | | | \- net.opengis.schemas:sensorML-1.0.1:jar:1.0.1-1:test > [INFO] | | | \- net.opengis.schemas:ic-2.0:jar:2.0.0-1:test > [INFO] | | \- net.opengis.schemas:sweCommon-1.0.1:jar:1.0.1-1:test > [INFO] | \- org.geosciml:cgiutilities-1.0:jar:1.0.0-1:test > > The artifacts I wish to upload are: > > cgiutilities-1.0 > geosciml-2.0 > gml-3.1 > ic-2.0 > om-1.0 > sampling-1.0 > sensorML-1.0.1 > sweCommon-1.0.1 > xlink > xml > > I may have more soon, including, GeoSciML 2.1, and GML 3.2 application > schemas when we have them. > > Kind regards, > > -- > Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> > Software Engineering Team Leader > CSIRO Earth Science and Resource Engineering > Australian Resources Research Centre ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
