jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Gradle Migration: .classpath files contain duplicate jars
Date Tue, 06 Aug 2019 13:38:08 GMT
On Tuesday, August 6, 2019, Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
wrote:

> That is interesting.
>
> TL;DR: quick workaround would be to replace `runtimev` with `apiv` for asm
> and groovy-all dependencies in :src:bom build script.
>
> The long story is "it's complicated".
>
>
> Technically speaking "asm" is caused json-smart:
>
> compileClasspath - Compile classpath for source set 'main'.
> +--- net.minidev:json-smart -> 2.3
> |    \--- net.minidev:accessors-smart:1.2
> |         \--- org.ow2.asm:asm:5.0.4
>
> It leaks "asm" dependency to a compile classpath of :src:components
>
> Technically speaking, net.minidev:json-smart should declare the dependency
> as "runtime" so
> the dependency does not accidentally leak to the compile classpath.
>
> I'm not sure what is the best way to resolve this.
>
> There are two approaches:
>
> 1) Use only `api` declarations in :src:bom. That would ensure that versions
> always match the ones declared in our "bill of material".
> The downsides are:
> 1.1) We would be able to add dependency like "org.ow2.asm:asm" or
> "org.codehaus.groovy:groovy-all" to our codebase.
> 1.2) We can accidentally import org.ow2.asm... because that dependency is
> leaked from json-smart.
>
> 2) Add exclude rules to the offending libraries.
> It would avoid accidental use of unwanted dependencies.


I’d go for this one.
It looks similar to what is done in Maven for broken dependencies.





> However there are downsides as well:
> 2.1) We need to manually add exclusions
>

Looks fine to me

> 2.2) We need a way to detect the offending libraries
>

we can inspect dependencies manually as a first step.

>
> There might be yet another approach: implement some sort of Gradle rules to
> automatically exclude certain libraries from the compile classpath.
> For instance, we could scan "bom", and automatically exclude "runtime"
> dependencies from compile classpath.
> I'm not sure how hard would it be.
>

I find the build already very complex. So I would KISS for now.


> Vladimir
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message