On 20/10/2010, at 2:38 AM, Jason Hatton wrote:

> We are using gradle-wrapper and at first I wasn't sold on it because we had 
> some issues with it flipping between .8 and .9

That was an unintentional breakage, and we now have some integration tests in 
place to stop it happening again. The plan is that the wrapper should be 
forwards compatible with later versions of Gradle (or at the very least that 
you get a deprecation warning for a few versions before it stops working).

> but, I am convinced that is the right way to go especially in a team setting. 
>  Fortunately we know now what to do and look forward to an official GA 
> release of .9.
> 
> 
> 
> On Tue, Oct 19, 2010 at 10:00 AM, Steve Ebersole <[email protected]> wrote:
> We do exactly what you say in that each developer builds the IDE project
> themselves.  That along with the bundled gradle wrapper is very flexible for
> non-team members too (which you may not care about depending on your
> projects).
> 
> Better integration with IDEs will come in terms of IDEs scanning for Gradle
> projects and "importing them" the way IntelliJ, Eclipse and NetBeans currently
> do for Maven.  For IntelliJ users, vote here :
> http://youtrack.jetbrains.net/issue/IDEA-53476?projectKey=IDEA
> 
> 
> On Tuesday, October 19, 2010, at 09:44 am, Ben Dotte wrote:
> > I was curious, how do people handle updating Gradle dependencies in a team
> > environment?
> >
> > We initially tried generating Eclipse/IDEA projects and checking them into
> > git with the idea that anyone updating dependencies should regenerate those
> > so everyone's IDEs will see the change (although this would still require
> > each person to run Gradle to download the dependencies). At least in this
> > scenario there would be some obvious missing dependencies, but we have had
> > issues getting this working.
> >
> > The alternative is to make each dev build their own IDE project files each
> > time build.gradle changes. I'm not sure how people would realize the build
> > changed. I suppose things might not compile, or something more subtle might
> > happen with slightly wrong library versions.
> >
> > We could try notifying people of the change, but often different people are
> > working on different branches of code, and may not need to rebuild until
> > well after the change.
> >
> > Ideally there would be better integration with Eclipse/IDEA, but in the
> > mean time I haven't come across a great way to handle this.
> 
> ---
> Steve Ebersole <[email protected]>
> http://hibernate.org
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
>    http://xircles.codehaus.org/manage_email
> 
> 
> 


--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz

Reply via email to