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