I agree with Thibault, *compileOnly* and *provided* have specific objectives.
Besides you can always tell Gradle to force a specific version of a given module https://docs.gradle.org/current/userguide/dependency_management.html#sec:finetuning_the_dependency_resolution_process 2017-04-22 2:48 GMT+02:00 Thibault Kruse <tibokr...@googlemail.com>: > You do not really offer 'more control' that way, as build systems > today already offer full control over transitive dependencies. > Instead, what you do is to force users to handle transitive > dependencies to groovy in an explicit way (unless they happen to have > a groovy version from somewhere else), possibly helping users in > failing fast when no explicit dependency resolution exists. That may > be good or bad. > > IMO you are abusing compileOnly/provided scopes. compileOnly is meant > for things like marker annotations that will not go into the generated > bytecode. provided is meant for Containers such as in Java EE. > And abusing concepts is never a good thing. > > What can happen to users I guess is that they end up with a classpath like: > groovy-sql:2.1.6;groovy-all:2.4.6;groovy-nio:2.1.6 > > So probably it would be better for libraries to declare compile > dependencies, but not on groovy-all. > > And groovy should define at least documentation for how to handle such > conflicts in the best way. > > I also believe gradle has new features for dependency resolution > coming up, where groovy might also offer resolution rules to import > into gradle. > > > Also, BTW, I noticed the individual groovy POMs on maven central all > have the same description: 'Groovy: A powerful, dynamic language for > the JVM'. https://mvnrepository.com/artifact/org.codehaus.groovy > > Might be nicer to have individual descriptions, as a little finishing > touch. > > > On Mon, Apr 17, 2017 at 6:38 AM, Schalk Cronjé <ysb...@gmail.com> wrote: > > I am wondering what people's approach is to build Groovy libraries with > > Gradle. Most people will probably use something like > > > > dependencies { > > compile 'org.codehaus.groovy:groovy-all:2.4.7' > > } > > > > which will set the appropriate Groovy version as a dependency. This can > > obvisously lead to some interestign Groovy version resslution when > combining > > multiple libraires with different Groovy versions as dependencies. > > > > For a number of projects I have worked on, I have adopted the 'provided' > > scope via the Nebula plugin, or since 'compileOnly' has become available > in > > Gradle defaulted to that i.e. > > > > dependencies { > > compileOnly 'org.codehaus.groovy:groovy-all:2.4.7' > > } > > > > This obviously means that the consumer of one of my Groovy libraries has > to > > explicitly state which version of Groovy they require, but IMO it is > better > > that way as it gives them more control. > > > > Thoughts? > > > > -- > > Schalk W. Cronjé > > Twitter / Ello / Toeter : @ysb33r >
