On 22/06/10 4:55 AM, Steve Ebersole wrote:
Personally I can see projects (mostly subprojects within a multi-module
build) that would not define source code at all. So I think those in
particular are inappropriate for general inclusion.
Now a base plugin that says "this is a project with source code of some
sort" would be a good candidate. Is that java-base?
Not quite. I think it would be bits of java-base (the source set
concept) and java (main and test source sets, plus unit testing and
publication as a jar).
On Mon, 2010-06-21 at 20:45 +0200, Meikel Brandmeyer wrote:
Hi,
Am 21.06.2010 um 08:43 schrieb Adam Murdoch:
There's really only the following lifecycle tasks at the moment:
* clean
* check
* assemble
* build
Arguably classes and test should be included in this list too.
+1
I'm the author of clojuresque (a gradle plugin for Clojure support). And classes and test
not being generally available is a slight annoyance, because I have to suck in the Java
plugin where it is not necessary. And on the other hand I cannot define my
"own" classes task, because then things blow up if people require both – Java
and Clojure. Or the user has to take care for plugin loading order, so that I can
conditionally define the task. Bleh. :(
Sincerely
Meikel
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
