The new Gradle plugin system

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

The new Gradle plugin system

hans_d
Administrator
What we are calling a plugin right now in Gradle is something very  
basic and actually not really a plugin. Right now we use plugins at  
the configuration phase to configure a project object (add tasks, set  
properties, ...). A better name would be Configurer for what they are  
doing right now.

We want to have something more generic. The new notion of a plugin is  
any library which has one or more plugin classes. A plugin class is a  
class which offers a set of methods (or closures) that take a project  
object as an argument (optionally also additional arguments).  Such a  
method might configure a project object like the current plugin's do  
(e.g. the JavaPlugin). But it might also take the project object just  
as an information source to do something, for example creating IDE  
files. Such plugin methods could also be also called via the command  
line. Or they could be called at execution time from a task.  A  
plugin library can have dependencies, can be downloaded from a  
repository, etc... In particular such a plugin library can be build  
as a part of a multi-project build.

I'm looking forward to implementing this. This is just a rough  
outline. Any feedback is very welcome.

- 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: The new Gradle plugin system

Ittay Dror

hdockter wrote
I'm looking forward to implementing this. This is just a rough  
outline. Any feedback is very welcome.
If A plugin adds tasks (targets) to the project, can't they then be called like any other task, have dependencies, etc?

A question about plugins is the use of the convention object. It looks like currently there can only be one convention object (JavaPlugin does 'project.convention = javaConvention' and if convention exists, leave it as is). Wouldn't this create conflicts when multiple plugins are used?

Ittay
Reply | Threaded
Open this post in threaded view
|

Re: The new Gradle plugin system

Ittay Dror
In reply to this post by hans_d
One thing I find great in Maven is the way plugins are just another type of dependency that Maven downloads and uses automatically. As more and more plugins are used in a build environment, it becomes more cumbersome to tell the developers to download and drop them in the right directory them manually.

