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. — Luke Daley Gradleware Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com
