groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Garcia <mario.g...@gmail.com>
Subject Re: compile vs compileOnly in Gradle projects for Groovy LIbraries
Date Sun, 23 Apr 2017 22:31:19 GMT
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 <tibokruse@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é <ysb33r@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
>

Mime
View raw message