Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 776007 - dev-java/*: Add support for Maven/Gradle build systems
Summary: dev-java/*: Add support for Maven/Gradle build systems
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Java team
URL: https://github.com/gradle/gradle/issu...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-03-14 13:46 UTC by Kaibo Ma
Modified: 2021-03-22 00:17 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kaibo Ma 2021-03-14 13:46:10 UTC
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 those might work with newer versions but with a newer slot.

 - 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 - comments are welcomed

I have an idea that might work for this problem. 

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 must be updated for some packages that depend on other packages that gets 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 accept local artifacts with POM files.

That's it, if this were to be implemented, newer (revisions/subslots? or old slot with -new at the end?) packages would be incompatible with older versions of packages. Any comments/improvements are welcomed.
Comment 1 Emily Rowlands 2021-03-14 16:16:26 UTC
Maven was once built from source, but was removed before the git history starts (in 2015!). chewi@g.o says that it's unlikely that it's going to happen again https://bugs.gentoo.org/175034#c2. A good step would be getting some of the eclasses from java-overlay, but that bug (https://bugs.gentoo.org/175054) has been open for a long time. This entire endeavour would probably be on the scale of slotted lua, but would definitely be worth it in my opinion.

Also, gentoo-dev@l.g.o would probably be the best place to ask for comments on this kind of thing.
Comment 2 Kaibo Ma 2021-03-15 13:05:37 UTC
I have posted to the mailing list with one more point added:

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).
Comment 4 Kaibo Ma 2021-03-21 10:41:24 UTC
After looking at the current packages that uses gradle, it looks like most plugins use a plugin with id 'com.gradle.plugin-publish' to publish to a maven repository. 
This plugin is not open source:
https://github.com/gradle/gradle/issues/15992 says 
"Plugin sources: internal repo", which means most gradle projects would depend upon this non-free plugin that was used to publish other plugins that this project would use. 

This would be a major problem if gentoo were to call gradle for building.
Comment 5 Jonas Stein gentoo-dev 2021-03-22 00:17:44 UTC
Please collect knowledge in the wiki pages and discuss on the mailinglist, IRC and other discussion platforms. The bug tracker is not for discussion or brainstorming.

Please use also
https://wiki.gentoo.org/wiki/Gradle
https://wiki.gentoo.org/wiki/Maven

Closing here, because this is technically no bug report. We can not do anything here.