[El] gdal-java

[Ralph Apel]

Hi,

ran the same build (of imageio-ext 1.1 r1236) now with
-Dmaven.test.failure.ignore=true for imageio-ext/plugin modules:

Not all of the tests for plugins declared as "internally uses gdal" do
fail:

gdaldoq1 fails
gdaldoq2 fails
gdalhdf4 "succeeds" with "Test file not available" ?
gdalenvisat "succeeds" with "Test file not available"
gdalerdasimg fails
gdalnitf fails
gdalehdr fails #
gdalenvihdr fails #
gdalmrsid skipped with "MrSID Driver is not Available."
gdalecw skipped with "ECW Driver is not Available."
gdalecwjp2 skipped with "JP2ECW Driver is not Available."
gdalmrsidjp2 skipped with "JP2MrSID Driver is not Available."
gdalkakadujp2 skipped with "JP2KAK Driver is not Available."
gdaljpeg fails
gdalarcgrid fails
gdalarcbinarygrid succeeds!
gdaldted fails #
gdalgeotiff fails
gdalwms succeeds!
gdalwcs succeeds!

Will retry with 1.7.3

On Thu, 2010-11-18 at 15:42 +0530, Viji V Nair wrote:
> Sure, just mailed the maintainer, waiting for his response, also
> adding myself as a co-maintainer so that I can update the package as
> well.
> 
> On Thu, Nov 18, 2010 at 3:38 PM, Ralph Apel <r.apel at r-apel.de> wrote:
> > Consider upgrading to 1.7.3 ?
> >
> > -------------------------------------------------------
> >  T E S T S
> > -------------------------------------------------------
> > Running it.geosolutions.imageio.plugins.doq1.DOQ1Test
> > Nov 18, 2010 10:56:11 AM
> > it.geosolutions.imageio.gdalframework.GDALUtilities loadGDAL
> > INFO: GDAL Native Library loaded (version: 1.7.2)
> > Error: One factory fails for the operation "ImageRead"
> > Occurs in: javax.media.jai.ThreadSafeOperationRegistry
> > java.lang.reflect.InvocationTargetException
> >
> >
> > On Thu, 2010-11-18 at 10:10 +0530, Viji V Nair wrote:
> >> Hi,
> >>
> >> gdal is already available on the repo, is there any specific reason
> >> for this rebuild?
> >>
> >> if not, i would suggest we should focus on building new apps rather
> >> than duplicating the same.
> >>
> >> If the current gdal is having any issues please file a bug report or
> >> write to me, will get it fixed.
> >>
> >> I have noticed that java is broken in gdal 1.7.2, it wont build the
> >> jnis properly if libtools is enabled. The same is fixed in 1.7.3 with
> >> lots of another fixes. I am in process of upgrading the same to the
> >> current version.
> >>
> >> Thoughts welcome.....
> >>
> >> Thanks
> >> Viji
> >>
> >>
> >>
> >> On Thu, Nov 18, 2010 at 2:09 AM, Ralph Apel <r.apel at r-apel.de> wrote:
> >> > Hi,
> >> >
> >> > I am now working on gdal-1.7.2-5_3; building it on my local CentOS 5.5,
> >> > as well as on a Fedora 12 and within an unmodified mock cfg i.e.
> >> > https://projects.argeo.org/elgis/svn/factory/trunk/modules/org.argeo.elgis.rpmfactory/files/etc/mock/elgis-5-testing-i386.cfg
> >> >
> >> > I essentially added the JPackage compat bits, in order to be able to
> >> > build a new and better imageio-ext package. I now do have %check active.
> >> >
> >> > Have had some trouble with the JPackage macro %add_to_maven_depmap which
> >> > evidently entered into some cross influence with
> >> >
> >> > %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from
> >> > distutils.sysconfig import get_python_lib; print get_python_lib(1)")}
> >> > %{!?ruby_sitearch: %define ruby_sitearch %(ruby -rrbconfig -e 'puts
> >> > Config::CONFIG["sitearchdir"]')}
> >> >
> >> > sort of "undefining" both. Finally I only have been able to solve the
> >> > problem by shifting the %add_to_maven_depmap to the end of the %install
> >> > section and using files for the %files section of -python and -ruby
> >> >
> >> >
> >> > Hoping to get it done soon and then proceed to with imageio-ext ...
> >> >
> >> > Which is the procedure for uploads?
> >> >
> >> > Cheers
> >> > Ralph
> >> >
> >> > On Mon, 2010-11-15 at 10:31 +0100, Ralph Apel wrote:
> >> >> Hi Mathieu,
> >> >>
> >> >> after rebuilding gdal-1.7.2-5_2.src.rpm on my box (had to disable tests
> >> >> for some reason), there are only some minor details to add, as well as
> >> >> consequences for other packages, i.e. imageio-ext. Here my comments:
> >> >>
> >> >> ========================================================================
> >> >>
> >> >> 1) The file locations for gdal-java are basically OK.
> >> >>
> >> >> 2) But there should be a versionless symlink /usr/share/java/gdal.jar
> >> >> --> gdal-1.7.2.jar (according to JPackage rules as adopted by many
> >> >> distros)
> >> >>
> >> >> 3) Marking gdal-java as architecture dependent (i.e. .i386.rpm, etc.) is
> >> >> OK because the shared libraries contained in this packages do the job
> >> >> and the Java classes are for binding purposes only.
> >> >>
> >> >> 4) But in order to just compile (not run) some reference to the gdal
> >> >> bindings the (arch independent) jar file is sufficient. This is what
> >> >> it.geosolutions do with their imageio-ext: they provide the jar file
> >> >> from gdal-1.7.2 naming it "gdal-bindings" from their point of view.
> >> >>
> >> >> 5) Therefore a new imageio-ext package should drop the
> >> >>
> >> >> $ tar tzf SOURCES/imageio-ext-1.1-SNAPSHOT.tgz | grep jar$ | grep gdal
> >> >> imageio-ext-1.1-SNAPSHOT/deploy/jar/gdal-1.7.2.jar
> >> >>
> >> >> and (Build)Require gdal-java instead.
> >> >>
> >> >> 6) In such a new imageio-ext package there will be no need for
> >> >>
> >> >> $ rpm -ql imageio-ext | grep bindings
> >> >> /usr/share/java/imageio-ext/gdal-bindings-1.7.2.jar
> >> >> /usr/share/java/imageio-ext/gdal-bindings.jar
> >> >> /usr/share/maven2/poms/JPP.imageio-ext-gdal-bindings.pom
> >> >> $ more /usr/share/maven2/poms/JPP.imageio-ext-gdal-bindings.pom
> >> >> <?xml version="1.0" encoding="UTF-8"?>
> >> >> <project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> >> >> http://maven.apache.org/xsd/maven-4.0.0.xsd"
> >> >> xmlns="http://maven.apache.org/POM/4.0.0"
> >> >>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> >> >>   <modelVersion>4.0.0</modelVersion>
> >> >>   <groupId>it.geosolutions.imageio-ext</groupId>
> >> >>   <artifactId>imageio-ext-gdal-bindings</artifactId>
> >> >>   <version>1.7.2</version>
> >> >> </project>
> >> >>
> >> >> 7) Then, there also should be a .pom file for gdal-java, as well as a so
> >> >> called "dependency mapping" (depmap)
> >> >>
> >> >> 8) Regarding the pom file as such, the only reference I have been able
> >> >> to find is
> >> >> http://www.osgeo.org/pipermail/gdal-dev/2007-March/012266.html
> >> >> to no avail.
> >> >>
> >> >> I would propose to start with a very simple one like
> >> >>
> >> >> <project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> >> >> http://maven.apache.org/xsd/maven-4.0.0.xsd"
> >> >> xmlns="http://maven.apache.org/POM/4.0.0"
> >> >>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> >> >>   <modelVersion>4.0.0</modelVersion>
> >> >>   <groupId>org.gdal</groupId>
> >> >>   <artifactId>gdal-java-bindings</artifactId>
> >> >>   <version>1.7.2</version>
> >> >> </project>
> >> >>
> >> >> 9) In the gdal-java subpackage, this pom should be located
> >> >> at /usr/share/maven2/poms/JPP-gdal.pom
> >> >> consistent with the location of the versionless
> >> >> symlink /usr/share/java/gdal.jar
> >> >>
> >> >> 10) If using jpackage-utils like
> >> >>
> >> >> BuildRequires:  jpackage-utils >= 0:1.7.5
> >> >> Requires:  jpackage-utils >= 0:1.7.5
> >> >> Requires(post):    jpackage-utils >= 0:1.7.5
> >> >> Requires(postun):  jpackage-utils >= 0:1.7.5
> >> >>
> >> >> in the %install section there should be a
> >> >>
> >> >> %add_to_maven_depmap org.gdal gdal-java-bindings %{version} JPP %{name}
> >> >>
> >> >> This macro creates a file /etc/maven/fragments/gdal for install,
> >> >> containing a "depmap" like
> >> >>
> >> >> <dependency>
> >> >>     <maven>
> >> >>         <groupId>org.gdal</groupId>
> >> >>         <artifactId>gdal-java-bindings</artifactId>
> >> >>         <version>1.7.2</version>
> >> >>     </maven>
> >> >>     <jpp>
> >> >>         <groupId>JPP</groupId>
> >> >>         <artifactId>gdal</artifactId>
> >> >>         <version>1.7.2</version>
> >> >>     </jpp>
> >> >> </dependency>
> >> >>
> >> >> which will be processed by maven2 from JPP permitting it to find the
> >> >> jar.
> >> >>
> >> >> If another macro
> >> >>
> >> >> %update_maven_depmap
> >> >>
> >> >> is included in %post as well as in %postun (of the gdal-java subpackage,
> >> >> I guess), then the "depmap summaries" in
> >> >>
> >> >> /etc/maven/maven2-depmap.xml
> >> >> /etc/maven/maven2-versionless-depmap.xml
> >> >>
> >> >> will be updated on install/uninstall.
> >> >>
> >> >> ========================================================================
> >> >>
> >> >> I will now test these modifications and prepare a modified imageio-ex
> >> >> package (which does still have some other issues to solve):
> >> >>
> >> >> $ tar tzf SOURCES/imageio-ext-1.1-SNAPSHOT.tgz | grep jar$
> >> >> imageio-ext-1.1-SNAPSHOT/deploy/jar/SwanHeaderSchema.jar
> >> >> imageio-ext-1.1-SNAPSHOT/deploy/jar/ncsa_jhdf.jar
> >> >> imageio-ext-1.1-SNAPSHOT/deploy/jar/jmagick.jar
> >> >> imageio-ext-1.1-SNAPSHOT/deploy/jar/kdu_jni.jar
> >> >> imageio-ext-1.1-SNAPSHOT/deploy/jar/gdal-1.7.2.jar
> >> >> imageio-ext-1.1-SNAPSHOT/plugin/swan/header/SwanHeaderSchema.jar
> >> >>
> >> >> Cheers
> >> >> Ralph
> >> >>
> >> >> >
> >> >>
> >> >> On Thu, 2010-11-11 at 10:11 +0100, Mathieu Baudier wrote:
> >> >> > Hi Ralph,
> >> >> >
> >> >> > while you are looking around the native libraries required for Java
> >> >> > GIS, I would be very interested in your opinion about the gdal-java
> >> >> > package (the version in testing).
> >> >> >
> >> >> > I kind of hacked the gdal spec file so that the JNI libraries are also
> >> >> > produced and installed.
> >> >> > But I'm not so sure that I did it properly and consistently with Java
> >> >> > packaging rules on EL (I had a look at Fedora Java packaging
> >> >> > guidelines, but did not implement all that they recommend).
> >> >> >
> >> >> > Moreover I am not sure whether the (arch independent) Java JAR file
> >> >> > which is produced, is also properly installed for use with other
> >> >> > applications.
> >> >> >
> >> >> > Thanks in advance!
> >> >> >
> >> >> > Mathieu
> >> >>
> >> >> _______________________________________________
> >> >> el mailing list
> >> >> el at lists.osgeo.org
> >> >> http://lists.osgeo.org/mailman/listinfo/el
> >> >
> >> > _______________________________________________
> >> > el mailing list
> >> > el at lists.osgeo.org
> >> > http://lists.osgeo.org/mailman/listinfo/el
> >> >
> >
> >