Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Support mirrors that require authentication #37

Closed
cemerick opened this Issue Jun 24, 2012 · 3 comments

Comments

Projects
None yet
2 participants
Owner

cemerick commented Jun 24, 2012

gh-34 and gh-36 added basic support for mirrors. However, repositories provided by DefaultMirrorSelector never carry credentials, and so mirrors that require authentication will not work yet.

Aether has an AuthenticationSelector interface, which can be set on the system session to provide credentials for repositories generally; this seems tailor-made to support having a credentials store (such as settings.xml), and looks to be how aether adds credentials to the "bare" repositories that can be produced by a MirrorSelector.

This approach wouldn't mesh well with pomegranate; repositories are specified along with their credentials, and it seems like mirrors should be, too. My thought is to not use DefaultMirrorSelector at all, and instead provide a MirrorSelector implementation that returns repositories with credentials already set (using the same schema for :mirrors credentials as are currently used for :repositories credentials). This should eliminate the need for an AuthenticationSelector entirely, and allow us to carry on in our preferred way of providing credentials.

The one wrinkle is that the repository/mirror matching methods are private in DefaultMirrorSelector. I think it won't be too difficult to either wall-hack them, or use a dummy DefaultMirrorSelector to drive our own MirrorSelector's matching of repositories to mirrors.

(One idea might be to ditch the brain-dead matching mini-language that aether and maven specify. We have a lot of options that are a lot more powerful than what DefaultMirrorSelector implements. Insofar as pomegranate is ostensibly a wrapper for Aether, I don't know if this is a good or bad idea.)

Feedback definitely wanted before I head down the rabbit hole.

Contributor

technomancy commented Jun 24, 2012

If Aether is going to ignore mirror settings then maybe we should just punt on it. If :mirrors is just going to get merged into the :repositories map then maybe it should be delegated to whatever ends up calling pomegranate? Seems like Leiningen is going to have to end up implementing this in profile merge logic anyway, right?

I thought mirror use was going to be a feature with subtleties and edge cases, but the more I think about it the simpler it seems.

Owner

cemerick commented Jun 24, 2012

I don't think there's any ignoring of anything going on (or are you talking about the fact that mirrors aren't used for resolving direct dependencies, addressed in gh-36?).

Anyway, it can't be punted. Transitive dependencies' poms can specify additional repositories to use to resolve their dependencies, and so on. This is done even for artifacts in central (surprising, no?). Thus, at the very least, we need to be able to support *-mapped mirrors so that resolution won't leak outside of a mirror that an org/team is using to cache all artifacts, etc.

Contributor

technomancy commented Jun 24, 2012

Oh, OK; I misread what was going on in #36. Implementing our own MirrorSelector sounds like the way to go, and it seems like accepting an ifn predicate to perform the matching is way better than Maven's selection logic.

@cemerick cemerick closed this in fb1864b Jun 25, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment