[
https://issues.apache.org/jira/browse/MNG-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-7612:
---------------------------------
Description:
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.
was:
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, my 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.
> 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)
