2009/8/3 Benjamin Bentmann <[email protected]> > Brian Fox wrote: > > 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... >> > > Sure, a new "resolution scope" should do as well. I think we really only > talk about a single new scope here, namely the combination of compile and > runtime, say "compile+runtime", "compile-plus-runtime" or <please insert > your well tasting name for the new scope here> such that we provide plugins > the following resolution scenarios: > > | compile | runtime | compile+runtime | test > ---------+---------+---------+-----------------+-------- > system | X | | X | X > provided | X | | X | X > compile | X | X | X | X > runtime | | X | X | X > test | | | | X > > I'm currently not aware of use cases that would require additional > combinations. > > Also, is there any potential conflict >> between what is resolved based on scope? If so, allowing lists might >> make that even more indeterminate. >> > > I'm not sure what kind of conflict you had in mind, when I proposed a list > of resolution scopes, I intended to logically OR them. > > To summarize, is something like > > @requiresDependencyResolution <our-new-super-cool-scope> > > a thing we all feel confident with? I.e. we would use the existing anno and > plugins wanting to use the new resolution scope would simply bump their > prerequisite on Maven. > > If we are going to the trouble of adding new scopes... any chance we can add a scope for integration testing at runtime (i.e. integration-test-time)
I am less sure on the need for a compile-integration-test scope, but I could be pursuaded! -Stephen > > Benjamin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
