question about plugins and multi-module builds

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

question about plugins and multi-module builds

Ittay Dror
Hi,

I'm not sure I understand how plugins work with multi-module builds.

Say I have a project with two modules: module_a and module_b.

I want a single build.gradle file to build both into a jar.

How do I use the java plugin to do that?

Does this do the trick?:
subprojects {
    usePlugin('java')
}

If I have also module_c, how do I define that only subprojects module_a
and module_b get the java plugin's functionality?

What tasks will module_c have? If none, then isn't it better to allow me
to define the type of projects as I create them, so instead of
'project(":module_a")' i can write 'javaproject(":module_a")' where
'javaproject' is defined by the java plugin and contains all tasks
(methods) to build the project? this will make a build file more inline
with familiar object oriented concepts (btw, i think prototype-oriented
is better for build files)

Ittay

--
--
Ittay Dror <[hidden email]>


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: question about plugins and multi-module builds

Ittay Dror
On Sun, Jun 22, 2008 at 10:47 PM, Ittay Dror <[hidden email]> wrote:

> Hi,
>
> I'm not sure I understand how plugins work with multi-module builds.
>
> Say I have a project with two modules: module_a and module_b.
>
> I want a single build.gradle file to build both into a jar.
>
> How do I use the java plugin to do that?
>
> Does this do the trick?:
> subprojects {
>   usePlugin('java')
> }
>
> If I have also module_c, how do I define that only subprojects module_a and
> module_b get the java plugin's functionality?
>
> What tasks will module_c have? If none, then isn't it better to allow me to
> define the type of projects as I create them, so instead of
> 'project(":module_a")' i can write 'javaproject(":module_a")' where
> 'javaproject' is defined by the java plugin and contains all tasks (methods)
> to build the project? this will make a build file more inline with familiar
> object oriented concepts (btw, i think prototype-oriented is better for
> build files)
Actually, mixins would be a better idiom, perhaps a plugin can
introduce mixins which i can then use?:
usePlugin('java')
subprojects(":module_a",":module_b") {
     mixin('java_jar')
}

>
> Ittay
>
> --
> --
> Ittay Dror <[hidden email]>
>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: question about plugins and multi-module builds

hans_d
Administrator
In reply to this post by Ittay Dror

On Jun 22, 2008, at 9:47 PM, Ittay Dror wrote:

> Hi,
>
> I'm not sure I understand how plugins work with multi-module builds.
>
> Say I have a project with two modules: module_a and module_b.
>
> I want a single build.gradle file to build both into a jar.
>
> How do I use the java plugin to do that?
>
> Does this do the trick?:
> subprojects {
>    usePlugin('java')
> }

Right

>
> If I have also module_c, how do I define that only subprojects  
> module_a and module_b get the java plugin's functionality?

subproject and allprojects are the names of method and fields.

The fields subproject and allprojects are lists of project objects.

The methods take a closure as an argument and delegate to the method  
configureProject like this:

configureProjects(subprojects, closure)

To configure a custom set of projects you can call configureProjects  
directly.

Either like: configureProjects([project(':module_a'), project
(':module_b')]) {
        // do something
}

or:

configureProjects(subprojects.findAll { somefilter }) {
       // do something
}

See also section 14.2.3 Project Filtering in the UG.

>
> What tasks will module_c have? If none, then isn't it better to  
> allow me to define the type of projects as I create them, so  
> instead of 'project(":module_a")' i can write 'javaproject
> (":module_a")' where 'javaproject' is defined by the java plugin  
> and contains all tasks (methods) to build the project?

project(':module_a') is just a query method to return a project  
object based on a path. It does not create anything.

> this will make a build file more inline with familiar object  
> oriented concepts (btw, i think prototype-oriented is better for  
> build files)

In fact Gradle is driven by the prototype notion (vs. inheritance).  
Our notion for the 'parent project' is that of a container not a  
superclass. Gradle offers convenience methods to make configuration  
of the container elements easy. But every project has its own state  
independent of the parent state. I think as well that using  
inheritance for configuration does usually not fit wll into the  
problem space of building.

- Hans

>
> Ittay
>
> --
> --
> Ittay Dror <[hidden email]>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

--
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: Re: question about plugins and multi-module builds

hans_d
Administrator
In reply to this post by Ittay Dror

On Jun 22, 2008, at 11:10 PM, Ittay Dror (Freiman) wrote:

> On Sun, Jun 22, 2008 at 10:47 PM, Ittay Dror <[hidden email]>  
> wrote:
>> Hi,
>>
>> I'm not sure I understand how plugins work with multi-module builds.
>>
>> Say I have a project with two modules: module_a and module_b.
>>
>> I want a single build.gradle file to build both into a jar.
>>
>> How do I use the java plugin to do that?
>>
>> Does this do the trick?:
>> subprojects {
>>   usePlugin('java')
>> }
>>
>> If I have also module_c, how do I define that only subprojects  
>> module_a and
>> module_b get the java plugin's functionality?
>>
>> What tasks will module_c have? If none, then isn't it better to  
>> allow me to
>> define the type of projects as I create them, so instead of
>> 'project(":module_a")' i can write 'javaproject(":module_a")' where
>> 'javaproject' is defined by the java plugin and contains all tasks  
>> (methods)
>> to build the project? this will make a build file more inline with  
>> familiar
>> object oriented concepts (btw, i think prototype-oriented is  
>> better for
>> build files)
> Actually, mixins would be a better idiom, perhaps a plugin can
> introduce mixins which i can then use?:
> usePlugin('java')
> subprojects(":module_a",":module_b") {
>      mixin('java_jar')
> }

