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
