Re: [gentoo-dev] [RfC] Supporting Maven/Gradle build systems by installing to a local maven repository

[Henning Sudbrock]

Hi Kaibo,

I'd like to suggest an alternative to using a local Maven repository for
making Portage-built artifacts available to Maven builds.

Maven also makes it possible to use a "Maven extension" for providing
artifacts that do not come from a remote Maven repository. If a Maven
extension provides an implementation of a "WorkspaceReader", Maven will
query that implementation for artifacts before checking any repository
for the artifacts. (An example of such an extension is used by
M2Eclipse, the Maven integration for the Eclipse IDE, which provides
artifacts built from Java projects within Eclipse.)

Using such a Maven extension would provide greater flexibility than a
local Maven repository, because ebuilds could modify artifact resolution
for their Maven builds by configuring the extension. (I believe that
this would be trickier when using a local Maven repository, in
particular with multiple ebuilds running in parallel.)

I don't know what a similar mechanism in Gradle would be, but I'd guess
that Gradle provides similar extension points.

When thinking about Java builds within portage some weeks ago, I
actually wrote a very simple such extension, to see if this approach
actually works (see
https://github.com/hsudbrock/portage-maven-workspace-reader), and it did
work fine. (This extension resolves artifacts that were "registered" by
other ebuilds by putting a file in a specific directory, where the file
contains the location of the artifact on the hard disk - but this is
just a very simple "proof of concept".)

What do you think about this alternative idea?

Best wishes,
Henning

On 15.03.21 14:02, Kaibo Ma wrote:
> Hi all,
> This is an RFC copied from a bug (https://bugs.gentoo.org/776007
> <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