So I think really what you want vis-a-vis artifact resolution is a way to have a new repository system session with new/altered implementations for fixes or new behavior. Possibly a new repository system as well. If the default behavior continues to work, anyone can do whatever radical things they might like to experiment with provided the user knowingly flips the switch to enable the non-default behavior. Currently there is a DefaultRepositorySytemSessionFactory and we might want to allow picking a new one of those so that new managers, selectors, and transformers can be used. Maybe we modify this slightly if we want a new a new collector or resolver. This is orthogonal to the model changes that may or may not be made.
How do we enable this? I think a bunch of CLI switch is cumbersome, so maybe we officially introduce feature toggles in the settings. Useful for us and if teams want to run with certain features it will be easier to share this configuration. If we’re going to employ feature toggles then I think the settings is likely the place to do it. If so I can probably make a prototype in a few hours. From settings session properties can be made that reach most of code from end to end. But this allows branching by abstraction and all behavior can live in master. We can see all the implementations in one place and users won’t have to go build special branches to try things out, it will just be in the standard snapshots and the releases. If the features are off by default it won’t surprise any existing users. As for shoring up all the behaviour there are still 2-3 places where scopes are mutatate outside the scope of the existing Aether code which makes things fairly confusing. As I’m sure people people look at the final state and wonder how it happened because if they trace through Aether code everyone who does seems it didn’t happen there. That aspect is a mess. This should be consistent for plugins and the application resolution but it currently is not. > On Jul 29, 2016, at 8:50 PM, Jason van Zyl <ja...@takari.io> wrote: > > The model version doesn’t necessarily have anything to do with resolution or > any behavioral changes per se. I also don’t think a branch is necessary and > we do branching by abstraction and figure out the feature toggles now and > just keep it all in master. > >> On Jul 28, 2016, at 2:11 PM, Christian Schulte <c...@schulte.it> wrote: >> >> Am 28.07.2016 um 19:18 schrieb Jason van Zyl: >>> I’m a vehement -1 to changing the artifactIds or structure without a plan. >> >> +1 >> >> If something does not need to be renamed, then don't rename it. If something >> needs to be renamed, don't choose some kind of trademarkish name no-one >> knows what it stands for but something self-describing as much as possible. >> >>> We have to change the groupId because we cannot deploy into Eclipse’s >>> namespace but for anyone using this code just leave it how it is while >>> making improvements. >> >> +1 >> >>> The library as it stands functions and people are using it. We have >>> something in Maven core that uses it and it’s pretty terrible but it’s a >>> great place to start trying to flesh out something new because the ITs will >>> catch most things. >> >> We have recently discussed the addition of some kind of feature >> toggles/switches/knobs and haven't come to a conclusion yet. I would like to >> make the following proposal: >> >> Rename the branch 'maven-3.x-next' to 'maven-next'. Use the model version to >> decide about how Maven should behave when it comes to a change in behaviour >> between a previous model version and the next model version. Update the >> model version right now to the next model version on that 'maven-next' >> branch so things can get going there (setup Jenkins and things like that >> e.g.) All I need to know for this is what is the model version we will be >> using in that 'maven-next' branch today. Is it a minor version increment >> (4.1) or a major one (5.0). The reason I would like to use the model version >> instead of some kind of feature toggle is to be able to deploy to central or >> somewhere else. So that Maven can detect how to behave also for POMs it >> downloads from the repositories instead of relying on some command line >> option. >> >> Regards, >> -- >> Christian >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Takari and Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
