[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: List of consultants focusing on Debian packaging for Java?

Hi Markus,

On 05/12/2020 23:04, Markus Koschany wrote:
> I had to do a quick analysis for OpenRefine to give you a proper answer. In
> short OpenRefine is a complex project with many dependencies. It is most likely
> suitable for Debian main and some work to package it for Debian is required. I
> have attached the list of dependencies found with mvn dependency:resolve and
> mvn dependency:list.

Thank you so much for this very thorough investigation! It is
encouraging, I don't think there are huge blockers and it is an exercise
that should help us improve OpenRefine upstream, by tidying up our

> The initial work will be significant but the reoccurring maintenance is equally
> important. It will be easier when the OpenRefine specific dependencies are only
> updated when OpenRefine moves to a newer version. If the project depends on a
> new dependency, then it must be packaged for Debian as well. Bug reports must
> be handled, for instance when we move to OpenJDK 17 and a build-dependency
> starts to fail to build from source, then something like that needs to be
> addressed even if it is not under the control of the OpenRefine project.
> Should OpenRefine move to another build system like Gradle then this would also
> require additional work or when the project decided to rewrite Java code in
> Kotlin. 
> OpenRefine build-depends on Apache Jena and Butterfly and several other
> artifacts which haven't been packaged for Debian yet.

How important is it that all dependencies are packaged independently?
Butterfly is a framework that has not been maintained for years, and we
are not aware of any other users beyond OpenRefine. We would love to
migrate to something else. We are the de facto maintainers of butterfly
since we use our own fork anyway, so I would argue that it can be
considered an internal library that is not worth exposing to the outside
world. This is true for other dependencies in the
org.openrefine.dependencies namespace. But of course many other
dependencies listed below are actively maintained and used in other

> The server module depends on Jetty 6 which has been removed from Debian. This
> quite ancient version is only available in Debian 8 "Jessie" at the moment. It
> is not supported anymore. Here the project needs to depend on a newer,
> supported Jetty version or at least depending on the current Jetty 9 version
> shouldn't cause any problems.

I have already upgraded to Jetty 9 in a branch, but did not have the
intention to put that in a release soon. It is good to know that it
would be a hurdle for packaging: it is totally possible to bump this up
on our priorities and get that released in the next version.

> The webapp depends on several Javascript files. I believe most of them are
> available in Debian but in in any case I recommend to ship the non-minified
> versions too because otherwise this is a reason for rejecting the package.

Good to know!

> It makes sense to split the whole work into different smaller pieces. I would
> package the main module first and all required build-dependencies and after
> that try to tackle the server and extensions modules but I don't know if that
> is really feasible. I suppose the extensions are important but optional but the
> server probably is not.

Good point - yes it would be possible to run OpenRefine without the
extensions shipped by default, but it would probably be disappointing to

You are correct that the server module is required.

> I am open to discuss more details offlist and I can prepare a quote or an
> estimate. If you or other OpenRefine project members help with packaging,
> mentoring would also be possible. You can also just learn Debian packaging the
> normal way, for example by reading the documentation linked on 
> https://mentors.debian.net/intro-maintainers/ and asking questions on debian-
> mentors or debian-java.

Ok! I would personally love to be able to get involved, but I think it
is pretty clear that it would be pretty risky to start such a big
packaging project on my own with no prior experience. So I'll definitely
follow up offlist.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: