Martin Davis wrote: > Also, when I looked at the GT CT API a while back, it had a dependency > on the Java JAI API - which is a huge payload! We didn't want to tie > ourselves to including JAI. I'm not sure if this is still the case - it > seemed a somewhat unecessary dependency. > > IMO this is an issue with using pieces of GeoTools. It seems like GT > modules tend to be fairly interdependent - which is fair enough from a > GT point of view. But if it's not possible to extract small subsets > containing just the desired functionality, then it imposes a burden on > the project using it which may not be supportable. The issue of API > instability is big too - it doesn't encourage commiting to using GT.
Martin, The same can certainly be said of GDAL ... that using the least of it's services means you have to buy into several megabytes of .so/DLL. Yet this hasn't been a big barrier in the C world. I would encourage accepting GeoTools as a prereq. I will conceed the JAI is an unpleasant requirement. I have been frustrated by this every time I have made a feeble effort to work with GeoTools myself - and get the Java environment setup properly. I think your point about keeping the JUMP API approachable and stable is quite reasonable. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | President OSGeo, http://osgeo.org ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
