My memory (which is really bad...) is that I didn't understand why this code existed, or how to re-implement it with the changes I was doing. I couldn't find a way to make the old code make any sense (every case I tried didn't exercise it), so I just commented it out. I meant to address that issue when submitting this change, but it slipped. Sorry about that!
On Tue, Sep 8, 2009 at 6:09 AM, Hans Dockter <[email protected]> wrote: > In Gradle trunk there is a bug regarding the handling of settings.gradle. > > The following rule is no longer obeyed: If a settings.gradle file is found, > Gradle checks if the current project is part of the multiproject hierarchy > defined in the found settings.gradle file. If not, the build is executed as > a single project build. Otherwise a multiproject build is executed. > > If I now go to the samples directory and execute the hello world sample, > the settings.gradle of the Gradle build is compiled. You have to use the -u > option to prevent this. > > @John: The SettingsHandler class introduced in Revision 1739 (GRADLE-421 > Allow buildSrc classes to be used in the settings script. Patch supplied by > John Murp) has some commented out logic to implement the above rule. Can you > remember why it was commented out? > > In a later commit Adam has removed the commented out code. > > - Hans > > -- > Hans Dockter > Gradle Project Manager > http://www.gradle.org > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- John Murph Automated Logic Research Team
