Thanks a lot for the advice! On Fri, Jan 27, 2012 at 21:17, Peter Niederwieser <pnied...@gmail.com>wrote:
> > Guillaume Laforge wrote > > > > Are there some good practices for building a project with different > Groovy > > versions, and offering JARs compiled against these versions? > > > > Say I have a project Foo, and I want to deliver a version "for" Groovy > > 1.8, > > and one for Groovy 2, etc. > > What is the best approach to adopt, in terms of project structure or > > simply > > how to configure a project build for that purpose? > > > > The straightforward approach would be to create multiple GroovyCompile, > Test, and Jar tasks and configure them manually. (You could also use the > Groovy plugin for the "main" Groovy version and add tasks for the other > versions.) I don't see this affecting the project structure (i.e. directory > layout). > > > Guillaume Laforge wrote > > > > Also what if there are features that I'd want to use in version n+1 of > > Groovy that is not available in version n, how would you tackle this > > problem? > > (ie. conditional compilation, à la #ifdef) > > > > First, it's easy to exclude certain sources from compilation. For example: > > task compileForGroovy18(type: GroovyCompile) { > source = sourceSets.main.groovy - files("**/groovy20/**") > } > > Alternatively, you could put Groovy 2.0 code into its own source set and > compile it separately. > > The bigger question is how to handle calling of the conditional code, but > that's a coding question. Depending on the concrete situation and needs, > the > whole conditional approach could become a pain, in which case branching is > another option (with different tradeoffs). The latter is what I do for > Spock, and it works well for me. > > -- > Peter Niederwieser > Principal Engineer, Gradleware > http://gradleware.com > Creator, Spock Framework > http://spockframework.org > Twitter: @pniederw > > > -- > View this message in context: > http://gradle.1045684.n5.nabble.com/Good-practices-for-building-with-different-Groovy-versions-tp5435677p5436529.html > Sent from the gradle-user mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Guillaume Laforge Groovy Project Manager SpringSource, a division of VMware Blog: http://glaforge.appspot.com/ Twitter: @glaforge <http://twitter.com/glaforge> Google+: http://gplus.to/glaforge