Those are great points. Yet I would still much more prefer to solve those use cases without centralization of plugins within the distro.
We want to approach it as we do it at gradle - identify the use cases (for example: unwieldy declaration of the external plugin, etc.) then discuss and design the best ways to solve them. Cheers! On Sat, Mar 3, 2012 at 12:11 PM, Niclas Hedhman <[email protected]> wrote: > On Sat, Mar 3, 2012 at 6:39 PM, Szczepan Faber <[email protected]> wrote: > > > Please no... :) I much more prefer the exact opposite: pulling out > plugins > > so that they have a separate release cycle (potentially faster) and are > > easier for contributors to improve and innovate. > > Well, at the moment they do that, but it is hard to consume. Another > issue about "modular" is the Documentation. Another is the "Maven > effect", that you can never rely on plugins to have a common working > ground together. Maven is brittle because it is too modular. > > If I, as the Gradle user, have to manually maintain 2 dozen plugins' > versions and track their release cycles, then I will not be a happy > user after a while. If it is "automagic", then you are in Maven land. > From a users perspective a monolithic Gradle is preferred, but as a > Gradle developer a monolithic release is hard. So, you do the > Debian/Linux approach where each component is released independently, > but there is a "stable" monolith which users can depend on. > > And then you still need to have a nice integrated documentation. > Current Docs MAKES Gradle, more so than the code... > > Cheers > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/3xugrbk > I work here; http://tinyurl.com/6a2pl4j > I relax here; http://tinyurl.com/2cgsug > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
