[Comment Edited] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[Comment Edited] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}

Robert Scholte (Jira)

    [ https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236787#comment-17236787 ]

Michael Osipov edited comment on MNG-5639 at 11/21/20, 8:30 PM:
----------------------------------------------------------------

I am confused, I see on Maven master:
{noformat}
commit 016932edbc6dfae2d0a8714a186a4e3a44174a78
Author: Mark Ingram <[hidden email]>
Date:   2014-05-27T16:44:06+02:00

    MNG-5639: Support resolution of Import Scope POMs from Repo that contains a ${parameter}

    Fix up previous

    Signed-off-by: Jason van Zyl <[hidden email]>
{noformat}

and on Core ITs:
{noformat}
commit ff75308bbcbbe6f3a2ef6b75d12042028098ce91
Author: Mark Ingram <[hidden email]>
Date:   2014-05-28T18:30:48+02:00

    MNG-5639 a test for resolving import scope POMs in DependencyManagement

    The new feature is allowing the repository URL to contain a property.

    Signed-off-by: Jason van Zyl <[hidden email]>
{noformat}

Can we assume this has been fixed with Maven 3.2.2? [~rfscholte], WDYT?

When I look at the IT, it looks ugly. a Property in a POM applies to a repo defined in the settings. Ouch.


was (Author: michael-o):
I am confused, I see on Maven master:
{noformat}
commit 016932edbc6dfae2d0a8714a186a4e3a44174a78
Author: Mark Ingram <[hidden email]>
Date:   2014-05-27T16:44:06+02:00

    MNG-5639: Support resolution of Import Scope POMs from Repo that contains a ${parameter}

    Fix up previous

    Signed-off-by: Jason van Zyl <[hidden email]>
{noformat}

and on Core ITs:
{noformat}
commit ff75308bbcbbe6f3a2ef6b75d12042028098ce91
Author: Mark Ingram <[hidden email]>
Date:   2014-05-28T18:30:48+02:00

    MNG-5639 a test for resolving import scope POMs in DependencyManagement

    The new feature is allowing the repository URL to contain a property.

    Signed-off-by: Jason van Zyl <[hidden email]>
{noformat}

Can we assume this has been fixed with Maven 3.2.2? [~rfscholte], WDYT?

> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> ------------------------------------------------------------------------------
>
>                 Key: MNG-5639
>                 URL: https://issues.apache.org/jira/browse/MNG-5639
>             Project: Maven
>          Issue Type: Improvement
>          Components: Dependencies
>    Affects Versions: 3.2.1
>            Reporter: Mark Ingram
>            Priority: Minor
>             Fix For: 3.7.x-candidate
>
>         Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR]   The project com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR]     Non-resolvable import POM: Could not transfer artifact org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to spring-milestones (${spring.url}): No connector available to access repository spring-milestones (${spring.url}) of type default using the available factories WagonRepositoryConnectorFactory @ line 20, column 25 -> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM model has successfully been resolved. So the correct value for the property is known and could in theory be substituted into the repository URL before the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the actual use case - several development streams are setup with individual sandboxed Nexus repository holding specific version of several shared components. The repository configuration uses the pattern $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in settings.xml file.
> One workaround would be to create profiles for every work stream that explicitly list the full repository URL, even then the above feature would be nice to allow the $\{nexus.baseurl} to avoid repeating that part.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)