[jira] [Closed] (MNG-7612) Chained Local Repository

["Slawomir Jaranowski (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MNG-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Slawomir Jaranowski closed MNG-7612.
------------------------------------
    Resolution: Fixed

> Chained Local Repository 
> -------------------------
>
>                 Key: MNG-7612
>                 URL: https://issues.apache.org/jira/browse/MNG-7612
>             Project: Maven
>          Issue Type: New Feature
>          Components: Artifacts and Repositories
>            Reporter: Slawomir Jaranowski
>            Assignee: Slawomir Jaranowski
>            Priority: Major
>             Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> New feature: Chained Local Repository Manager (CLRM).
> This new feature is not something one would use in production, is more targeted to Integration Test isolation.
> User story: ITs usually are run as part of Maven build – lets call it "outer build" – that may build among other things, plugins and some artifacts needed for the ITs. The ITs itself – let's call them "inner build" – should run in isolated environment.
> Problem: the "outer build" is usually affected by user environment (settings.xml, use of MRM, and may use user own local repository unless alternate specified) but also we do not want user MRM to be altered by IT runs. The "inner build" on the other hand, may fail if use same LRM as "outer build", as they are isolated, so they do not use settings.xml from the outer build, may not use MRM and same remote repository IDs, and all these may lead to mysterious "artifact not found" problems. Typically,  outer build may use MRM that defines mirrorOf with ID "my-mrm", while inner would use defaults, where only remote repository is "central": this leads that user LRM gets populated with artifacts available from "my-mrm" remote repository, while inner build would know only about "central" remote repository. Enhanced LRM (default since Maven 3.0) would refuse to serve up these artifacts.
> Solution is CLRM: with CLRM user is able to specify isolated LRM for ITs, while still making artifacts from outer LRM "visible" (discoverable) for the IT build. Inner build uses isolated LRM solely, but for resolution purposes still is able to resolve from outer LRM, where outer build might deployed artifacts, plugins used by IT inner build.
> Technical remark: CLRM defines "head" LRM, and list of LRM as "tail". Almost all methods are delegated toward "head", except for find methods (metadata and artifact), exposing tail LRM contents for artifact resolution. Also, CLRM is *able* to enforce artifact availability (as explained above), but in most cases (at least in IT user story), one would want to inhibit this.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)