Gentoo Archives: gentoo-dev

From: Kaibo Ma <kaiboma06@×××××.com>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] [RfC] Supporting Maven/Gradle build systems by installing to a local maven repository
Date: Mon, 15 Mar 2021 13:03:08
Message-Id: CANt-4Eh9QtO_sR-kkUgNGJVznXeZcPaJk5FALjDjyLYPMuNsqg@mail.gmail.com
1 Hi all,
2 This is an RFC copied from a bug (https://bugs.gentoo.org/776007), and I
3 have added a new section because I realized maven local would not be a good
4 destination for system-wide packages.
5
6 -----
7
8 0. Motivation
9
10 Java packaging has become more difficult on Gentoo because maven/Gradle,
11 the two main build systems for java, is unsupported. When java packages
12 migrated from their ant builds to maven/Gradle, most of the packages have
13 not been updated since. I know that in Java overlay, the packaging
14 practices in general is to patch the pom.xml files to work with local jars,
15 but it does not work with Gradle and can be difficult when working with
16 large projects.
17
18 1. Challenges
19
20 - maven modules/artifacts do not work well with java-config. They
21 generally have a group, which resolves name collisions, but java-config
22 currently does not have a group variable.
23
24 - it will be hard to reinvent the wheel. If the solution was to rewrite
25 pom.xml/build.gradle files, it would have to resolve the dependencies
26 correctly with all the version constraints instead of relying on the build
27 system. Currently, for java-config packages can only depend on a specific
28 slot of a library, but some might work with newer versions of their
29 dependencies.
30
31 - plugins are also hard to create in Gradle. Custom resolution of
32 dependencies or specifying a custom repository is not easy because it
33 involves "internal" API without much documentation. Fedora's XMvn project
34 can be used as a starting point but at the time of writing, XMvn is
35 outdated and missing some implementations for newly added interface methods
36 in Gradle's API.
37
38 2. Proposed idea
39
40 Maven/Gradle both have an offline mode which restricts them from fetching
41 online files. For java libraries, they will be published to the local maven
42 repository, which makes it available for other java programs using
43 maven/gradle that depends on the library.
44
45 Packages that still use java-pkg-simple.eclass can be kept because they are
46 generally not available in maven, so it is rare for other packages to
47 depend on them. The eclass and java-config should be updated for some
48 packages that depend on other packages that get published to mavenLocal,
49 but this seems like a rare case. Those packages can also just get converted
50 to a maven/project using patches.
51
52 For applications, the launcher scripts should also be changed to parse
53 local artifacts with POM files.
54 If this were to be implemented, newer (revisions/subslots? Or old slots
55 with -new at the end?) packages would be incompatible with older versions
56 of packages.
57
58 3. ERRATA
59
60 The local maven repository would not be a good fit since it is on a
61 per-user basis (~/.m2). The correct way would be to define a path for
62 installing (such as /usr/share/.m2), and pass that to build tools as a URL
63 (file:///usr/share/.m2).
64
65 Feel free to reply if you have any questions or improvements.
66 Kaibo Ma

Replies