So, why not use the artifact identification for plugins and let gradle download them automatically using ivy? something like plugin('org.gradle:java')? (there's no version on purpose, this means use latest). Gradle can still be shipped with a default plugin repository, and maybe maintain the ability to use classes directly (plugin(class: MyPlugin)), for ad-hoc plugins.

Ittay
Reply | Threaded
Open this post in threaded view
|

Re: The new Gradle plugin system

hans_d
Administrator
In reply to this post by Ittay Dror

On May 28, 2008, at 9:10 AM, Ittay Dror wrote:

>
>
>
> hdockter wrote:
>>
>> I'm looking forward to implementing this. This is just a rough
>> outline. Any feedback is very welcome.
>>
>
> If A plugin adds tasks (targets) to the project, can't they then be  
> called
> like any other task, have dependencies, etc?

Those tasks can be called like any other task. I'm not sure though  
what you mean with 'have dependencies'. When we say

dependencies {
     compile "x:y:3.0.5"
}

this assigns a dependency to the compile configuration. There is also  
a mapping which relates the compile configuration to the compile  
task, which allows the compile task to say: Give me a list of the jar  
files belonging to me.
This list of jar files can then be used by the task, for example for  
passing it to the Ant javac task. But this list of jar files are not  
really dependencies of the task.

>
> A question about plugins is the use of the convention object. It  
> looks like
> currently there can only be one convention object (JavaPlugin does
> 'project.convention = javaConvention' and if convention exists,  
> leave it as
> is). Wouldn't this create conflicts when multiple plugins are used?

Yes it would. The current plugin system is basic.

>
> Ittay
> --
> View this message in context: http://www.nabble.com/The-new-Gradle- 
> plugin-system-tp17239360p17506455.html
> Sent from the gradle-dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: The new Gradle plugin system

hans_d
Administrator
In reply to this post by Ittay Dror

On May 29, 2008, at 8:22 AM, Ittay Dror wrote:

>
> One thing I find great in Maven is the way plugins are just another  
> type of
> dependency that Maven downloads and uses automatically. As more and  
> more
> plugins are used in a build environment, it becomes more cumbersome  
> to tell
> the developers to download and drop them in the right directory them
> manually.
>
> So, why not use the artifact identification for plugins and let gradle
> download them automatically using ivy? something like
> plugin('org.gradle:java')? (there's no version on purpose, this  
> means use
> latest). Gradle can still be shipped with a default plugin  
> repository, and
> maybe maintain the ability to use classes directly (plugin(class:
> MyPlugin)), for ad-hoc plugins.

I agree. This is a feature we want to have for our new plugin system.

- Hans

>
> Ittay
> --
> View this message in context: http://www.nabble.com/The-new-Gradle- 
> plugin-system-tp17239360p17528003.html
> Sent from the gradle-dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: The new Gradle plugin system

Ittay Dror
Hi Hans,

hdockter wrote
> So, why not use the artifact identification for plugins and let gradle
> download them automatically using ivy? something like
> plugin('org.gradle:java')? (there's no version on purpose, this  
> means use
> latest). Gradle can still be shipped with a default plugin  
> repository, and
> maybe maintain the ability to use classes directly (plugin(class:
> MyPlugin)), for ad-hoc plugins.

I agree. This is a feature we want to have for our new plugin system.
Some small notes, just so that the plugin system doesn't become a mess like in maven:
1. when using a plugin, it uses the gradle core as installed, not downloading parts of it that were defined as dependencies (I have a maven system with 6 'maven-artifact' jars, 3 'maven-core', 6 'maven-model', etc., because each plugin brings the jar it was built against). Instead, plugins should define a range of versions of gradle they support (like in firefox). Maybe allow them to define other plugins they require or conflict with, but also, just with ranges they support (not a specific version that is downloaded automatically)
2. plugins should not be installed in a local repository somewhere, but somewhere under GRADLE_HOME, thus allowing a user to put them there manually
3. there should be the possibility to put plugins in the project's source tree (e.g., create a 'gradle' directory next to gradlefile). that way, if a developer checkouts the source tree, he already has all plugins and there's no need to rely on some remote repository to preserve them (btw, this is also true for regular dependencies: allow them to be stored in the source tree)
4. automatic downloading of plugins should be turned *off* by default. just error out if a plugin is not found and give a hint to the user of a command he can run to download all/some of the plugins required. Btw, an automatic check for plugin updates could be nice (but should be turned off easily).
5. missing plugins should be discovered early, for all modules, not as the build progresses. so a developer can install gradle, checkout the code, run something like 'gradle install-plugins' and know for sure that now he has all plugins

HTH,
Ittay
Reply | Threaded
Open this post in threaded view
|

Re: The new Gradle plugin system

Ittay Dror
Hi Again,
Ittay Dror wrote
Some small notes, just so that the plugin system doesn't become a mess like in maven:
One more thing: I think it should be possible for plugins to alter the behavior of Gradle, not just add targets and tasks to projects. This can be done a-la osgi or java's ServiceLoader. For example, in Ant, if a library has the file META-INF/services/org.apache.tools.ant.ProjectHelper, then it defines the project helper.

Ittay
Reply | Threaded
Open this post in threaded view
|

Re: The new Gradle plugin system

hans_d
Administrator

On Jun 11, 2008, at 7:25 AM, Ittay Dror wrote:

>
> Hi Again,
>
> Ittay Dror wrote:
>>
>>
>> Some small notes, just so that the plugin system doesn't become a  
>> mess
>> like in maven:
>>
>
> One more thing: I think it should be possible for plugins to alter the
> behavior of Gradle, not just add targets and tasks to projects.  
> This can be
> done a-la osgi or java's ServiceLoader. For example, in Ant, if a  
> library
> has the file META-INF/services/org.apache.tools.ant.ProjectHelper,  
> then it
> defines the project helper.

Interesting. I'm thinking about using OSGI for the plugin system  
anyway, but I'm no sure yet.

An complementary approach for customization is to provide lifecycle  
events and listeners.

- Hans

>
> Ittay
> --
> View this message in context: http://www.nabble.com/The-new-Gradle- 
> plugin-system-tp17239360p17770308.html
> Sent from the gradle-dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: The new Gradle plugin system

Ittay Dror

hdockter wrote
An complementary approach for customization is to provide lifecycle  
events and listeners.
Another one is to provide AOP capabilities.

Ittay
Reply | Threaded
Open this post in threaded view
|

Re: The new Gradle plugin system

hans_d
Administrator

On Jun 11, 2008, at 9:00 AM, Ittay Dror wrote:

>
>
>
> hdockter wrote:
>>
>> An complementary approach for customization is to provide lifecycle
>> events and listeners.
>>
>
> Another one is to provide AOP capabilities.

I hope to start the work on the new plugin system next week. I'm  
looking forward to exchanging ideas (or code :)).

- Hans

>
> Ittay
> --
> View this message in context: http://www.nabble.com/The-new-Gradle- 
> plugin-system-tp17239360p17771260.html
> Sent from the gradle-dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: The new Gradle plugin system

