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 |