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