nice. as i work with the trunk, it should be no big act to try that out. thanks.
hdockter wrote: > > Hallo Helmut, > > On Sep 1, 2008, at 11:09 AM, Helmut Denk wrote: > >> >> hallo hans, >> >> >> hdockter wrote: >>> >>> This is all a question of priorities. Obviously supporting multi- >>> project builds for Eclipse is significantly more important than >>> integrating TestNG in our Java Plugin. >>> >> >> this is exactly true from my perspective. >> >> i migrated one of our 'multi-builds' (as we call it >> 'multi-module-build' and you call it 'multi-project-build' >> i shortcut the term ;-). >> >> using our existent repositories the gradle-build works >> well. even publishing through uploadLibs works - nice >> result for a start ... >> >> now next step would be to integrate with eclipse >> in a way that .project and .classpath are satisfied >> and unit-tests can be run from inside of eclipse ... > > In fact this is already implemented in trunk. With trunk you can say: > > gradle eclipse > > and the files mentioned by you above are generated. The Eclipse task > are documented by their Javadoc. See the classes. EclipseProject and > EclipseClasspath. The user's guide does not contain a section on this > yet. > > What we still have to implement is to enable multiproject builds > which have a non hierarchical structure. That is where the > gradle.settings file does not have to live in the parent dir of the > subprojects you want to build. > > - Hans > > -- > 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/Configuration-issues-tp19239895p19251594.html Sent from the gradle-dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
