Quantcast

compile vs compileOnly in Gradle projects for Groovy LIbraries

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

compile vs compileOnly in Gradle projects for Groovy LIbraries

ysb33r

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: compile vs compileOnly in Gradle projects for Groovy LIbraries

Jochen Theodorou
On 16.04.2017 23:38, Schalk Cronjé wrote:
[...]
>     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?

so you would let a user execute this with say groovy 2.0?

bye Jochen

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: compile vs compileOnly in Gradle projects for Groovy LIbraries

Thibault Kruse
In reply to this post by ysb33r
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é <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: compile vs compileOnly in Gradle projects for Groovy LIbraries

Mario Garcia
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 <[hidden email]>:
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é <[hidden email]> 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

Loading...