As said in the previous email. The parent module may inject behavior  
and state into the subprojects. One important use case is applying a  
plugin to the subprojects. I can well imagine that mixin's are a very  
good mechanism to assemble plugin's.  And offering a mixin method to  
do this assembly on the fly might be cool. But right now I think I  
would create a certain plugin via mixin's and then apply it to the  
project (vs. to mixin a plugin into the project object). Gradle  
plugin's do two things. They change the structure of the project  
object. For example by adding properties or adding a convention  
object, in the future also by adding methods. This could be also  
achieved by applying a mixin directly to a project. But as important,  
they use the API of the project object to configure the project  
object (e.g. createTask('...')). This is something you can't achieve  
by mixing in something directly into the project object.

Groovy has no good support for mixin's yet, but this will improve  
with 1.6 (the additions are already in trunk).

- Hans

>
>>
>> Ittay
>>
>> --
>> --
>> Ittay Dror <[hidden email]>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
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: Re: question about plugins and multi-module builds

Ittay Dror
What I would like is a way for me, as a user, to model the conventions
used in my modules. So if, for example, I have many jar modules, that
use resource copying and say osgi, I would like to be able to pack all
of these functionalities (compile & package java, copy files, create
manifest file) and declare them as a 'StandardModule' class. Then, to be
able to say something like 'modle_a is a StandardModule'  (maybe by
"project('module_a'){use('StandardModule')}"). This combines the use of
convention object, plugins and custom tasks. Of course after that I may
want to hack some properties / tasks in a specific module.

Ittay

Hans Dockter wrote:

>
> On Jun 22, 2008, at 11:10 PM, Ittay Dror (Freiman) wrote:
>
>> On Sun, Jun 22, 2008 at 10:47 PM, Ittay Dror <[hidden email]>
>> wrote:
>>> Hi,
>>>
>>> I'm not sure I understand how plugins work with multi-module builds.
>>>
>>> Say I have a project with two modules: module_a and module_b.
>>>
>>> I want a single build.gradle file to build both into a jar.
>>>
>>> How do I use the java plugin to do that?
>>>
>>> Does this do the trick?:
>>> subprojects {
>>>   usePlugin('java')
>>> }
>>>
>>> If I have also module_c, how do I define that only subprojects
>>> module_a and
>>> module_b get the java plugin's functionality?
>>>
>>> What tasks will module_c have? If none, then isn't it better to
>>> allow me to
>>> define the type of projects as I create them, so instead of
>>> 'project(":module_a")' i can write 'javaproject(":module_a")' where
>>> 'javaproject' is defined by the java plugin and contains all tasks
>>> (methods)
>>> to build the project? this will make a build file more inline with
>>> familiar
>>> object oriented concepts (btw, i think prototype-oriented is better for
>>> build files)
>> Actually, mixins would be a better idiom, perhaps a plugin can
>> introduce mixins which i can then use?:
>> usePlugin('java')
>> subprojects(":module_a",":module_b") {
>>      mixin('java_jar')
>> }
>
> As said in the previous email. The parent module may inject behavior
> and state into the subprojects. One important use case is applying a
> plugin to the subprojects. I can well imagine that mixin's are a very
> good mechanism to assemble plugin's.  And offering a mixin method to
> do this assembly on the fly might be cool. But right now I think I
> would create a certain plugin via mixin's and then apply it to the
> project (vs. to mixin a plugin into the project object). Gradle
> plugin's do two things. They change the structure of the project
> object. For example by adding properties or adding a convention
> object, in the future also by adding methods. This could be also
> achieved by applying a mixin directly to a project. But as important,
> they use the API of the project object to configure the project object
> (e.g. createTask('...')). This is something you can't achieve by
> mixing in something directly into the project object.
>
> Groovy has no good support for mixin's yet, but this will improve with
> 1.6 (the additions are already in trunk).
>
> - Hans
>
>>
>>>
>>> Ittay
>>>
>>> --
>>> --
>>> Ittay Dror <[hidden email]>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
--
Ittay Dror <[hidden email]>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Re: question about plugins and multi-module builds

hans_d
Administrator

On Jun 23, 2008, at 9:21 AM, Ittay Dror wrote:

> I would like is a way for me, as a user, to model the conventions
> used in my modules. So if, for example, I have many jar modules, that
> use resource copying and say osgi, I would like to be able to pack all
> of these functionalities (compile & package java, copy files, create
> manifest file) and declare them as a 'StandardModule' class. Then,  
> to be
> able to say something like 'modle_a is a StandardModule'  (maybe by
> "project('module_a'){use('StandardModule')}").

Right now you can already write:

project('module_a) {
    usePlugin('java')
}

I agree that usePlugin is a bit lengthy. I also think about renaming  
it to 'use'.

> This combines the use of
> convention object, plugins and custom tasks. Of course after that I  
> may
> want to hack some properties / tasks in a spec

We are on the same page. We want to have fine grained building blocks  
and we want to be able to assemble them to higher order plugins.  
Gradle will provide some predefined assemblies. And the user should  
also be able to assemble its own plugin from those building blocks on  
the fly (without having to write a plugin). Somehow something like this:

use('compileAndPackage', 'copy')

- Hans

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





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

    http://xircles.codehaus.org/manage_email