Roadmap for 0.4

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

Roadmap for 0.4

hans_d
Administrator
Hi,

I plan to release 0.3 today, so it is time to think about the roadmap  
for 0.4.

In general I think it would be good to have short release cycles for  
the next releases. Something like 3 weeks. These are the issue I  
would like to resolve in 0.4:

- Complete Javadoc for all our public API. This involves a  
refactoring of the remaining Groovy tasks to Java.
- Further performance improvements of the DAG creation.
- Arbitrary multi-project layouts. Right now we require a  
hierarchical layout for multi-project builds. This is a strong  
limitation and in particular a problem for Eclipse. It also very much  
violates the promise of Gradle to be very flexible. Arbitrary layouts  
are also the base for some of our future power features.
- dependency layer refactoring: As discussed in this list in a thread  
with this name (the discussion is not finished)
- OPTIONAL: Phil Messenger has worked on eclipse classpath file  
generation. We might be able to bake this into 0.4.

- Hans

--
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 for 0.4

Adam Murdoch-2


Hans Dockter wrote:
> Hi,
>
> I plan to release 0.3 today, so it is time to think about the roadmap
> for 0.4.
>
> In general I think it would be good to have short release cycles for
> the next releases. Something like 3 weeks.
+1
> These are the issue I would like to resolve in 0.4:
>
This is a fine roadmap - I'd love to see any or all of this in 0.4.  
Interesting that there is no work on the plugins (apart from documenting
them, I guess).

Will you update jira to reflect this roadmap?
> - Complete Javadoc for all our public API. This involves a refactoring
> of the remaining Groovy tasks to Java.
I plan to keep chipping away at the javadocs, but I will probably mix it
up with a bit of coding. My immediate plan is to do a bit of work on
error handling/reporting and at the same time port the exception
hierarchy to java.

> - Further performance improvements of the DAG creation.
> - Arbitrary multi-project layouts. Right now we require a hierarchical
> layout for multi-project builds. This is a strong limitation and in
> particular a problem for Eclipse. It also very much violates the
> promise of Gradle to be very flexible. Arbitrary layouts are also the
> base for some of our future power features.
> - dependency layer refactoring: As discussed in this list in a thread
> with this name (the discussion is not finished)
> - OPTIONAL: Phil Messenger has worked on eclipse classpath file
> generation. We might be able to bake this into 0.4.
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for 0.4

hans_d
Administrator
Hi Adam,

On Aug 20, 2008, at 11:12 AM, Adam Murdoch wrote:

>
>
> Hans Dockter wrote:
>> Hi,
>>
>> I plan to release 0.3 today, so it is time to think about the  
>> roadmap for 0.4.
>>
>> In general I think it would be good to have short release cycles  
>> for the next releases. Something like 3 weeks.
> +1
>> These are the issue I would like to resolve in 0.4:
>>
> This is a fine roadmap - I'd love to see any or all of this in  
> 0.4.  Interesting that there is no work on the plugins (apart from  
> documenting them, I guess).

This is a question of priorities. Of course there are many features  
I'd rather see implemented today than tomorrow. But with a short  
release cycle in mind I think we either have to change priorities or  
this is what can be achieved in 3 weeks. I'm completely open to  
change priorities.

>
> Will you update jira to reflect this roadmap?
>> - Complete Javadoc for all our public API. This involves a  
>> refactoring of the remaining Groovy tasks to Java.
> I plan to keep chipping away at the javadocs, but I will probably  
> mix it up with a bit of coding. My immediate plan is to do a bit of  
> work on error handling/reporting and

Reporting is very important. My idea was to get this into 0.5. But if  
you tackle this now, all the better. There was one Ant task which  
integrates an armada of different reports. I can't remember its name  
right now. Another thing that might be interesting about reporting is  
not just to produce reports but also use them as tests. For example  
the build should fail if there are cyclic dependencies between  
packages. (http://72miles.com/architecturerules/).

I hope you have some resources left for discussions :) (in particular  
about the arbitrary layout issue).

> at the same time port the exception hierarchy to java.

Just to mention it. I've run into a strange compile error by groovyc  
when I have started doing this. I had no resources at that time to  
look into this.

- Hans

>> - Further performance improvements of the DAG creation.
>> - Arbitrary multi-project layouts. Right now we require a  
>> hierarchical layout for multi-project builds. This is a strong  
>> limitation and in particular a problem for Eclipse. It also very  
>> much violates the promise of Gradle to be very flexible. Arbitrary  
>> layouts are also the base for some of our future power features.
>> - dependency layer refactoring: As discussed in this list in a  
>> thread with this name (the discussion is not finished)
>> - OPTIONAL: Phil Messenger has worked on eclipse classpath file  
>> generation. We might be able to bake this into 0.4.
>>
>> - Hans
>>
>> --
>> Hans Dockter
>> Gradle Project lead
>> http://www.gradle.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_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 for 0.4

