[gdal-dev] gdal jar in maven central

[Justin Deoliveira]

On Tue, Mar 31, 2015 at 8:58 AM, Even Rouault <even.rouault at spatialys.com>
wrote:

> Le mardi 31 mars 2015 16:43:06, Justin Deoliveira a écrit :
> > Hey Even,
> >
> > On Tue, Mar 31, 2015 at 8:25 AM, Even Rouault <
> even.rouault at spatialys.com>
> >
> > wrote:
> > > Justin,
> > >
> > > > I searched the archives and couldn't find much on this topic. I was
> > > > wondering how people would feel about having the gdal java jar hosted
> > > > in the central maven repository? I think it would be pretty nice for
> > > > users
> > >
> > > to
> > >
> > > > not have to build the bindings locally, or find a repository that has
> > >
> > > them.
> > >
> > > > Any thoughts, objections, or concerns?
> > >
> > > That should likely be useful, but pardon the naive remark as I'm not
> > > familiar
> > > with how maven central works : the gdal.jar alone will not be usefull.
> > > You need the 4 libgdalXXXXjni.so / dll for it to be usefull, and of
> > > course thy are
> > > architecture dependant, so I'm wondering how that would be handled.
> >
> > Right. The jar won't be of much use unless you have all the native
> > libraries installed on the system. While maven does allow you to store
> > other artifacts in a repository I don't think that is a good fit in this
> > case. As you mention it's very platform dependant and it's pretty common
> > for users to compile gdal themselves to get the formats they need.
> >
> > That said the jar itself would allow applications to at least compile.
> > Without the native libs any actual usage will of course fail. But most
> > projects I have seen that utilize the java bindings account for this
> case,
> > allow things like tests to fail cleanly, or disabling certain
> functionality
> > if the bindings are not active.
> >
> > Long story short I think this would be of most use to developers writing
> > libraries that utilize the bindings. It would allow users of those
> > libraries to build it without any extra steps. At least that is my case.
>
> That's a valid use case I think. Although I guess some word of caution
> written
> in big letters will be necessary to make users aware that the gdal.jar is
> far
> from being self sufficient.
>

Right. The bindings already display a pretty visible warning when any of
libgdalXXXXjni.so (or anything it depends on) fail to load. Which I think
makes it fairly clear.

>
> Regarding the libgdalXXXXjni.so, they don't depend on the third-party libs
> against which GDAL is compiled (well... in theory, as I can see that we do
> over-link in practice, in the Unix makefiles, but that could/should be
> corrected). So if a repository would manage different architectures, they
> could
> be delivered independantly of libgdal itself.
>

Yeah, I've found that the libgdalXXXXjni.so work fairly well in isolation.
What I've done in the past is compile the java binding so/dylib/dll's and
post them for download. And found it usually works fine if the user already
has a "relatively close" version of libgdal installed.


> >
> > > > If people are into the idea I would be happy to put in the work to
> make
> > >
> > > it
> > >
> > > > happen.
>
> Does that require adding/changing stuff in the GDAL repo itself or just
> uploading a built gdal.jar ? How does Maven Central "authenticate" who is
> allowed to upload what / how does the GDAL project gets control on that ?
>
>
Right, there are a few steps involved. The easiest vector that I have seen
for open source projects  is to utilize the Sonatype OSSRH repositories
(which provide sync to maven central). The full process is described here.

  http://central.sonatype.org/pages/ossrh-guide.html#review-requirements

To sum it up though, here is what I think would be required for gdal.

1. Create a pom for the gdal jar that adheres to these requirements:


http://central.sonatype.org/pages/requirements.html#sufficient-metadata

2. Have a developer set up an OSSRH account and do the initial setup.

     http://central.sonatype.org/pages/ossrh-guide.html#initial-setup

3. For each release build the gdal jar (along with it's source and javadoc
artifacts) and GPG sign them.


http://central.sonatype.org/pages/requirements.html#sign-files-with-gpgpgp

   Then deploy all the jars/signatures to the OSSRH staging repositories.
This will eventually sync them to maven central.


Again I'm happy to volunteer to do these steps if there aren't any
developers on the project that want the extra hassle. Do the java bindings
have a dedicated maintainer at this point?


> >
> > > Regards,
> > >
> > > Even
> > >
> > > --
> > > Spatialys - Geospatial professional services
> > > http://www.spatialys.com
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150331/638d67be/attachment.html>