You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Tamas Cservenak (Jira)" <ji...@apache.org> on 2022/11/23 08:33:00 UTC

[jira] [Updated] (MRESOLVER-297) Chained LRM

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

Tamas Cservenak updated MRESOLVER-297:
--------------------------------------
    Description: 
Implement "chained" LRM. This utility would NOT meant to be used in any production env, but rather in some confined use cases like "isolated" environment like running IT tests.

If you split "inner" and "outer" build when for example running Maven IT Suite, the "outer" build is directly affected by user setup (user settings.xml and other things), while "inner" is (should be) isolated. Moreover, the "outer" build builds plugins and dependencies that are required by "inner" build. Simply sharing same local repository does not work, see for example MNG-5185 but it boils down to this:
 * Maven3 enhanced local repo tracks "artifact availability", by repo ID and this is affected by user env (ie. MRM being used with own repo ID)
 * inner IT build has central repo "shut down" (file/null), as it expects all resolved and present in local repo by "outer" build
 * while this is true (files are present) they may be not available, as "outer" build user env may use different settings than inner (ie. a MRM with own repo ID)

The implemented "chained" LRM can isolate local repo for ITs:
 * sandbox  "inner" build ITs into own local repo
 * but allow artifact resolution from local repo used by "outer" build
 * this 2nd is needed as dependencies and artifacts built by "outer" build are needed in "inner" build

  was:
Implement "chained" LRM. This utility would NOT meant to be used in any production env, but rather in some confined use cases like "isolated" environment like running IT tests.

If you split "inner" and "outer" build when for example running Maven IT Suite, the "outer" build is directly affected by user setup (user settings.xml and other things), while "inner" is (should be) isolated. Moreover, the "outer" build builds plugins and dependencies that are required by "inner" build. Simply sharing same local repository does not work, see for example MNG-5185 but it boils down to this:
 * Maven3 enhanced local repo tracks "artifact availability", by repo ID and this is affected by user env (ie. MRM being used with own repo ID)
 * inner IT build has central repo "shut down" (file/null), as it expects all resolved and present in local repo by "outer" build
 * while this is true (files are present) they may be not available (as outer build user env uses different settings than inner)

The implemented "chained" LRM can isolate local repo for ITs:
 * sandbox  "inner" build ITs into own local repo
 * but allow artifact resolution from local repo used by "outer" build
 * this 2nd is needed as dependencies and artifacts built by "outer" build are needed in "inner" build


> Chained LRM
> -----------
>
>                 Key: MRESOLVER-297
>                 URL: https://issues.apache.org/jira/browse/MRESOLVER-297
>             Project: Maven Resolver
>          Issue Type: New Feature
>          Components: Resolver
>            Reporter: Tamas Cservenak
>            Priority: Major
>             Fix For: 1.9.2
>
>
> Implement "chained" LRM. This utility would NOT meant to be used in any production env, but rather in some confined use cases like "isolated" environment like running IT tests.
> If you split "inner" and "outer" build when for example running Maven IT Suite, the "outer" build is directly affected by user setup (user settings.xml and other things), while "inner" is (should be) isolated. Moreover, the "outer" build builds plugins and dependencies that are required by "inner" build. Simply sharing same local repository does not work, see for example MNG-5185 but it boils down to this:
>  * Maven3 enhanced local repo tracks "artifact availability", by repo ID and this is affected by user env (ie. MRM being used with own repo ID)
>  * inner IT build has central repo "shut down" (file/null), as it expects all resolved and present in local repo by "outer" build
>  * while this is true (files are present) they may be not available, as "outer" build user env may use different settings than inner (ie. a MRM with own repo ID)
> The implemented "chained" LRM can isolate local repo for ITs:
>  * sandbox  "inner" build ITs into own local repo
>  * but allow artifact resolution from local repo used by "outer" build
>  * this 2nd is needed as dependencies and artifacts built by "outer" build are needed in "inner" build



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