Ciao Andrea, please read below.... ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Owner - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy
phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://simboss.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini ------------------------------------------------------- On Thu, Jan 22, 2009 at 8:49 AM, Andrea Aime <aa...@opengeo.org> wrote: > Simone Giannecchini ha scritto: >> Ciao Jody, >> as we are moving the gdal plugin to supported, I was thinking about >> actually reverting the mechanics of the switch. >> >> Right now you build with gdal only if explicitly requested, in the end >> I would like build with gdal by default (even though we might not ask >> people to install the native libs) but still, give users the >> possibility to build without gdal. >> I got to talk to daniele before I can actually come up with a more >> precise proposal. > > Simone, > as far as I know profiles are only able to add to the base > build definition, but cannot subtract. Well, we could define a standard that contains all the plugins and one that keeps out only imageio-ext gdal. The first one could be activate by default. > On the other hand, we have a number of other modules > that have some problematic dependency, that is, ones that > do depend on jars that _we cannot_ redistribute, not just > with some minor annoyance such as a license that requires > advertising. > > As far as I know if the GDAL native libraries are not around, > the gt-gdal related modules compile anyways and just shut > down their tests, right? > Correct. > Adrian, the fact these modules are in the build does not > force you to use them. I mean, consider the SDE module, > it's in supported land, yet it depends on commercial > jars (and thus the usage of dummy jars and whatnot). > I guess you have no use for it, but at the same time it's > not really making any harm, is it? > The GDAL ones have a dependency on the GDAL Java bindings, > but GDAL itself does not have any advertising request > (uses a MIT style license). > > So I guess the trouble was with the imageio-ext jar > that is going to carry around the jai headers and thus > the JAI license. And here we have the advertisement > clause, which I gather is the one bothering one (correct?). > > It seems to me a solution would be to treat that specific > jar just like JAI, that is, declare it > as a "provided" dependency that is then not included > in the shipped package? Simone, would the tiff module still > be usable if people then forget to include the fixed > tiff reader? The quick answer is no, it would need quite some work to achieve that. Moreover, you would also loose the possibility to perform multuithreaded reads which is importanto on large data with server class HW. I'd rather find a way to cope with the advertisement clause for imageio. Simone. > > Cheers > Andrea > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
