[El] gdal-java
Viji V Nair
viji at fedoraproject.org
Thu Nov 18 03:03:12 EST 2010
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
>
More information about the el
mailing list