hans_d
Administrator
In reply to this post by Ittay Dror

On May 28, 2008, at 9:10 AM, Ittay Dror wrote:

>
>
>
> hdockter wrote:
>>
>> I'm looking forward to implementing this. This is just a rough
>> outline. Any feedback is very welcome.
>>
>
> If A plugin adds tasks (targets) to the project, can't they then be  
> called
> like any other task, have dependencies, etc?
>
> A question about plugins is the use of the convention object. It  
> looks like
> currently there can only be one convention object (JavaPlugin does
> 'project.convention = javaConvention' and if convention exists,  
> leave it as
> is). Wouldn't this create conflicts when multiple plugins are used?

This problem is solved in Gradle 0.2. See UG 8.2.1.

- Hans

>
> Ittay
> --
> View this message in context: http://www.nabble.com/The-new-Gradle- 
> plugin-system-tp17239360p17506455.html
> Sent from the gradle-dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: The new Gradle plugin system

Ittay Dror
Hi Hans,

As I wrote before, I'm trying to create a plugin to compile C++ resources. What I'm finding is that I need to duplicate a lot of the code of the JavaPlugin (some I get by subclassing, but apply() for example first sets the convention object and then uses it, so I need to redefine the whole method).

I think it would be good to have a default convention object (things like source directory, output directory will always be needed), and also add to it a set of targets. Then, each plugin can set its own convention plugin, with targets that will be executed by the default targets. A plugin can then set his targets to depend on another plugin's targets if required.

Take for example the following scenario:
1. a module has some resource files, java files and c files that implement jni methods.
--> so 'java' and 'cpp' plugins are needed.
2. which of them adds the task of copying resources?
--> that should be a third (default?) plugin
3. the flow is:
a. copy resources
b. compile java classes
c. run javah on the classes
d. compile c files
--> the 'compile' task from the cpp plugin should depend on the javah task (added by the cpp plugin) that depends on the 'compile' task of the java plugin. doing this with 'doLast' is not very good, since then the order of using the plugins becomes important. i expect something like createTask('javah', dependsOn: convention.java.tasks.compile)
4. also, this means two artifacts are created during build: jar and shared library (.so/.dll), so there should be two tasks for uploading each.

Ittay


hdockter wrote
On May 28, 2008, at 9:10 AM, Ittay Dror wrote:

>
>
>
> hdockter wrote:
>>
>> I'm looking forward to implementing this. This is just a rough
>> outline. Any feedback is very welcome.
>>
>
> If A plugin adds tasks (targets) to the project, can't they then be  
> called
> like any other task, have dependencies, etc?
>
> A question about plugins is the use of the convention object. It  
> looks like
> currently there can only be one convention object (JavaPlugin does
> 'project.convention = javaConvention' and if convention exists,  
> leave it as
> is). Wouldn't this create conflicts when multiple plugins are used?

This problem is solved in Gradle 0.2. See UG 8.2.1.

- Hans

>
> Ittay
> --
> View this message in context: http://www.nabble.com/The-new-Gradle- 
> plugin-system-tp17239360p17506455.html
> Sent from the gradle-dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: The new Gradle plugin system

Ittay Dror
Just to add another thought. Maybe scratch the standalone convention object and instead have the plugin object be the convention object, with tasks collection and properties. It can have an 'init' method if it needs to define any core gradle mechanisms, but simple plugins will not need it.

ittay
Ittay Dror wrote
Hi Hans,

As I wrote before, I'm trying to create a plugin to compile C++ resources. What I'm finding is that I need to duplicate a lot of the code of the JavaPlugin (some I get by subclassing, but apply() for example first sets the convention object and then uses it, so I need to redefine the whole method).

I think it would be good to have a default convention object (things like source directory, output directory will always be needed), and also add to it a set of targets. Then, each plugin can set its own convention plugin, with targets that will be executed by the default targets. A plugin can then set his targets to depend on another plugin's targets if required.

Take for example the following scenario:
1. a module has some resource files, java files and c files that implement jni methods.
--> so 'java' and 'cpp' plugins are needed.
2. which of them adds the task of copying resources?
--> that should be a third (default?) plugin
3. the flow is:
a. copy resources
b. compile java classes
c. run javah on the classes
d. compile c files
--> the 'compile' task from the cpp plugin should depend on the javah task (added by the cpp plugin) that depends on the 'compile' task of the java plugin. doing this with 'doLast' is not very good, since then the order of using the plugins becomes important. i expect something like createTask('javah', dependsOn: convention.java.tasks.compile)
4. also, this means two artifacts are created during build: jar and shared library (.so/.dll), so there should be two tasks for uploading each.

