> It looks pretty straightforward at a first glance, but I think it
> would require
> other components because you are not providing any information of
> the direct dependencies of the java packages/artifacts, which
> means it might have to consult other sources (probably a remote repo)
> first,
>What do you think about this alternative idea?
It looks pretty straightforward at a first glance, but I think it would
require
other components because you are not providing any information of
the direct dependencies of the java packages/artifacts, which
means it might have to consult other
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
>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.
I don't think this would be a big problem.
For ebuilds, they can just enable offline mode which would restrict
maven/gradle from using remote artifacts.
As
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).
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
