unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Julien Lepiller <julien@lepiller.eu>
To: Bruno Victal <mirai@makinata.eu>, help-guix <help-guix@gnu.org>
Cc: mirai@makinata.eu, bjoern.hoefling@bjoernhoefling.de
Subject: Re: Guidance for packaging Java programs
Date: Thu, 13 Jul 2023 19:48:59 +0200	[thread overview]
Message-ID: <CC08CF8F-B177-46DE-86A6-D2C75C3E820D@lepiller.eu> (raw)
In-Reply-To: <2c37e0d5-b110-ab8a-8810-7f73ab0ec180@makinata.eu>

Hi Bruno,

I'm glad to see some interest in Java :)

First, Java has its own build systems, somewhat like autotools/cmake/meson etc. In the past, ant was the most popular. It's somewhat similar to Make, as you specify build targets in a build.xml file. This case is well supported and we have a ant-build-system for that.

The first difficulty is that ant is-just like make, so it won't manage dependencies, and even not specify any. In the Java world, they either use the same solution as C, in that they don't care and it's your job to bring in dependencies until the build stops breaking (although it might sound bad, this is the good way of doing things for us), or they ship the binary of their dependencies and force you to use that. This is bad for us, since we want to build everything fsom source. It's just a bit more work, but nothing we can patch or snippet away usually.

Nowadays, ant is loosing "market share" in favor of Maven and Gradle. We have a working though probably too primitive maven-build-system which can build a maven project as long as you provide dependencies and plugins.

They are both also package managers, so they usually specify dependencies, which could be useful for an importer, but they often lack source information and there's a lot of bloat in these files (many unneeded dependencies stay there forever…).

Gradle is similar to Maven but it requires quite a lot of work still. The main issue is that it requires Kotlin, the programming language. Since Guix tries to bootstrap its compilers, we need a bootstrap of Kotlin. I tried to do that and after a lot of pain, managed to cleanly bootstrap a kotlin-1.0. I still need to work on adding more to the chain and get more recent versions, but that's pure crazyness at this point.

BiglyBT doesn't seem to have too mazy dependencies at first glance, maybe a better target, though it still requires some cleanup. Not sure what swt is, but we would need to build it ourselves.

Jing looks like it can use ant, but it also looks like it has a ton of lependencies. You could get lost in a rabbithole packaging that one :)

I've never seen anything like saxon-he sources. It looks like a bunch of zip files that contain java files with no build system. The ant-build-system might be able to build that, though no idea how much dependencies there could be.

I'd also like to get Mindustry at some point, but I don't see that happening any time soon : it uses gradle, and with custom plugins too, which means we can't even cheat and use something other than gradle :/

If you feel like helping, maybe an importer would be a good first step :). You should be able to get info from Maven Central (get the pom files, they are XML files and we have a module somewhere to handle them (guix build maven pom) I think). It should work for maven and gradle packages at least. Mapping maven name to guix names might also be challenging, but we can solve with an upstream-name property.

Here are some more resources if you want to learn more about Guix and Java:

I gave a talk about bootstrapping Maven in 2020:

https://xana.lepiller.eu/guix-days-2020/guix-days-2020-julien-lepiller-bootstrapping-maven-480.mp4

There's also my Kotlin bootstrap chain:

https://framagit.org/tyreunom/guix-android/-/blob/master/android/packages/kotlin.scm

There's also a bootstrap of sbt (Scala Build Tool) from Scala, but Scala is not bootstrapped/able in that repo.

To summarize, the main pain points are: lots of dependencies that can quickly go out of hand, source buildability is not great, as many ship their own versions of their dependencies (we need to snippet pre-built jars away, and find a workaround when the build fails to find them), and bootstrappability, as there can be quite a lot of dependency circles.

HTH, and don't hesitate if you want to learn more!

Le 13 juillet 2023 19:00:07 GMT+02:00, Bruno Victal <mirai@makinata.eu> a écrit :
>Hi all,
>
>I'm interested in seeing BiglyBT (an awesome BitTorrent client) [1],
>jing (a RELAX NG validator) [2], Saxon-HE (a free implementation of
>XSLT 2.0 + 3.0) [3] and Mindustry (an addicting tower-defense
>game) [4] packaged for Guix and I'd like to ask for some guidance
>with this subject.
>
>Though I'm not familiar with the language, this seldomly reveals to
>be a problem if the project uses GNU Autotools, Meson, CMake, etc.
>but I'm completely lost when it comes to Java. It's hard to understand
>what's happening, what are the dependencies, how the whole thing is
>assembled together or if I'm even staring at something supposed to be
>built at all. The lack of importers doesn't help either :(
>
>The impression I get is that overall the Guix Java subsystem/support
>seems to be quite barren which I suspect is in part due to the
>rather arcane build process involved. (the manual doesn't have much
>information on the topic as well)
>
>Does anyone have any insight in what would it take to get the
>aforementioned applications properly packaged in Guix? (i.e. without
>repackaging the binary from upstream)
>I'd also be grateful if someone could point me to a primer on
>“how to go from a (java) source checkout into a built app that can
>be used”.
>
>
>[1]: <https://github.com/BiglySoftware/BiglyBT>
>[2]: <https://github.com/relaxng/jing-trang>
>[3]: <https://github.com/Saxonica/Saxon-HE/>
>[4]: <https://mindustrygame.github.io/>
>


  reply	other threads:[~2023-07-13 18:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-13 17:00 Guidance for packaging Java programs Bruno Victal
2023-07-13 17:48 ` Julien Lepiller [this message]
2023-07-13 19:35   ` Bruno Victal
2023-07-13 20:19     ` Julien Lepiller
2023-07-14  5:32       ` Dr. Arne Babenhauserheide
2023-07-28  2:09   ` Bruno Victal
2023-07-28  5:07     ` Julien Lepiller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CC08CF8F-B177-46DE-86A6-D2C75C3E820D@lepiller.eu \
    --to=julien@lepiller.eu \
    --cc=bjoern.hoefling@bjoernhoefling.de \
    --cc=help-guix@gnu.org \
    --cc=mirai@makinata.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).