[
https://issues.apache.org/jira/browse/MNG-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17642188#comment-17642188
]
ASF GitHub Bot commented on MNG-7612:
-------------------------------------
slawekjaranowski opened a new pull request, #890:
URL: https://github.com/apache/maven/pull/890
Adds new feature: Chained Local Repository Manager.
---
https://issues.apache.org/jira/browse/MNG-7612
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MNG) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you
replace `MNG-XXX`
and `SUMMARY` with the appropriate JIRA issue. Best practice is to
use the JIRA issue
title in the pull request title and in the first line of the commit
message.
- [x] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [x] You have run the [Core IT][core-its] successfully.
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [x] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [x] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
[core-its]: https://maven.apache.org/core-its/core-it-suite/
> 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)
