Hi Martin, Thanks for clarifying. So I think long term we should upgrade the parts coverageio that are used to supported... given that they are relatively static.
However I think for the short term relaxing our policy about including "private" modules in the build is a compromise for a few reasons: 1. Christian put in a lot of work to get imagemosaic-jdbc to supported and it deserves to be included in the release. 2. My time for releasing 2.5.0 is limited, and I need to get something out quickly. 3. This seems to be relatively common case. There are other supported modules which have dependencies on unsupported modules. So... I plan to proceed as follows: * include imagemosaic-jdbc in the release * mark the coverageio jar as "unsupported" in the final release artifact * remove references to coverageio in the javadocs ... (not sure how hard this one will be) All other modules which depend on unsupported stuff will be kicked out. This includes: * demo/mappane-use * extension/xsd/xsd-wcs -Justin Martin Desruisseaux wrote: > Justin Deoliveira a écrit : >> Doing the 2.5.0 release i ran into a minor issue with the newly added >> imagemosaic-jdbc module. It depends on gt-coverageio which is >> unsupported. So to include it in the release we would have to include >> coverageio... which goes against our plan of excluding unsupported >> modules. > > > The issue depends on which part of coverageio is used exactly: > > * If this is "image metadata", then this part may change. It requires > agreement between different ImageReader potential implementors. > > * If this is "image mosaic", then this part is expected stable now. > > * If this is the abstract "GeographicImageReader" base class, then > I do not expect change in this class neither. > > > Possible approachs: > > * Graduate parts of the "coverageio" module, exclusing among others the > "Image I/O metadata" part. I think that it would be premature to graduate > the whole coverageio in public API, but we may graduate selected parts of > it depending on user need. > > or > > * Apply a small amendment to our policy. Instead of saying "stable module > can not depends on unsupported module", we could said "this module > (gt-coverageio) is not public - it does not appear in the javadoc and > users should not be aware of it, unless they can afford changes in the > API. However whatever a supported module use it or not is implementation > details that users don't need to know." > > > Martin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
