Roadmap

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Roadmap

Ittay Dror
Hi,

Can you post a roadmap for Gradle, even if it is tentative. As the current version is 0.1.4, does it mean that Gradle now has ~14% of its final functionality? What else is there to expect? When do you think a 1.0 release will be (is it dependent only on core features, or the availability of plugins)?

Thank you,
Ittay
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap

hans_d
Administrator
Hi Ittay,

On Jun 10, 2008, at 1:19 PM, Ittay Dror wrote:

>
> Hi,
>
> Can you post a roadmap for Gradle, even if it is tentative. As the  
> current
> version is 0.1.4, does it mean that Gradle now has ~14% of its final
> functionality? What else is there to expect? When do you think a  
> 1.0 release
> will be (is it dependent only on core features, or the availability of
> plugins)?

Good point. I think for people who are considering to use Gradle it  
is important to get an idea about the direction.

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.

1.0 means also our vision and what Gradle stands for is implemented.  
I'm optimistic that with Gradle 0.3 we are fully competitive  
regarding all major features to for example Maven. We might as well  
call such a release 1.0. But in our vision there are features that go  
beyond what is offered by build tools today. And only when they are  
implemented we want to call it 1.0.

Gradle 0.1.5 will have a lot of improvements. Yet, as long as we are  
in the 0.X stream, we want to reserve the minor numbers for exciting  
new major features.

Our version policy is not carved in stone. If there are good  
arguments to do it differently we change our policy.

When the roadmap is ready I gonna announce it here on the list.

- Hans

>
> Thank you,
> Ittay
> --
> View this message in context: http://www.nabble.com/Roadmap- 
> tp17752996p17752996.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


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap

Ittay Dror
Hi Hans,

hdockter wrote
1.0 means also our vision and what Gradle stands for is implemented.  
I'm optimistic that with Gradle 0.3 we are fully competitive  
regarding all major features to for example Maven. We might as well  
call such a release 1.0. But in our vision there are features that go  
beyond what is offered by build tools today. And only when they are  
implemented we want to call it 1.0.
I think that Gradle offers a good feature set today. I also think that version numbers are important for companies when choosing a tool. It will be hard for a manager to choose a build tool that is in version 0.3. Even for open source projects, I think the reaction to seeing a 0.x version is "Let's look at it again in half a year". Also, look at Ant: it became mature only in version 1.6 (and even then, it didn't have Ivy).

Beyond version number, a large set of plugins is important. It creates a feeling that many use cases have been answered.

Ittay
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap

Xavier Hanin
On Tue, Jun 10, 2008 at 1:58 PM, Ittay Dror <[hidden email]> wrote:

Hi Hans,


hdockter wrote:
>
> 1.0 means also our vision and what Gradle stands for is implemented.
> I'm optimistic that with Gradle 0.3 we are fully competitive
> regarding all major features to for example Maven. We might as well
> call such a release 1.0. But in our vision there are features that go
> beyond what is offered by build tools today. And only when they are
> implemented we want to call it 1.0.
>

I think that Gradle offers a good feature set today. I also think that
version numbers are important for companies when choosing a tool. It will be
hard for a manager to choose a build tool that is in version 0.3.
I agree, a version number has a deep psychological effect. Call your versions milestones with sub numbers (eg 1.0-Mx.y instead of 0.x.y versions) and you will attract more users than with 0.x.y version scheme. Beta can be good as well.

Even for
open source projects, I think the reaction to seeing a 0.x version is "Let's
look at it again in half a year". Also, look at Ant: it became mature only
in version 1.6
But it still pull the heavy legacy load  of being backward compatible with 1.0. So if you really want to ensure backward compatibility in 1.x stream, don't release 1.x too early. Or you could simply target 2.0 as the mature killer version, 1.0 being used to attract people and increase the number of plugins. With Ivy we released a 1.0 pretty early, sometimes I think more time would have been needed to get a better maturity, but maybe Ivy wouldn't be where it is today without the increase in user number we've seen with 1.0.

My 2c.
Xavier



(and even then, it didn't have Ivy).

Beyond version number, a large set of plugins is important. It creates a
feeling that many use cases have been answered.

Ittay
--
View this message in context: http://www.nabble.com/Roadmap-tp17752996p17753658.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





--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap

hans_d
Administrator
Hi Xavier,

On Jun 10, 2008, at 7:34 PM, Xavier Hanin wrote:

> On Tue, Jun 10, 2008 at 1:58 PM, Ittay Dror <[hidden email]>  
> wrote:
>
> Hi Hans,
>
>
> hdockter wrote:
> >
> > 1.0 means also our vision and what Gradle stands for is implemented.
> > I'm optimistic that with Gradle 0.3 we are fully competitive
> > regarding all major features to for example Maven. We might as well
> > call such a release 1.0. But in our vision there are features  
> that go
> > beyond what is offered by build tools today. And only when they are
> > implemented we want to call it 1.0.
> >
>
> I think that Gradle offers a good feature set today. I also think that
> version numbers are important for companies when choosing a tool.  
> It will be
> hard for a manager to choose a build tool that is in version 0.3.
> I agree, a version number has a deep psychological effect. Call  
> your versions milestones with sub numbers (eg 1.0-Mx.y instead of  
> 0.x.y versions) and you will attract more users than with 0.x.y  
> version scheme. Beta can be good as well.
>
> Even for
> open source projects, I think the reaction to seeing a 0.x version  
> is "Let's
> look at it again in half a year". Also, look at Ant: it became  
> mature only
> in version 1.6
> But it still pull the heavy legacy load  of being backward  
> compatible with 1.0. So if you really want to ensure backward  
> compatibility in 1.x stream, don't release 1.x too early. Or you  
> could simply target 2.0 as the mature killer version, 1.0 being  
> used to attract people and increase the number of plugins. With Ivy  
> we released a 1.0 pretty early, sometimes I think more time would  
> have been needed to get a better maturity, but maybe Ivy wouldn't  
> be where it is today without the increase in user number we've seen  
> with 1.0.
>

Thanks a lot for sharing your experience with Ivy. As you and Ittay  
have proposed, it might be an alternative approach to use 1.0 as the  
'fully competitive' flag and 2.0 for most of the major new features  
we have in mind. We have some time to make a decision.

- Hans

> My 2c.
> Xavier
>
>
>
> (and even then, it didn't have Ivy).
>
> Beyond version number, a large set of plugins is important. It  
> creates a
> feeling that many use cases have been answered.
>
> Ittay
> --
> View this message in context: http://www.nabble.com/Roadmap- 
> tp17752996p17753658.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
>
>
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap

pinus
In reply to this post by hans_d
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.
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap

hans_d
Administrator
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


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap

Ittay Dror
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. 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?

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

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap

hans_d
Administrator

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.

> 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. 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.

- 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


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap

Ittay Dror
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 <[hidden email]>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap

hans_d
Administrator

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 <[hidden email]>
>
> ---------------------------------------------------------------------
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap

astubbs
Good evening Hans,

How does Maven deal with this problem?

hdockter wrote
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 <ittay.dror@gmail.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