My name is Jérôme and I'm currently working on a GSoC project to package differents GIS Softwares and one of goals this summer is working on packaging Java softwares like GeoServer and GeoTools.
I know there is already a GeoServer package, but it's not built in a way that would be accepted on Debian, that is why I want to create proper GeoServer and GeoTools packages.
I don't have a lot of experience developing and building Java applications so what I've found is maybe wrong so feel free to correct me.
I've been looking into GeoTools first since the majority of Java GIS softwares depends on it. From what I can see, GeoTools is composed of many modules(100+) which are all independent jars. After that I've started listing every dependencies that would need packaging or repackaging for the right version or to be compatiable with Maven-Debian-Helper. Since the list is pretty big, I thought I could start by only packaging some modules. That's why I looked into which modules GeoServer needed.
I also tried to manually build only single modules independently. It works, but from what I understand they still get all the dependencies from the main "pom.xml", are they all needed?
It seems GeoServer is still using many modules. So, would it be possible to create a Basic GeoServer with only a small part of the dependencies?
I've been told that JAI could be a problem, but it seems to be packaged in Ubuntu's multiverse and Debian non-free. That would make any packages depending on it non-free, but I don't think this is too much of a problem.
I was also wondering if there could be any other problem with license and redistribution?
These are pretty much all the questions I have for now, I might need your help again in the future as I advance.
I have been looking into a similar dependency audit for GeoTools for the Eclipse Foundation as part of the LocationTech working group. My effort is only going as far as rounding up all the jars needed for the uDig project, but the process is similar.
You will find that the maven pom.xml correctly reflects the dependencies of each module, however some care can be taken to consider “compile” dependencies used in unit testing from “runtime” dependencies as is required by a downstream application such as GeoServer.
Thus far JAI and JAI ImageIO and the vecmath jar are the only odd ducks out - as they a distributed under some kind of oracle binary license similar to how Java is managed. This makes sense as they were originally intended to be extensions to Java
You can cut down the amount you review by only focuses on the the code we release. Both the geoserver and geotools projects maintain a community or “unsupported” section which contains experimental work that has not yet QA and passed IP review. We have this area to foster new talent in a relaxed environment, when these modules are ready (or attract investment to pay for) the IP and QA checks they are included as part of a release.
Other than that you will not have too much luck producing a cut down version of GeoServer. Optional data formats (such as oracle) are already isolated in GeoServer “extensions”. Often these extensions are lightweight containing a but of UI code and a dependency on the GeoTools “plugin” they bring into the system.
My name is Jérôme and I’m currently working on a GSoC project to package
differents GIS Softwares and one of goals this summer is working on
packaging Java softwares like GeoServer and GeoTools.
I know there is already a GeoServer package, but it’s not built in a way
that would be accepted on Debian, that is why I want to create proper
GeoServer and GeoTools packages.
I don’t have a lot of experience developing and building Java
applications so what I’ve found is maybe wrong so feel free to correct me.
I’ve been looking into GeoTools first since the majority of Java GIS
softwares depends on it. From what I can see, GeoTools is composed of
many modules(100+) which are all independent jars. After that I’ve
started listing every dependencies that would need packaging or
repackaging for the right version or to be compatiable with
Maven-Debian-Helper. Since the list is pretty big, I thought I could
start by only packaging some modules. That’s why I looked into which
modules GeoServer needed.
I also tried to manually build only single modules independently. It
works, but from what I understand they still get all the dependencies
from the main “pom.xml”, are they all needed?
It seems GeoServer is still using many modules. So, would it be possible
to create a Basic GeoServer with only a small part of the dependencies?
I’ve been told that JAI could be a problem, but it seems to be packaged
in Ubuntu’s multiverse and Debian non-free. That would make any packages
depending on it non-free, but I don’t think this is too much of a problem.
I was also wondering if there could be any other problem with license
and redistribution?
These are pretty much all the questions I have for now, I might need
your help again in the future as I advance.
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight� - the same software that powers the world’s largest code
search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
have you considered simply repackaging the existing GeoServer binaries? In my view, this will save you a great deal of effort.
I recommend shipping the contents of the basic GeoServer war.zip as the basic GeoServer. There is a great deal of hidden wisdom in the GeoServer release module about which modules are to be included in each release artifact (see the developer guide where it mentions "mvn assembly:attached"). By depending on the binary artifacts, you are recycling this wisdom. Because java bytecode is portable across machine architectures, you still support "all" architectures (and I use that term in the dpkg sense).
As I mentioned before in another forum there are licence and redistribution issues for GeoServer plugins such as Oracle and ArcGIS that contain proprietary third-party JDBC drivers; in my view you can address these by creating separate .deb packages for these for publication through non-free repositories. Some such as MS SQL require manual download by every user.
The presence of JAI is detected at runtime. It is not required to use GeoServer (but desirable for some mapping applications). If JAI is present in some repo and then installed into a JDK, it is a property of the JDK used to run GeoServer, not of GeoServer itself.
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Mineral Resources Flagship
Australian Resources Research Centre
On Tue, Jul 15, 2014 at 10:19 AM, Ben Caradoc-Davies <
Ben.Caradoc-Davies@anonymised.com> wrote:
The presence of JAI is detected at runtime. It is not required to use
GeoServer (but desirable for some mapping applications). If JAI is
present in some repo and then installed into a JDK, it is a property of
the JDK used to run GeoServer, not of GeoServer itself.
Mind, pure java JAI is needed, nothing will run without it, what Ben is
talking about
is the native version of it, that can be used to accelerate some operations,
that one is indeed optional
Cheers
Andrea
--
GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information.
Ing. Andrea Aime @geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
I could simply package the binaries, but my goal is to create a package that could be available on the official repositories and for that the package needs to be built from source.
Do you think this is the good approach? Do you guys think GeoServer/GeoTools need to be on the official repos?
Concerning JAI. The JAI-Core and JAI-ImageIO package already exist, in non-free. From what I've seen in GeoTools' pom.xml some modules require JAI, this would mean that these GeoTools package would have to be put in non-free (I think?) since they depend on a non-free package and so if GeoServer depends on one of these, it would be put in non-free too anyway. That is if I understand correctly the Maven Dependencies, maybe the JAI dep could be ignored by Maven?
Thanks for the answers
On 14-07-15 05:26 AM, Andrea Aime wrote:
On Tue, Jul 15, 2014 at 10:19 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com <mailto:Ben.Caradoc-Davies@anonymised.com>> wrote:
The presence of JAI is detected at runtime. It is not required to use
GeoServer (but desirable for some mapping applications). If JAI is
present in some repo and then installed into a JDK, it is a
property of
the JDK used to run GeoServer, not of GeoServer itself.
Mind, pure java JAI is needed, nothing will run without it, what Ben is talking about
is the native version of it, that can be used to accelerate some operations,
that one is indeed optional
Cheers
Andrea
--
GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information.
Ing. Andrea Aime @geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
Concerning JAI. The JAI-Core and JAI-ImageIO package already exist, in
non-free. From what I've seen in GeoTools' pom.xml some modules require
JAI, this would mean that these GeoTools package would have to be put in
non-free (I think?) since they depend on a non-free package and so if
GeoServer depends on one of these, it would be put in non-free too
anyway. That is if I understand correctly the Maven Dependencies, maybe
the JAI dep could be ignored by Maven?
If the GeoTools package is itself DFSG compliant and only depends on a
non-free package it should go to contrib instead.
Only if the GeoTools package is not DFSG compliant it needs to go to
non-free.
The criteria for the different archive areas are documented in the Debian
Policy section 2.2:
On Mon, Jul 14, 2014 at 02:03:28PM -0400, Jerome Villeneuve Larouche wrote:
My name is Jérôme and I'm currently working on a GSoC project to
package differents GIS Softwares and one of goals this summer is
working on packaging Java softwares like GeoServer and GeoTools.
Thanks for working on this.
I know there is already a GeoServer package, but it's not built in a
way that would be accepted on Debian, that is why I want to create
proper GeoServer and GeoTools packages.
+1
I've been looking into GeoTools first since the majority of Java GIS
softwares depends on it. From what I can see, GeoTools is composed
of many modules(100+) which are all independent jars.
I wonder why you think there is a bunch of jars. When looking at
I can find release tarballs containing Java source code (only a few
jahrs in the test suite).
What I mean is that when you build GeoTools, each modules make his own jar. I suppose the proper way would be to have one big GeoTools source Package that would create all the smaller module's packages. I'll have to look if ignoring the modules I don't need is complicated so I could ignore the unsupported one and build only those I would need for GeoServer for now.
After that
I've started listing every dependencies that would need packaging or
repackaging for the right version or to be compatiable with
Maven-Debian-Helper. Since the list is pretty big, I thought I could
start by only packaging some modules. That's why I looked into which
modules GeoServer needed.
I admit I do not have any experience what might be the best approach to
this but if I were you I would consult the Debian Java list[1] to get
some help. I personally feel not competent to give some reasonable
advise whether modularising the source tarball is the best
straightforward approach to tackle this.
I also tried to manually build only single modules independently. It
works, but from what I understand they still get all the
dependencies from the main "pom.xml", are they all needed?
It seems GeoServer is still using many modules. So, would it be
possible to create a Basic GeoServer with only a small part of the
dependencies?
It might make sense to modularise only the binary packages and build
from the original source tarball.
I've been told that JAI could be a problem, but it seems to be
packaged in Ubuntu's multiverse and Debian non-free. That would make
any packages depending on it non-free, but I don't think this is too
much of a problem.
I was also wondering if there could be any other problem with
license and redistribution?
See my other mail about this.
I'm not sure I completely understand the non-free and DFSG stuff, I'll have to read the policy Bas linked. But I agree that dropping JAI for something newer might be a good idea.
These are pretty much all the questions I have for now, I might need
your help again in the future as I advance.
On 15/07/14 20:18, Jerome Villeneuve Larouche wrote:
I could simply package the binaries, but my goal is to create a package
that could be available on the official repositories and for that the
package needs to be built from source.
Do you think this is the good approach? Do you guys think
GeoServer/GeoTools need to be on the official repos?
This is a compelling argument. I agree that you must build from source.
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Mineral Resources Flagship
Australian Resources Research Centre
