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
