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. 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. I like the approach here:
http://gulopine.gamemusic.org/2008/jan/10/simple-plugin-framework/ for
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
