Good news! With the help of Simone it appears that the coverageio dependency is actually not needed. So simply removing it does the trick nicely.
Justin Deoliveira wrote: > 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
