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

[Henning Sudbrock]

> 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, and then attempts to resolve to a local JAR from your
 > WorkspaceReader.

Hm, not sure I understand your point. A WorkspaceReader provides the
information about direct dependencies just like a Maven repository does,
i.e., via POM artifacts (just like Maven resolves POM artifacts from a
local/remote Maven repository, Maven would also resolve POM artifacts
via a WorkspaceReader).

 > Have you tested this with --offline and the local maven cache (~/.m2)
 > cleared beforehand to see if your extension can actually work in a
 > sandboxed environment?

I have tested it so far to see that both POM and JAR artifacts are
resolved via the WorkspaceReader (also in combination with the --offline
flag and the local maven cache cleared, yes).

 > It seems that having a local maven repository is the only
 > straightforward
 > and easy solution which doesn't involve much heavy patching of build
 > files or deep understanding of the infrastructure with a large amount
 > of effort in order to maintain the project.

I guess it's also an option to first start with a local maven
repository, and to extend it later - if needed - with a WorkspaceReader
for Maven builds (using a WorkspaceReader to, e.g., configure
ebuild-specifics for artifact resolution, and having the local maven
repository as the default to which Maven would fall back if the
WorkspaceReader does not provide any artifact for given Maven coordinates).

-- Henning Sudbrock


On 23.03.21 06:02, Kaibo Ma wrote:
>  >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 sources (probably a remote repo)
> first, and then attempts to resolve to a local JAR from your
> WorkspaceReader.
>
> Have you tested this with --offline and the local maven cache (~/.m2)
> cleared beforehand to see if your extension can actually work in a
> sandboxed environment? XMvn does make use of this but it does
> more than just this, it generates full POMs which might be very hard
> to tackle.
>
> Another thing is for gradle. It does not expose public API for custom
> repositories. It does have the API for it, but it is not documented and
> it is subject to change. XMvn has a gradle connector, but it is already
> outdated and would only work for older gradle versions. I have tried
> to create a gradle plugin with a custom repository, but the internal API
> was very confusing, and it wasn't clear what I should do.
>
> It seems that having a local maven repository is the only straightforward
> and easy solution which doesn't involve much heavy patching of build
> files or deep understanding of the infrastructure with a large amount of
> effort in order to maintain the project.
>
> Kaibo Ma
>