On 17/05/10 18:25, Jody Garnett wrote: > I think you are into proposal territory - ie a modification that would impact > our build process.
I am not so sure. It should have no visible impact whatsoever on the build process. It is more changing the means of delivery of documents required for the build: rather than storing documents we do not govern in svn, we package them in mvn artifacts. The poms that create the artifacts are hiding out in the GeoTools svn tree (not yet checked in), but are not GeoTools modules. The issue is that we do not need to rebuild the schema jars when we build GeoTools. Looking here, I see many, many non-GeoTools dependencies. http://download.osgeo.org/webdav/geotools/ I should reframe my request: can I upload some artifacts required for app-schema testing? (Forget they are schemas.) I do not see why I need a proposal to do something we are already doing: storing third-party jars in our osgeo maven repo. Nothing else changes. In this case, I am the third-party, as self-appointed packager of these schemas. So, if I announced that I had a third-party whizbang-1.3.2.jar that I wanted to use in app-schema testing, would I be allowed to upload it to the osgeo maven repo? I think the process has been fairly informal so far. > Would you be able to migrate the existing schemas? I hope to dump them, except for some hand-made test-only schemas that are specific to app-schema and not published anywhere. > 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 have adopted naming and numbering to match namespaces and versioning respectively. > I would however still like the code (well schemas) in this case to be > somewhere under the control of the the geotools project. The poms used to build them will be checked in under app-schema/app-schema-packages. > 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. I concur. That is my plan. I should commit the poms to GeoTools svn and let you have a look. > 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. I hope to avoid this; you may be able to persuade me if you can detail your concerns. Or have I assuaged them? I do not understand why this affects filter, wfs, wps, etc. I am not proposing to extend this process beyond app-schema at this time. Perhaps if everyone adopts app-schema-resolver we will? But the other modules are different because they have their own (sometimes modified) copies of schemas, and use tools to generate code based on these. I can see how we might modify xmlcodegen and friends to consume schemas in jars, but I am not sure the tools are able to handle schemas as published (*cough* GML 3.2). A wholesale refactoring of these tools is outside the scope of my request. 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
