Hi Adam,
On Aug 29, 2008, at 8:50 AM, Adam Murdoch wrote:
Hans Dockter wrote:
Hi,
I would like to share my ideas on the future modularization of
Gradle (if possible implemented for 1.0).
- A very small core jar which has only one dependency on slf4j. No
build-in tasks. Other projects can use this in an embedded way for
whatever reason they need an api for dependency based programming.
Jars with plugins and Tasks can be programatically added.
- A groovy decorated version of the core jar, with the same use
case as above but more convenient to use if people want to pay the
dependency and performance penalty.
- A very small Java only stand alone version of Gradle. It has
folders where you can just place build script engines and plugin
jars which are then automatically picked up.
- A Groovy and Java build script engine (with an own Java Ant
Builder).
This is a good plan.
Personally, I'd like to be able to download a small gradle
distribution which then downloads the bits I need, in slightly
finer grained chunks than the wrapper does (In fact, the solution
could be to change the wrapper so it can download stuff from an ivy
repository).
In order to add things like reporting to the plugins, currently we
have to add jars to gradle's lib directory. I'm reluctant to keep
just adding jars here.
I completely agree. One of the responsibilities of our future plugin
system will be to deal with plugin specific libs. Then in the gradle
lib dir we will only have the dependencies of gradle-core. Also the
build script engines will have there own libs.
Fetching them from a repository somewhere if I happen to use the
java plugin would be a much nicer situation.
The question were those libs should come from is independent of being
modular I think. It is a matter of taste. With the new plugin system
it should be definitely possible to download plugins on demand. I'm
not sure if it is a good idea to ship our core plugin's without the
libs, although our plugin system should be able to solve this use
case. Just yesterday I could not build Gradle because the JavaProject
integration test was stalled as the Maven repo was not responding.
This went on for hours. I finally refactored the JavaProject to use
local libs.
I don't feel strong about this. But in contrast to Maven it should be
easy for implementors to bundle the libs directly.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
