On Tue, Apr 14, 2015 at 11:55 AM, Jörg Schaible < joerg.schai...@swisspost.com> wrote:
> Hi Arnaud, > > Arnaud Héritier wrote: > > > On Mon, Apr 13, 2015 at 11:16 PM, Jörg Schaible <joerg.schai...@gmx.de> > > wrote: > > [snip] > > >> IMHO, mvjars will create a bigger maintenance mess than the current > >> solutions. > >> > > > > I don't know. I think it really depends if your are provider or consumer > > of mvjars. If you are consumer you may imagine to not have to manually > > switch anymore between several implementations (using classifiers ....) > > and it gives you the ability to do the selection at runtime and not at > > build time. As producer I agree that it won't be easy if tools (Build, > > IDE) aren't providing a good/simple support. That's why Oracle (Brian) is > > trying to involve us. > > Actually my biggest fear is for such a feature that some people will find > *very* creative ways to use it. Therefore I hope that mvjars will be > consequently restricted e.g. they should not be allowed to provide changes > in the API for different versions. Better safe than sorry. > yes, totally agree. For me it should be the case. As far as I understood the compiler should allow only to "override" a class or a method with a more optimized code. It shouldn't allow to add something (but I don't know how they'll do. Perhaps they'll allow only new private methods/fields) > > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
