One more: Better support for classifiers. ideally be able to reference them
via a {$project.classifier} type of construct, esp so I can use/reference
them in assemble transformations.This might be able to be done without bumping to V4 though. On Sun, Nov 12, 2017 at 6:41 PM, Chris Graham <chrisgw...@gmail.com> wrote: > required: > - *everything* in settings.xml can be put in a profile section in > settings.xml. > > I often move around/between projects and having to redo mirrors section, > and unable to add servers into the profile section for clarity is a pain. > > For me, it's just a matter of convienence. > > On Sat, Nov 4, 2017 at 11:20 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> 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 >> > >