Ittay


hdockter wrote
On May 28, 2008, at 9:10 AM, Ittay Dror wrote:

>
>
>
> hdockter wrote:
>>
>> I'm looking forward to implementing this. This is just a rough
>> outline. Any feedback is very welcome.
>>
>
> If A plugin adds tasks (targets) to the project, can't they then be  
> called
> like any other task, have dependencies, etc?
>
> A question about plugins is the use of the convention object. It  
> looks like
> currently there can only be one convention object (JavaPlugin does
> 'project.convention = javaConvention' and if convention exists,  
> leave it as
> is). Wouldn't this create conflicts when multiple plugins are used?

This problem is solved in Gradle 0.2. See UG 8.2.1.

- Hans

>
> Ittay
> --
> View this message in context: http://www.nabble.com/The-new-Gradle- 
> plugin-system-tp17239360p17506455.html
> Sent from the gradle-dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: The new Gradle plugin system

hans_d
Administrator
In reply to this post by Ittay Dror

On Jun 17, 2008, at 7:51 PM, Ittay Dror wrote:

>
> Hi Hans,
>
> As I wrote before, I'm trying to create a plugin to compile C++  
> resources.
> What I'm finding is that I need to duplicate a lot of the code of the
> JavaPlugin (some I get by subclassing, but apply() for example  
> first sets
> the convention object and then uses it, so I need to redefine the  
> whole
> method).

I agree that is too simple.

>
> I think it would be good to have a default convention object  
> (things like
> source directory, output directory will always be needed),

Partly we can use the project object for this. In fact we do this  
already. For example buildDir (the output dir) is a project property.  
But I have been rather conservative about putting stuff in there. An  
additional default convention object is a good idea.

> and also add to
> it a set of targets. Then, each plugin can set its own convention  
> plugin,
> with targets that will be executed by the default targets. A plugin  
> can then
> set his targets to depend on another plugin's targets if required.
>
> Take for example the following scenario:
> 1. a module has some resource files, java files and c files that  
> implement
> jni methods.
> --> so 'java' and 'cpp' plugins are needed.
> 2. which of them adds the task of copying resources?
> --> that should be a third (default?) plugin
> 3. the flow is:
> a. copy resources
> b. compile java classes
> c. run javah on the classes
> d. compile c files
> --> the 'compile' task from the cpp plugin should depend on the  
> javah task
> (added by the cpp plugin) that depends on the 'compile' task of the  
> java
> plugin. doing this with 'doLast' is not very good, since then the  
> order of
> using the plugins becomes important. i expect something like
> createTask('javah', dependsOn: convention.java.tasks.compile)
> 4. also, this means two artifacts are created during build: jar and  
> shared
> library (.so/.dll), so there should be two tasks for uploading each.

I like this. In general the new plugin system must offer good  
mechanisms how different plugins can complement and associate with  
each other.

Regarding the roadmap. In my of my earlier emails I have said that I  
plan to immediately start with the new plugin system. I have changed  
plans in that I want to implement some rather urgently missing other  
pieces first. Is this critical for your C/C++ plugin? Of course I'm  
very happy if you already start with changing stuff to your needs.

- Hans

>
> Ittay
>
>
>
> hdockter wrote:
>>
>>
>> On May 28, 2008, at 9:10 AM, Ittay Dror wrote:
>>
>>>
>>>
>>>
>>> hdockter wrote:
>>>>
>>>> I'm looking forward to implementing this. This is just a rough
>>>> outline. Any feedback is very welcome.
>>>>
>>>
>>> If A plugin adds tasks (targets) to the project, can't they then be
>>> called
>>> like any other task, have dependencies, etc?
>>>
>>> A question about plugins is the use of the convention object. It
>>> looks like
>>> currently there can only be one convention object (JavaPlugin does
>>> 'project.convention = javaConvention' and if convention exists,
>>> leave it as
>>> is). Wouldn't this create conflicts when multiple plugins are used?
>>
>> This problem is solved in Gradle 0.2. See UG 8.2.1.
>>
>> - Hans
>>
>>>
>>> Ittay
>>> --
>>> View this message in context: http://www.nabble.com/The-new-Gradle-
>>> plugin-system-tp17239360p17506455.html
>>> Sent from the gradle-dev mailing list archive at Nabble.com.
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> 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
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/The-new-Gradle- 
> plugin-system-tp17239360p17927501.html
> Sent from the gradle-dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: The new Gradle plugin system

