You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <p....@ubik-ingenierie.com> on 2019/08/06 11:57:39 UTC
Gradle Migration: .classpath files contain duplicate jars
eclipse task generates .classpath files containing duplicate version of
jars:
- asm
- groovy-all
Regards
--
[image: logo Ubik Ingenierie] <https://www.ubik-ingenierie.com> Philippe
Mouawad
Senior Performance Expert
320914981 <+33320914981> | p.mouawad@ubik-ingenierie.com
[image: ubik-ingenierie.com] ubik-ingenierie.com
<https://www.ubik-ingenierie.com> | [image: 03.20.91.49.81] 03.20.91.49.81
<+33320914981> | [image: 23 rue du chemin de fer , 59100 , Roubaix] 23 rue
du chemin de fer, 59100, Roubaix
<https://www.openstreetmap.org/#map=18/50.69454/3.16455>
Re: Gradle Migration: .classpath files contain duplicate jars
Posted by Philippe Mouawad <ph...@gmail.com>.
On Tue, Aug 6, 2019 at 4:30 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >we can inspect dependencies manually as a first step.
>
> I just don't like inspect things manually because I tend to make mistakes
> there.
>
Ok, let's see what other think.
>
> >I find the build already very complex. So I would KISS for now.
>
> Really?
> What is complicated?
>
It's just my feeling for now (I wrote "I feel" , not " it is ") with the
following context:
- I use Maven, I am a very beginner in Gradle.
- I don't know Kotlin, and the build is based on it. It's ok, I'll learn
it, but I thought it would be in Groovy initially.
- I use Eclipse, it seems it's more integrated for IDEA. IMO, the build
MUST also work smoothly with Eclipse, one of the migration aim was to
simplify IDE integration, it was not great for Eclipse and not made for
IDEA. Now it is smooth for IDEA (I haven't tested it and rely on what you
say) but not for Eclipse.
So I am starting to look at it.
For now I feel unable to maintain it or make it evolve, but for now it
looks ok to me as it's the begining.
As for me it looks quite simple and clean.
>
You built it, so it is naturally simple to you knowing you also knew
Gradle.
Yes it is clean.
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: Gradle Migration: .classpath files contain duplicate jars
Posted by Vladimir Sitnikov <si...@gmail.com>.
>we can inspect dependencies manually as a first step.
I just don't like inspect things manually because I tend to make mistakes
there.
>I find the build already very complex. So I would KISS for now.
Really?
What is complicated?
As for me it looks quite simple and clean.
Vladimir
Re: Gradle Migration: .classpath files contain duplicate jars
Posted by Philippe Mouawad <ph...@gmail.com>.
On Tuesday, August 6, 2019, Vladimir Sitnikov <si...@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
>
Re: Gradle Migration: .classpath files contain duplicate jars
Posted by Vladimir Sitnikov <si...@gmail.com>.
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.
However there are downsides as well:
2.1) We need to manually add exclusions
2.2) We need a way to detect the offending libraries
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.
Vladimir