Unfortunately they're all external libraries. Right now I'm just trying to make it build (it uses a new version of gradle...) and am making a list of the libraries one at a time as I find them. Nothing's particularly complex; examples are Phidias (https://github.com/rotty3000/phidias) and jungrapht ( https://github.com/tomnelson/jungrapht-visualization), but there's more.
AFAICT packaging a Maven Java-only library is, or at least should be, almost trivial... On Fri, 24 May 2024 at 18:08, Jérémy Lal <kapo...@melix.org> wrote: > Hi David, > > Le ven. 24 mai 2024 à 17:06, David Given <d...@cowlark.com> a écrit : > >> I'm try to put together a package for a big, complex application. One of >> its dependencies isn't in Debian yet. What do I do? >> >> - package up the dependency and somehow get both packages sponsored at >> the same time (how?); >> - package up the dependency and get it sponsored first... meaning that >> I'll be trying to get a library added which has no users. >> >> Neither option seems great, TBH. What's the recommended thing to do here? >> > > There is a third option: you can bundle the dependency. > It is especially appropriate when it is from the same upstream authors, > when they chose to split their software into parts that fit together, > but that are not actually used elsewhere. > Also, it makes sense when the dependency is a non-released obscure library > that won't ever be used by some other package. > It is not appropriate if that dependency is a mainstream java library that > just happens to be missing from debian. > In that case, options 1/2 are better. > Check Java Team policy, they might have some doc on that matter. > The tools to do that are uscan (check its man page), debian/copyright, > multiple upstream tarballs, components, and you can find plenty of examples > from sources.debian.net. > > >
