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