I think the disconnect here is that the "resolution scope" != "specified scope"
That is to say if you ask for the runtime scope in a plugin, you get more than things declared "runtime". We all know this intuitively but it is confusing at times. Perhaps what is needed is the addition of a few more "resolution scope" tags that a plugin could ask for. I mean, how many combinations aren't already covered by the existing scopes? If it's small and adding one or two more might be easier to support and maintain than allowing a list of them...where many of the artifacts in each list overlap. Also, is there any potential conflict between what is resolved based on scope? If so, allowing lists might make that even more indeterminate. On Mon, Aug 3, 2009 at 5:02 AM, Benjamin Bentmann<[email protected]> wrote: > Barrie Treloar wrote: > >> I cant remember if this is already raised somewhere else, but there is >> similar problem with the scope "test". >> test means both testCompile and testRuntime (which themselves dont >> exist) so things like dependency:analyze reports errors because that >> level of granularity does not exist. > > Reminds me of MDEP-152 and MDEP-146. Anyway, please let us keep this > discussion focused on the original topic, otherwise I fear we won't get > anywhere. > > My concern was to allow plugins to easily/efficiently enforce resolution of > certain dependencies with the scopes that we have in place. Extending the > scope system to distinguish between test-compile and test-runtime is another > story. > > > Benjamin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
