Java and ebuilds

[lars_the_bear]

Hi folks

I'm in the process of writing .ebuild files for software that I maintain. In general, I think I'm kind-of on top of this for C/C++, although there are still many things I don't understand.

For Java, though, it's a bit different.

I've been looking at the documentation concerning Java and Portage, but most of it looks a bit old (4-5 years). I was struck by two statements, however:

1. Packagers are encouraged to have the Java built from source

2. There's no built-in support for Maven or Gradle

These two statements seem pretty contradictory to me, since my experience is that Maven and Gradle pretty-much dominate the Java world now. I can't remember the last time I saw anything else used. To be fair, some long-standing projects like Tomcat still use Ant (I think), but they are the exception, rather than the rule. I use Maven; I don't much like it, but that's the way things are going.

So it seems to me that if I want to package my Java applications, I'm faced with this choice:

1. Build from source with Maven, using build scripts and yadda yadda yadda that I write myself. I can do this, so long as there actually is an implementation of Maven that I can specify as a build-time dependency (which I think there is), but it's a bit tedious. Or:

2. Don't build from source at all. Just download the compiled JARs from their repositories, and copy them into sensible places, along with the scripts, etc., needed to run them.

I'm curious about how other people are tackling this problem (if they are). Downloading compiled JARs seems hugely easier to me, and the arguments given for building Java from source don't seem particularly compelling to me.

Comments welcome.

BR, Lars.

[fedeliallalinea]

The problem with new build systems is that, most of the time, they are not well thought out for offline use.
And even if they are you have to either write an ebuild for each dependency (see python packages) or have a long list of dependencies in SRC_URI and have an eclass compile them (see go packages).

There is an eclass written by Sakaki, a brilliant gentoo user who is no longer active, several years ago:

• java-maven-pkg: https://github.com/sakaki-/sakaki-tools/blob/master/eclass/java-maven-pkg.eclass
  
• an example ebuild: https://github.com/sakaki-/sakaki-tools/blob/master/dev-java/jitsi-sctp/jitsi-sctp-20200407.ebuild

_________________
Questions are guaranteed in life; Answers aren't.

[logrusx]

Hello Lars,

[charles17]

[logrusx]

Also look here: https://wiki.gentoo.org/wiki/Project:Java

Best Regards,
Georgi

[lars_the_bear]

[Goverp]

Perhaps think of your bunch of jar files as a Snap. It may lead to duplication, but it does provide a known Java environment for the application.
_________________
Greybeard

[lars_the_bear]

[charles17]

[lars_the_bear]

[charles17]

[lars_the_bear]

[logrusx]

[lars_the_bear]

[logrusx]

I meant not to count on maven to deliver the client whatever is necessary. That's a recipe for disaster. The deliverables should be complete by themselves.

Best Regards,
Georgi

[lars_the_bear]

[Goverp]

Does this imply a need for a shared jar library (if that's not too recursive a concept)? And similar for Rust crates, whatever packages Go uses, etc. sort of /lib/java/foo for each component foo? TeX has a similar problem, and part of the solution is the kpathsea tool which uses config files to search a vast library tree built according to the TeX Directory Standard (TDS). Or does such a shared library for Java already exist, and I just haven't noticed. I guess emerge (or maybe jmerge) would download a binary jar or try to compile from source depending on some config files in /etc/portage.
_________________
Greybeard