hans_d
Administrator
In reply to this post by Ittay Dror

On Jun 17, 2008, at 7:53 PM, Ittay Dror wrote:

>
> Just to add another thought. Maybe scratch the standalone  
> convention object
> and instead have the plugin object be the convention object, with  
> tasks
> collection and properties. It can have an 'init' method if it needs to
> define any core gradle mechanisms, but simple plugins will not need  
> it.

On first sight I like this idea. It is definitely more object  
oriented than the current separation.

- Hans

>
> ittay
>
> Ittay Dror wrote:
>>
>> Hi Hans,
>>
>> As I wrote before, I'm trying to create a plugin to compile C++  
>> resources.
>> What I'm finding is that I need to duplicate a lot of the code of the
>> JavaPlugin (some I get by subclassing, but apply() for example  
>> first sets
>> the convention object and then uses it, so I need to redefine the  
>> whole
>> method).
>>
>> I think it would be good to have a default convention object  
>> (things like
>> source directory, output directory will always be needed), and  
>> also add to
>> it a set of targets. Then, each plugin can set its own convention  
>> plugin,
>> with targets that will be executed by the default targets. A  
>> plugin can
>> then set his targets to depend on another plugin's targets if  
>> required.
>>
>> Take for example the following scenario:
>> 1. a module has some resource files, java files and c files that  
>> implement
>> jni methods.
>> --> so 'java' and 'cpp' plugins are needed.
>> 2. which of them adds the task of copying resources?
>> --> that should be a third (default?) plugin
>> 3. the flow is:
>> a. copy resources
>> b. compile java classes
>> c. run javah on the classes
>> d. compile c files
>> --> the 'compile' task from the cpp plugin should depend on the  
>> javah task
>> (added by the cpp plugin) that depends on the 'compile' task of  
>> the java
>> plugin. doing this with 'doLast' is not very good, since then the  
>> order of
>> using the plugins becomes important. i expect something like
>> createTask('javah', dependsOn: convention.java.tasks.compile)
>> 4. also, this means two artifacts are created during build: jar  
>> and shared
>> library (.so/.dll), so there should be two tasks for uploading each.
>>
>> Ittay
>>
>>
>>
>> hdockter wrote:
>>>
>>>
>>> On May 28, 2008, at 9:10 AM, Ittay Dror wrote:
>>>
>>>>
>>>>
>>>>
>>>> hdockter wrote:
>>>>>
>>>>> I'm looking forward to implementing this. This is just a rough
>>>>> outline. Any feedback is very welcome.
>>>>>
>>>>
>>>> If A plugin adds tasks (targets) to the project, can't they then be
>>>> called
>>>> like any other task, have dependencies, etc?
>>>>
>>>> A question about plugins is the use of the convention object. It
>>>> looks like
>>>> currently there can only be one convention object (JavaPlugin does
>>>> 'project.convention = javaConvention' and if convention exists,
>>>> leave it as
>>>> is). Wouldn't this create conflicts when multiple plugins are used?
>>>
>>> This problem is solved in Gradle 0.2. See UG 8.2.1.
>>>
>>> - Hans
>>>
>>>>
>>>> Ittay
>>>> --
>>>> View this message in context: http://www.nabble.com/The-new-Gradle-
>>>> plugin-system-tp17239360p17506455.html
>>>> Sent from the gradle-dev mailing list archive at Nabble.com.
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> 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
>>>
>>>
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/The-new-Gradle- 
> plugin-system-tp17239360p17927852.html
> Sent from the gradle-dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: The new Gradle plugin system

Ittay Dror
In reply to this post by hans_d
Hi Hans,
hdockter wrote
Regarding the roadmap. In my of my earlier emails I have said that I  
plan to immediately start with the new plugin system. I have changed  
plans in that I want to implement some rather urgently missing other  
pieces first. Is this critical for your C/C++ plugin? Of course I'm  
very happy if you already start with changing stuff to your needs.
It is not critical for my c/c++ plugin to work as a proof-of-concept, but it is critical to make it robust and stable. I don't feel comfortable  yet with changing Gradle itself, mainly because I don't have much time to invest.

Ittay