On 15.03.21 14:02, Kaibo Ma wrote:
> 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).

Correct, the user-local maven repository is not suitable.

I have been thinking about how to support "modern" Java-ish applications
for a long time. One requirement is a system-wide maven repository. But
you also need support from the build system, e.g. Gradle or Maven:


1. We need to be able to tell the build system that it should only
lookup artifacts from a particular repository, the system wide one. For
example

gradle --exlusive-maven-repository "${SYSTEM_WIDE_MAVEN_REPO}"

2. We need to be able to tell the build system to install it's artifacts
in a particular local repository, nowhere else. For example

gradle publishToMavenLocal --into <directory>


Given a Maven repositories structure, especially considering a Maven
repositories metadata, I believe this needs some effort if <directory>
is somewhere under ${D}. But nothing that is impossible to solve.

And, I think it is clear that this *requires* support from the build
systems. That is, any approach that is based on patching build system
configuration to achieve similar results in fragile and hence not
sustainable.

I think it would be beneficial to team-up with other distrbutions. Even
non source-based ones, like Debian, would benefit from an established
and standardized system-wide Maven repository.

But in summary, this is not a trivial task and it requires cooperation
from and coordination with from the build systems. But if we want to
continue packaging source-based Java-ish applications, that are not
simply fat Jars, then we would need something like this. Hence I'd
really like to see it one day.

- Florian


Reply via email to