Hi all, This is an RFC copied from a bug (https://bugs.gentoo.org/776007), and I have added a new section because I realized maven local would not be a good destination for system-wide packages.
----- 0. Motivation Java packaging has become more difficult on Gentoo because maven/Gradle, the two main build systems for java, is unsupported. When java packages migrated from their ant builds to maven/Gradle, most of the packages have not been updated since. I know that in Java overlay, the packaging practices in general is to patch the pom.xml files to work with local jars, but it does not work with Gradle and can be difficult when working with large projects. 1. Challenges - maven modules/artifacts do not work well with java-config. They generally have a group, which resolves name collisions, but java-config currently does not have a group variable. - it will be hard to reinvent the wheel. If the solution was to rewrite pom.xml/build.gradle files, it would have to resolve the dependencies correctly with all the version constraints instead of relying on the build system. Currently, for java-config packages can only depend on a specific slot of a library, but some might work with newer versions of their dependencies. - plugins are also hard to create in Gradle. Custom resolution of dependencies or specifying a custom repository is not easy because it involves "internal" API without much documentation. Fedora's XMvn project can be used as a starting point but at the time of writing, XMvn is outdated and missing some implementations for newly added interface methods in Gradle's API. 2. Proposed idea Maven/Gradle both have an offline mode which restricts them from fetching online files. For java libraries, they will be published to the local maven repository, which makes it available for other java programs using maven/gradle that depends on the library. Packages that still use java-pkg-simple.eclass can be kept because they are generally not available in maven, so it is rare for other packages to depend on them. The eclass and java-config should be updated for some packages that depend on other packages that get published to mavenLocal, but this seems like a rare case. Those packages can also just get converted to a maven/project using patches. For applications, the launcher scripts should also be changed to parse local artifacts with POM files. If this were to be implemented, newer (revisions/subslots? Or old slots with -new at the end?) packages would be incompatible with older versions of packages. 3. ERRATA The local maven repository would not be a good fit since it is on a per-user basis (~/.m2). The correct way would be to define a path for installing (such as /usr/share/.m2), and pass that to build tools as a URL (file:///usr/share/.m2). Feel free to reply if you have any questions or improvements. Kaibo Ma