hans_d
Administrator
In reply to this post by Adam Murdoch-2

>
> Will you update jira to reflect this roadmap?
>> - Complete Javadoc for all our public API. This involves a  
>> refactoring of the remaining Groovy tasks to Java.
http://jira.codehaus.org/browse/GRADLE-174   
>> - Further performance improvements of the DAG creation.
http://jira.codehaus.org/browse/GRADLE-184
>> - Arbitrary multi-project layouts. Right now we require a  
>> hierarchical layout for multi-project builds. This is a strong  
>> limitation and in particular a problem for Eclipse. It also very  
>> much violates the promise of Gradle to be very flexible. Arbitrary  
>> layouts are also the base for some of our future power features.
http://jira.codehaus.org/browse/GRADLE-158   
>> - dependency layer refactoring: As discussed in this list in a  
>> thread with this name (the discussion is not finished)
http://jira.codehaus.org/browse/GRADLE-183
>> - OPTIONAL: Phil Messenger has worked on eclipse classpath file  
>> generation. We might be able to bake this into 0.4.
http://jira.codehaus.org/browse/GRADLE-28
>>

- Hans

--
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 for 0.4

dportello
hdockter wrote
>> - Arbitrary multi-project layouts. Right now we require a  
>> hierarchical layout for multi-project builds. This is a strong  
>> limitation and in particular a problem for Eclipse. It also very  
>> much violates the promise of Gradle to be very flexible. Arbitrary  
>> layouts are also the base for some of our future power features.
http://jira.codehaus.org/browse/GRADLE-158   
I'm curious as to how far this effort has come so far? I'm willing to pitch in a hand if there hasn't been much done. My team is using Eclipse and we require a multi-project build, so this feature is a must.

I've been hacking away at Gant and had something working, but at this point, it's not longer gant in my opinion. After a bit of research I stumbled upon gradle the other day and found that it meets most of our needs.

In the last day I've been review the tagged 0.3 code base and I have a general idea of what needs to be done, though I will have more questions.

I'm also willing to work on a corbortura plugin.

Thank you,
Dennis P.

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for 0.4

Adam Murdoch-2


dportello wrote:
hdockter wrote:
  
- Arbitrary multi-project layouts. Right now we require a  
hierarchical layout for multi-project builds. This is a strong  
limitation and in particular a problem for Eclipse. It also very  
much violates the promise of Gradle to be very flexible. Arbitrary  
layouts are also the base for some of our future power features.
        
http://jira.codehaus.org/browse/GRADLE-158   	

    

I'm curious as to how far this effort has come so far? 

Not particularly far at this stage.

I'm willing to pitch
in a hand if there hasn't been much done. My team is using Eclipse and we
require a multi-project build, so this feature is a must.

  

We've yet to figure out how this might work, though I reckon everyone already has some ideas.  I've started a thread to discuss the solution, if you want to join in.


Adam

--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for 0.4

hans_d
Administrator
In reply to this post by dportello
Hi Dennis,

On Aug 28, 2008, at 11:33 PM, dportello wrote:

>
>
> hdockter wrote:
>>
>>>> - Arbitrary multi-project layouts. Right now we require a
>>>> hierarchical layout for multi-project builds. This is a strong
>>>> limitation and in particular a problem for Eclipse. It also very
>>>> much violates the promise of Gradle to be very flexible. Arbitrary
>>>> layouts are also the base for some of our future power features.
>> http://jira.codehaus.org/browse/GRADLE-158   
>>
>
> I'm curious as to how far this effort has come so far? I'm willing  
> to pitch
> in a hand if there hasn't been much done. My team is using Eclipse  
> and we
> require a multi-project build, so this feature is a must.

I'm already working on this. I hope to submit a working solution  
sometimes next week.

>
> I've been hacking away at Gant and had something working, but at  
> this point,
> it's not longer gant in my opinion. After a bit of research I  
> stumbled upon
> gradle the other day and found that it meets most of our needs.
>
> In the last day I've been review the tagged 0.3 code base and I have a
> general idea of what needs to be done, though I will have more  
> questions.
>
> I'm also willing to work on a corbortura plugin.

Very cool. Adam also wanted to implement some reporting functionality  
for 0.4. I will start a thread on the dev list to discuss the best  
ways to integrate reporting.

What other features would you consider as nice-to-have for your project?

- Hans

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





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

    http://xircles.codehaus.org/manage_email