> 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
