You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Mark Hobson (JIRA)" <ji...@codehaus.org> on 2005/08/19 18:34:08 UTC
[jira] Created: (MNG-757) Transitive dependency resolution ignores custom repositories
Transitive dependency resolution ignores custom repositories
------------------------------------------------------------
Key: MNG-757
URL: http://jira.codehaus.org/browse/MNG-757
Project: Maven 2
Type: Bug
Versions: 2.0-beta-1
Environment: Windows XP, Cygwin
Reporter: Mark Hobson
Priority: Blocker
Attachments: projects.zip, settings.xml, test-repo.zip
The attached files set the scene:
* test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
* projects.zip - expand this for the projects
* settings.xml - the ~/.m2/settings.xml file
The scenario is as follows:
* test-repo contains a single artifact C
* project B depends on C
* project A depends on B & defines test-repo
* settings.xml also defines test-repo
The build process is:
* m2 install B (downloads C, installs B ok)
* m2 install A (finds B and C in local repo, installs A ok)
Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=all ]
John Casey closed MNG-757:
--------------------------
Resolution: Fixed
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-1
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=all ]
Brett Porter updated MNG-757:
-----------------------------
Fix Version: (was: 2.0-beta-1)
2.0-beta-2
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-2
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=comments#action_44807 ]
Brett Porter commented on MNG-757:
----------------------------------
btw, this is easier to test using a file:// repo than a test repo on http
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-1
> Attachments: projects.zip, settings.xml, test-repo.zip
>
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Reopened: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=all ]
Brett Porter reopened MNG-757:
------------------------------
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-1
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=comments#action_46341 ]
John Casey commented on MNG-757:
--------------------------------
I've worked another 3h on this issue, but I'm not at all sure how to log it properly without causing negative time estimation in JIRA...
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-2
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=comments#action_45847 ]
Brett Porter commented on MNG-757:
----------------------------------
rolled back due to MNG-836.
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-1
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=comments#action_44935 ]
John Casey commented on MNG-757:
--------------------------------
this would seem to imply that we expect dependency poms to have profiles from settings.xml merged into them...that doesn't sound right to me. The only way that a could transitively find c would be if:
1. the same set of repositories were used at all levels for dependency resolution...which would be defined in the project-to-be-built pom.xml file. This is how -alpha-3 worked.
2. we apply settings.xml profiles to all POMs we work with during the build, including dependency POMs.
If you think about the integrity of the dependency POM, these two are restatements of the same thing...modifying something that's meant to be an authoritative source of information for a graph of dependencies (the dependency and it's transitive closure).
I'm not sure it's wise to put all resolution control in the hands of your project's dependencies...so maybe it would be better to say that the project being built should provide the list of repositories used to resolve everything a la -alpha-3...? I bring this up since there was another JIRA issue filed to change that to repository-set-per-POM.
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-1
> Attachments: projects.zip, settings.xml, test-repo.zip
>
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=comments#action_44958 ]
John Casey commented on MNG-757:
--------------------------------
I think the correct solution here is to append successively deep transitive dependency POMs' repository definitions to the list being used for resolution, preserving repository uniqueness by id. This allows each project to have precedence in determining which repository a given artifact will be resolved from, while ensuring that the artifact will be resolved from somewhere...as long as those repositories are accessible.
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-1
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Remaining: 4 hours
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "Mark Hobson (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=comments#action_44940 ]
Mark Hobson commented on MNG-757:
---------------------------------
Not sure if the actual use-case that led to this helps, but I had:
1) project depending on Hibernate
2) Hibernate depending on JTA
3) JTA hosted on my repo
So JTA on my repo couldn't possibly be referenced by the ibiblio Hibernate POM, and so m2 needs help finding it. Either this could come from settings.xml, or maybe even a repo-hint added to the Hibernate dependency in the top-level project's POM?
I haven't been keeping up-to-speed on the latest design discussions, so whatever you guys think as long as there's a way of achieving this.
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-1
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Remaining: 4 hours
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=comments#action_44937 ]
Brett Porter commented on MNG-757:
----------------------------------
I think settings profiles should be applied to all poms - parents, deps and projects. The reason for this need to is to avoid the chicken and egg problem of a parent in a repository specified in the parent (which may happen in the project, or the dep - so needs to apply to both).
It may make sense to make the project authoratative, but that doesn't solve the chicken and egg problem either.
The other issue you refer to was to make the project repositories be searched before the parent (ie super POM), I think.
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-1
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Remaining: 4 hours
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=all ]
John Casey updated MNG-757:
---------------------------
Complexity: Expert (was: Intermediate)
Remaining Estimate: 4 hours
Original Estimate: 14400
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-1
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Remaining: 4 hours
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=comments#action_46267 ]
Brett Porter commented on MNG-757:
----------------------------------
the details are in MNG-836
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-2
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=all ]
Brett Porter updated MNG-757:
-----------------------------
Assign To: John Casey
Fix Version: 2.0-beta-1
yeah, this is a bug. probably a regression related to recent fixes in profile merging.
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-1
> Attachments: projects.zip, settings.xml, test-repo.zip
>
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=all ]
John Casey closed MNG-757:
--------------------------
Resolution: Fixed
Fix Version: (was: 2.0-beta-2)
2.0-beta-1
see it0068 and it2001
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-1
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=comments#action_46340 ]
John Casey commented on MNG-757:
--------------------------------
I'm functionally re-adding the code that got rolled back, because I suspect that this was not the root problem. In addition, I'm adding two integration tests: the first, it0068, will verify that MNG-836 is not repeated; the second, it2001, replicates the scenario originally laid out in this issue, and verifies that it works. This last test - it2001 - is complex, and must be run manually by executing test.sh inside the it2001 directory.
I'm going to commit what I have for this, and if regressions pop up, I guess we'll fix them.
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-2
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "Mark Hobson (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=comments#action_44960 ]
Mark Hobson commented on MNG-757:
---------------------------------
Sounds good to me. Would higher-level POMs have precedence over transitive dependency POMs? This would allow projects to override repositories, e.g. use an in-house repo for some dependencies rather than ibiblio (without mirroring the entirety of ibiblio).
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-1
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Remaining: 4 hours
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-757) Transitive dependency resolution ignores custom repositories
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-757?page=comments#action_46243 ]
John Casey commented on MNG-757:
--------------------------------
what are the details of the regression caused by this fix, do we know? Do we have a test in place to prevent future regressions?
> Transitive dependency resolution ignores custom repositories
> ------------------------------------------------------------
>
> Key: MNG-757
> URL: http://jira.codehaus.org/browse/MNG-757
> Project: Maven 2
> Type: Bug
> Versions: 2.0-beta-1
> Environment: Windows XP, Cygwin
> Reporter: Mark Hobson
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-2
> Attachments: projects.zip, settings.xml, test-repo.zip
>
> Original Estimate: 4 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> The attached files set the scene:
> * test-repo.zip - expand this into the root context of a local web server on 127.0.0.1:8080 for a test repo
> * projects.zip - expand this for the projects
> * settings.xml - the ~/.m2/settings.xml file
> The scenario is as follows:
> * test-repo contains a single artifact C
> * project B depends on C
> * project A depends on B & defines test-repo
> * settings.xml also defines test-repo
> The build process is:
> * m2 install B (downloads C, installs B ok)
> * m2 install A (finds B and C in local repo, installs A ok)
> Now the problem is if C is then deleted the second step fails - i.e. m2 only looks in the central repo for C and not the custom test-repo, even though test-repo is defined in both A's POM and settings.xml.
> This didn't happen in 2.0-alpha-3 - is this intentional?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org