On Wed, Jun 4, 2008 at 1:07 PM, johann sorel <[EMAIL PROTECTED]> wrote: > Hello, > > > We would like to start a discussion around JNI. >
we == who? > As you have seen in the past months some work has be done on GDAL. > This work is great and can be useful to handle more raster formats, but > the problem is that GeoTools is getting tightly linked to those JNI > classes. What do you mean by tightly coupled? The dependencies on the GDAL modules will be needed only if you want to use GDAL, otherwise the dependencies will be ignored. If this does not happen I would consider it a problem/bug and we (we means GeoSolutions associates) will fix it. We have slightly refactored the geotools plugin and it does not complain anymore if the native libs are not installed. I would recommend you check the GDAL module yourself and then you report any problems you encounter, this would help a lot. As of the definition of problems, that is a personal opinion of yours not an absolute statement. JNI can be problematic but I don't consider it a problem. > > It seem's that the approach choosed here to bind this work to GeoTools > could introduce some problems in the future and it could be really > useful to avoid tight dependency on it > > - unnecessary jars for those who don't need the GDAL plugins. Not true or at least strange thought. The work is done as a plugin hence if you do not need you don't have to use it. As of the download of the needed jars, this is how GeoTools work. Do you have an option to download epsg-hsql instead of epsg-wkt? I don't think so. We might want to split geotools and separate the downloads of the plugins; if that is what you are trying to say, you can make a proposal for that since I think it is a reasonbale request. > - community work outside org.geotools package namespace > - community work on external svn Are we going to drop all the external dependencies like jai, imageio, commons, jts and so on and develop everything inside geotools from scratch? Could you please elaborate a little bit on this since it looks a bit odd as a statement. The GeoTools GDAL plugins are using geotools package names not geosolutions (did you check the code before writing this email?) > - additional barrier for GeoTools community to work on those modules > Actually the GDAL bindings are something people have been wanting for years! Which barriers are you talking about? Which modules people should have problems to work on? Please clarify so that we can try and remove those barriers. > > We ring the bell today because we have found that the render module has > a dependency on an unsupported module which uses this JNI work The renderer depends, as I already told you on IRC, on a PURE JAVA reader for asciigrid data and DOES NOT depend on any JNI call. I agree that depending on a snapshot release is bad but this is used only for testing float data. I am keen to accept suggestions on how to improve this situation. > We feel concerned because render is in the library module, which means > it is official and supported. > Besides, using JNI reduce geotools portability which is > the main purpose and the main reason why we use Java. As I already said, JNI is used through format plugins, hence it is not part of the core geotools. Btw, GDAL can be built ANYWHERE, I have personally built it on a an N800!! For the moment we only ship the JNI bindings for linux and windows, we are working against the mac. Anyway, this would not limit the portability of geotools simply because the plugins won't be available on platform where the JNI libs are not available. > > How can we solve this ? > > Probably in moving JNI related classes outside GeoTools and keep it in > it's native project ImageIO-Ext on java.net. > After all it is an extension that as be clearly envisioned as an > independent project, so it should not be part of geotools trunk. >From your words I understand that you have not carefully looked at the gdal bindings. There is no JNI code in geotools, the JNI code is in imageio-ext. GeoTools has only wrappers that calls the imageio-ext ImageReaders when the JNI libs are deployed. If this are not deployed the geotools plugins should not be available even if installed. If this behavior is not respected this is bug and we (again GeoSoutions team) will fix it. As a side note, JAI and ImageIO from sun comes with native libs, same apply to hdf. Netcdf has its own libs. How is this different from the support for GDAL? > Renderer should be designed in such a way that external projects > should be able to plugin extensions by overriding carefully designed > methods. > > > We raise this issue because we are working as you know on a new Java2D > renderer. > This one depends on the render module but not on imageio-ext. We believe > there is a need to create > a render module independent so that multiple renderers may use it. > I fully agree with your last statements, but I think you need to check a bit better your (your referring to your "we") information about GDAL support since it shows some misconceptions and misunderstandings. As I said our goal is to make dependencies as transparent as possible for people and we are keen to improve things if problems arise. However I usually do not take actions as consequences of personal opinions or misconceptions. Regards, Simone. > > Regards > > -- > Johann Sorel > > Company - Geomatys GIS Developer > Mail - [EMAIL PROTECTED] > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- ------------------------------------------------------- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it ------------------------------------------------------- ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
