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
