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 dependencies. > > 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 projects. > > 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 users. 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. Best, Antonin
signature.asc
Description: OpenPGP digital signature
