On 08/08/2013, at 11:29 PM, Luke Daley <luke.da...@gradleware.com> wrote:
> > On 08/08/2013, at 2:01 PM, Sean Reilly <seanjrei...@gmail.com> wrote: > >> Luke, >> >> Thanks for the info. Comments inline: >> >> >>>> I'm fine with that if that's really the case, but if so, is it possible >>> for Gradle to emit (suitably grave) warnings if a plugin author uses the >>> internal api at all? I don't want to use gradle plugins that drastically >>> fail when I upgrade to a new version of gradle. >>> There would be a pretty severe cost on doing this at runtime. It's >>> something we can look into though. It's not an easy problem to solve. >> >> >> Fair enough. Off of the top of my head the only thing that would work would >> be some sort of classloader hierarchy for plugins, so that they would fail >> period if they tried to access internal packages. I'm sure that this would >> get really complicated really quickly, and it would probably just result in >> a poor implementation of OSGi. Blech. > > There are long term plans to make a stronger boundary between the > public/internal space. > > However, there is no plan to enforce runtime separation. I personally (other > devs may feel different) don't want to go down this route. 3rd party code > should be allowed to use internal API if they wish, but they take on the > responsibility that comes with that (i.e. no guarantee of any kind of cross > version compatibility). We'll probably make it opt-in, though, at some point. It would no longer be part of the implicit API visible to a plugin or build, but instead would become just another dependency that you declare you need and that is visible to conflict resolution and reporting. Then I can write rules about the kinds of plugins (and build scripts) I will accept in my builds. For example, I may state that I only want plugins (and build scripts) that are portable wrt Gradle version, or that I'm ok with community plugins that use internal APIs but any plugins my organisation writes must be portable. Or that I don't care. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
