[
https://issues.apache.org/jira/browse/MNG-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17642866#comment-17642866
]
Hudson commented on MNG-7612:
-----------------------------
Build succeeded in Jenkins: Maven » Maven TLP » maven » master #145
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/145/
> 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)
