On 9 May 2014, at 9:24 pm, Luke Daley <luke.da...@gradleware.com> wrote:
> > > On 9 May 2014 at 3:07:05 pm, Luke Daley (l...@ldaley.com) wrote: > >> Hi, >> >> I’m trying to bust the new plugin portal code out of core-impl and parts out >> of core. I’m unsure about how to do this and avoid a circular dependency. >> >> There are 3 parts: >> >> 1. core - integrates plugin resolvers into the build lifecycle, provides >> dependency management services needed for plugin resolution >> 2. general plugin infrastructure for plugin resolvers to use (e.g. >> interfaces to implement) >> 3. specific plugin portal plugin resolver implementation >> >> My plan was to create a new ‘plugin-portal’ project for #3, and put the >> interfaces and support (#2) in ‘core’. Thus, circular dependency. >> >> The way that core-impl solves this is through some service loader >> indirection. I can see how we could do a similar thing in this case. The >> ‘plugin-portal’ project could advertise a PluginResolver implementation that >> ‘core’ loads at runtime. Therefore, ‘core’ would have no compile dependency >> on ‘plugin-portal’. Is this the way to go? >> >> One question then is how to order the plugin resolvers in core. If it just >> loads them arbitrarily off the classpath, what orders them? One option would >> be for the plugin portal resolver to be called out especially (e.g. it’s >> loaded via some kind of marker interface that lives in core). >> >> Any ideas? > > Another way to do this would be to move RepositoryHandler and > DependencyHandler and their dependencies out to a separate project like > dependency-resolution-api. That way plugin-portal can depend on this instead > of core to break the cycle. We’d also have to move the base plugin resolver > types out of core as well. > I would avoid this for 2 reasons: - This is only part of the dependency management DSL. The other parts have (cyclic) dependencies on the other parts of core. - The plugin resolution implementation should not be using the dependency management DSL. Instead it should be using dependency management services. I don’t want our infrastructure to interact via the DSL types. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com
