Transitive dependency resolution ignores custom repositories

yeah, this is a bug. probably a regression related to recent fixes in profile merging.

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.

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.

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.

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.

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).

rolled back due to MNG-836.

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?

the details are in MNG-836

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.

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...

see it0068 and it2001