Ideas on modularization

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Ideas on modularization

hans_d
Administrator
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).

In the best of worlds our standard Java tasks would have no  
dependency on Ant. That would make embedding Gradle more convenient.  
On the other hand delegating to Ant tasks saves a lot of work.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Ideas on modularization

Adam Murdoch-2


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.  Fetching them from a repository somewhere if I happen to use
the java plugin would be a much nicer situation.


Adam

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Ideas on modularization

hans_d
Administrator
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