Thanks, you're the first person to admit that this is a valid use case and not just some arcane process unique to my situation :)
2008/7/1 Brian E. Fox <[EMAIL PROTECTED]>: > >1. A locked down repo in which only "approved" versions of some deps > exist. > > >2. An open repo which proxied on to maven central. > > This is commonly done where the CI system uses only the approved > versions and the devs are free to use the proxied one. It simply means > that they must be sure that the dependencies are in the approved version > before they commit/merge or obviously the CI will fail (as it should) > > >Note that the process of approving an artifact is not trivial - we need > to > >vet each dep and each transitive dep of said deps - don't really want > to do > >all this rigmarole in the case of test-scope and plugin deps. > > This simply isn't possible at the moment. As you discovered, even the > pluginRepository separation isn't working perfectly because it tries to > find the plugin's deps in a normal repo. Further, the pluginRepository > separation is deprecated in 2.1 because it doesn't really get any > benefit and generally makes a mess of things. > > You have a valid use case here, but it simply hasn't been proposed or > coded. This is something that could be done, but more likely in the 2.2 > timeframe. > > >Even if maven somehow communicated the scope of the artifact it is > >requesting to the repository I could work around this at the repository > >level; i.e., for e.g., the open-proxied repo would reject all requests > for > >compile/runtime dependencies and only allows requests for test and > plugin > >dependencies and their transitive dependencies, but maven swallows up > this > >information before making the call to the repository. > > >Is sending this information along with the call to the repository > difficult? > >I have no idea how maven resolves dependencies so have no idea as to > how > >easy/difficult this is. > > This would require a new wagon implementation to be tightly tied to a > repository manager like Nexus as the current defaults are using regular > http gets and convey no information other than the file they want. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
