On Oct 1, 2008, at 10:11 PM, snesbitt wrote:
We definitely have and will have much shorter release cycles.
Shorter release cycles will help, but really can't be guaranteed
especially
as complexity grows, and the number of plugins - especially
thirdparty -
supplied grow in number, complexity and usage.
If Eclipse is capable to manage to have a milestone release every 6
weeks we should also be able to do so. Otherwise something is going
into a wrong direction.
Third-party plugins have of course their own release cycle.
If definitely would make sense to be able to assign arbitrary
attributes for the forked JVM and the call to javac. In general I'm
not sure. The feature you are proposing would simply create a
namespace for each task, right?
I hadn't really given much thought to implementation, but a
namespace would
be one way.
The problem that I see now is to do what I suggested requires some
iffy
assumptions and/or detailed knowledge of the plugin internals. I
made the
assumption that compile was essentially a call to the ant javac
task. In
that context my request made sense. Under a different
implementation - like
direct calls to
javac - my request makes no sense and would be dangerous.
This is transparent. In our case here. 'memoryMaximumSize' is a
property of the Compile plugin. To be precise of the ForkOptions
class. This property has the same name as the Ant task property but
is a property on its own. So if we move from Ant javac to plain javac
this is an internal implementation change and would not change our
API. What this internal change would allow though, is to provide an
'additionalArguments' property. So if Java X would introduce a new
option for javac you would not have to wait for a new Gradle release
to use it. The Ant javac task does not provide such a generic property.
One thing I hated about Maven was the complexity of the plugins and
the
rigidity in behavior (not to mention bugs). It wasn't unusual to lose
confidence in a plugin and start seriously considering writing
one's own -
which negated a lot of the value of Maven.
It would be nice if Gradle avoided that "feature" <grin>
This is a good point which points to a fundamental problem of Maven
and the rigidity of XML based build scripts/declarations. You might
view a plugin/task as a little framework to solve a certain domain.
Frameworks are rigid by definition. If they are too rigid to solve
your problem the alternative is to use toolsets instead. But for
working with toolsets you need a real language to use them, this is
not possible with XML. The philosophy of Gradle is to provide small
frameworks for the major usecases. If this does not work out, you can
fall back to toolsets used with Groovy.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
