> - the JRE is still required for the gdal libraries Perhaps not? As long as the environmental variables are set correctly (which is what we use the udig.bat or udig.sh script for) the JRE should be able to link in those libraries ...
Indeed to set up a development environment that uses GDAL we depend on developers setting those global environmental variables do we not? Let us quickly ask Daniele on this one :-) Daniele we (well Frank) has been able to package up some of the JAI and ImageIO jars into bundles so they show up on the class path when we are running GeoTools code. Is there a way we can set up the execution environment when we run uDig so that the java executable can see the various gdal native libraries? Right now we copy them into the JRE bin folder. Frank also had a number of questions you may be able to answer: > Now I have several questions before I request a pull for udig-platfrom: > 1. How can I check, whether the native libraries are loaded correctly (API > calls, something like isNativSupportAvailable()) > 2. Where can I find additional data sets to test, whether everything works > correctly with JAI/imageio > I tested with mentioned asc files and tiff files -> everything looks fine > (on mac) but it was not possible to load *.sid and *.ecw files -> Add data > wizard doesn't finish, no exceptions, Any suggestions here? > 3. Could anybody test if I created the pull request the native libs on linux > 32/64 bit, I can test on mac os and win32/64 bit with 32 bit runtime > 4. Is there a wiki page that describes how to setup the JRE with gdal > binaries for native support? > > Frank one of the best resources is the ImageIO-EXT Documentation: - http://java.net/projects/imageio-ext/downloads/directory/Documentation Indeed the README.txt has the following: ======================= ImageI/O-Ext Deployment ======================= 1. Make sure all the imageio-ext jars you need are on the classpath of your application 2. Download the proper GDAL Native libraries (depending on your System) and extract them on your disk. 2a. If you are on Windows, make sure that the GDAL DLL files are on your PATH (by adding an entry to the PATH environment variable referring to the folder where the native libs have been deployed). Note that multiple DLLs versions available on different location on your PATH's machine may cause loading issues. Usually, you can extract DLLs on your JDK/bin folder. When done, you could run "gdalinfo --version" to check the native libs installation. 2b. If you are on Linux, make sure to set the LD_LIBRARY_PATH environment variable to refer to the folder where the SOs have been extracted. (Typical uses are extracting SOs on your java JDK in the /jre/lib/i386 (Linux32) or /jre/lib/amd64 (linux64) subfolders). When done, yo u could "cd" to the folder where they have been extracted and run "./gdalinfo --version" to check the native libs installation. 3. Download the GDAL CRS Definitions zip archive and extract them on your disk. Make sure to set a GDAL_DATA environment variable to the folder where you have extracted the files. Based on that I think we could modify either our udig.at or udig.sh script; or mess around with the ini file (for example the java library path). However a bit of research indicates that we may be able to do this using the normal eclipse mechanism (i.e. allow it to build the library path). I think you are already using this technique? http://stackoverflow.com/questions/957700/how-to-set-the-java-library-path-from-eclipse
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
