On Jun 18, 2008, at 8:04 AM, Ittay Dror wrote:
Hi Hans,
Hans Dockter wrote:
On Jun 18, 2008, at 5:46 AM, Ittay Dror wrote:
Hi Hans,
I read the roadmap document, impressive.
I have one comment to make: about classloader isolation. do you
think it is
really necessary? look at firefox, that has a very rich set of
non-trivial
plugins. I don't think it has any isolation.
If I'm guessing your reasons for wanting this, it is to prevent
clashes when
two plugins require two versions of the same library. I think
this is a very
rare case.
It is rare but not that rare. I have been hitten by this a couple
of times. And look at Ivy. The reason why Ivy does not provide
WebDav support right now, is that commons-vfs (which is used by
Ivy) would need httpclient 2.x to provide this but Ivy itself uses
httpclient 3.x.
That is why I suggested providing this as an optional utility. So the
author of webdav-plugin will have some way of saying 'run inside a
private class loader' (which is really not a complex thing to achieve
for a specific case). Maybe also make it available to users, to solve
conflicts between plugins (whose authors are not aware of each other).
But not to make it something that always happens. I think this is a
general rule: if some complex use case requires a certain feature,
make
a utility that provides this feature, rather than incorporating it
into
the general framework.
However, if class loading is always used, it makes the system
more complex and less efficient. Maybe make this just a utility
that plugins
can use?
I was thinking about having an OSGi based plugin system. But
people have warned me that OSGi is a very complex technology. I'm
not sure yet.
I don't think it is complex, but I think it will increase the time to
the initial bootstrap.
This is an important point.
I think a build tool should primarily stay simple
and light weight. For that reason, please don't go with any type of
IOC
container.
This is not on the agenda.
I like the approach here:
http://gulopine.gamemusic.org/2008/jan/10/simple-plugin-framework/ for
I will have a look at this. I will also have a look at the Grails
plugin system.
- Hans
creating extensions.
On the one hand we want to deliver something within a reasonable
time frame and no excessive complexity on the other hand it should
have enterprise quality (whatever this means ;)). As yet I have
hardly any opinions on implementation details.
It should be a simple tool that keeps simple plugins simple and allows
complex plugins to achieve what they want. I think this is the area
where maven failed: any plugin that is used incurs a lot of overhead
(because the maven container does so many things) and is complex to
configure
(<build><plugins><plugin><artifactId>...</artifactId><groupId>...</
groupId><version>...</version><configuration>.............</
configuration></plugin></plugins></build>
just to set a simple property. Btw, it is so complex but I can't
reference one configuration parameter of the plugin in another).
- Hans
Ittay
hdockter wrote:
Hi all,
there is now a roadmap available at: http://gradle.org/roadmap.html
I have become convinced that a 1.0 release should not wait longer
than necessary.
Thanks for all your input
- Hans
On Jun 12, 2008, at 10:22 PM, pinus wrote:
hdockter wrote:
1.0 means API stability. For this Gradle should have a reasonable
install base so that we have enough feedback to be confident
that all
major use cases are properly covered.
You have a chicken and egg problem here. Who has time to check an
early release of an open source program? Just wait for the 1.0,
this will
be beta enough to test. No testers no response.
A roadmap is very important for me to decide if I seriously try or
wait.
--
View this message in context: http://www.nabble.com/Roadmap-
tp17752996p17808294.html
Sent from the gradle-user 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/Roadmap-
tp17752996p17959213.html
Sent from the gradle-user 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
--
--
Ittay Dror <[EMAIL PROTECTED]>
---------------------------------------------------------------------
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
