Would adding support for 2 new scopes be viable without changing the pom model ( the DTD/XSD doesn't actually define the values so that should be ok).
Specifically I'm thinking 'annotation' ( having annotationPaths on m-c-p was a workaround, but kinda horrible in practice ), and maybe "module" for the new module path? On the topic of scopes, I'd love to see an _actual_ compile-time-only scope, thats only at compilation. I wonder, since the scope values are not actually set in the DTD/XSDs, could the internals be altered to say a CSV of scopes, with the default being "compile,test" which would cover current behaviour - but if you specifically say "this is a compile only dependency" then it literally is. Mark -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree On Sun, Nov 5, 2017 at 1:20 AM, Stephen Connolly < [email protected]> wrote: > The past two days, Hervé, Robert and I have been discussing our next steps. > > I think we have a semi-consensus which I want to bring back to the list: > > We keep 3.5.x as a stable branch with critical bug fixes only > > We switch master to 4.0.0 and start to burn down a release scope. > > 4.0.0 will not change the pom modelVersion > > The 4.0.0 scope should probably be: > > Required: > * drop Java 7, switch codebase to Java 8 idioms (while maintaining binary > api compatibility for plugins) > * specify the classloader behaviour and fix impl to align with spec (may > need a plugin flag to allow plugins to opt in to spec behaviour) > * specify the extension spec > * allow limited mutation of the runtime model (reducing transitive > dependencies for consumers within the reactor, only for plugin goals that > declare intent) use case: shade plugin > * better CI integration hooks > * nice error message for newer pom modelVersion > > Optional: > * (damn I forgot, maybe Robert remembers) > -- > Sent from my phone >
