[El] gdal-java

[Ralph Apel]

Hi Viji,

very glad to read that. Any gdal package with proper java bindings,
usable from a JPP style maven2, will fit my personal coming project
interests, which are along the chain imageio-ext -> geotools -> udig, as
I said. 

Although I am new in ELGIS, my current personal feeling is that ELGIS
cannot and should not attempt to be self contained. As a kind of
caricature, it should consist in the first place of a (relatively
complex) set of yum .repo files (with prios and excludes and so on, as
well as strongly dynamic maintenance) making up a proven EL-based GIS
platform, and a relatively small repo in the second place, containing
any stuff which can't be satisfied from the broader scope repos. Surely,
one possible reason for such an impossibility of satisfying certain
requirements from broader repos may be based on conflicts, incompatible
forks and so on. In such a case, ELGIS would be forced to provide their
own release of some broader scope package in order to consistently
complete their GIS platform(s).

Cheers
Ralph
 
On Thu, 2010-11-18 at 13:33 +0530, Viji V Nair wrote:
> Hi Ralph
> 
> On Thu, Nov 18, 2010 at 1:23 PM, Ralph Apel <r.apel at r-apel.de> wrote:
> > Hi Viji,
> >
> > my focus is getting a pristine build of imageio-ext-1.1 to work.
> > And my focus is Java packaging (i.e. geotools and udig in this cotext).
> > But: Why are you against rebuilds? Your policy?
> > Sure: no reason not to upgrade to gdal-1.7.3 ...
> 
> I am not against the rebuilds, no policy issues. As I said, since the
> package already exist on the repo it would be easier for us to correct
> the same to use with imageio-ext.
> 
> You can also work on the gdal fedora/epel package if you are
> interested, as a co-maintainer.
> 
> Thanks
> Viji
> 
> >
> > As you can read from the thread
> >
> > - Add a versionless symlink /usr/share/java/gdal.jar --> gdal-1.7.2.jar.
> > This is: enable gdal to be used in JPP-alike settings with
> > "build-classpath" and so on.
> >
> > - There also should be a .pom file for gdal-java, as well as a so called
> > "dependency mapping" (depmap). This is: enable gdal to be used in
> > JPP-alike maven2 build environments.
> >
> > - My proposal for a very simple pom to start with is
> > <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>
> > This text should be installed at at /usr/share/maven2/poms/JPP-gdal.pom
> >
> > - jpackage-utils should be required for gdal-java as
> > 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 of gdal.spec there should be a macro invocation like
> >
> >  %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.
> >
> > - Another macro %update_maven_depmap should be included in %post as well
> > as in %postun of the gdal-java subpackage.
> >
> > When you do this with whatever gdal package, be it from fedora or from
> > elgis, you will probably find that the macro %add_to_maven_depmap
> > creates some conflicts with definitions like
> >
> > %{!?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"]')}
> >
> > After having spent several days working on this issue, I now at least have a solution (but no explanation) for the issue with
> > %add_to_maven_depmap:
> >
> > * Move %add_to_maven_depmap invocation to the end of the %install
> > section.
> > * Avoid using stuff like %{python_sitearch} or %{ruby_sitearch} above in
> > the %files sections, use file lists instead.
> >
> > (That is what rebuilds are good for :-)
> >
> > Now I am turning to focus on an imageio-ext package (Build)Requiring ANY
> > gdal-java.
> >
> > Regards
> > Ralph Apel
> >
> >
> >>
> > 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
> >> >
> >
> > _______________________________________________
> > el mailing list
> > el at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/el
> >