Comments (7)
@Natoshka yours is a very different case, and I see no bug. Note this text in your reason
output:
* Exposes 3 classes: com.fasterxml.jackson.databind.JsonNode, com.fasterxml.jackson.databind.annotation.JsonDeserialize, com.fasterxml.jackson.databind.annotation.JsonSerialize (implies api).
Please see this.
from dependency-analysis-gradle-plugin.
@autonomousapps WOW! Thanks for such insight! It seems I have been using Gradle wrong 😳 And thanks for plugin, by the way ❤️
from dependency-analysis-gradle-plugin.
Thanks for the issue. This is an interesting bug. I don't have any immediate ideas how to resolve it -- open to suggestions.
from dependency-analysis-gradle-plugin.
I've found a similar case in my Java multi module library. Example:
subprojects {
ext {
jackson_version = "2.15.2"
}
dependencies {
implementation "com.fasterxml.jackson.core:jackson-databind:${jackson_version}"
}
}
project(":one") {
dependencies {
...
}
}
project(":two") {
dependencies {
implementation project(":one")
...
}
}
and after running ./gradlew buildHealth I get
Advice for :one
Existing dependencies which should be modified to be as indicated:
api 'com.fasterxml.jackson.core:jackson-databind:2.15.2' (was implementation)
Advice for :two
Existing dependencies which should be modified to be as indicated:
api 'com.fasterxml.jackson.core:jackson-databind:2.15.2' (was implementation)
api project(':one') (was implementation)
I don't understand why plugin tries to change implementation to api in such a case. Plugin has no idea about the subsequent usages of the library, so the advice is more harmful than useful, isn't it? 😢 Is it possible to disable such advice (from impl to api) via configuration?
./gradlew one:reason --id com.fasterxml.jackson.core:jackson-databind
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
> Task :one:reason
----------------------------------------
You asked about the dependency 'com.fasterxml.jackson.core:jackson-databind:2.15.2'.
You have been advised to change this dependency to 'api' from 'implementation'.
----------------------------------------
Shortest path from :one to com.fasterxml.jackson.core:jackson-databind:2.15.2 for compileClasspath:
:one
\--- com.fasterxml.jackson.core:jackson-databind:2.15.2
Shortest path from :one to com.fasterxml.jackson.core:jackson-databind:2.15.2 for runtimeClasspath:
:one
\--- com.fasterxml.jackson.core:jackson-databind:2.15.2
Shortest path from :one to com.fasterxml.jackson.core:jackson-databind:2.15.2 for testCompileClasspath:
:one
\--- com.fasterxml.jackson.core:jackson-databind:2.15.2
Shortest path from :one to com.fasterxml.jackson.core:jackson-databind:2.15.2 for testRuntimeClasspath:
:one
\--- com.fasterxml.jackson.core:jackson-databind:2.15.2
Source: main
------------
* Exposes 3 classes: com.fasterxml.jackson.databind.JsonNode, com.fasterxml.jackson.databind.annotation.JsonDeserialize, com.fasterxml.jackson.databind.annotation.JsonSerialize (implie
s api).
* Provides 1 service loader: com.fasterxml.jackson.databind.ObjectMapper (implies runtimeOnly).
Source: test
------------
* Uses 2 classes: com.fasterxml.jackson.databind.ObjectMapper, com.fasterxml.jackson.databind.ObjectWriter (implies testImplementation).
* Provides 1 service loader: com.fasterxml.jackson.databind.ObjectMapper (implies testRuntimeOnly).
from dependency-analysis-gradle-plugin.
If I understand correctly, this behavior happens due to analyze of some compiler-generated classes, for example for lambdas. For test project Kotlin bytecode tool-window shows this:
final class com/github/dependency/analysis/feature/FeatureElementKt$FeatureElement$1 extends kotlin/jvm/internal/Lambda implements kotlin/jvm/functions/Function1 {
/* some bytecode */
// access flags 0x11
public final invoke(Landroidx/compose/foundation/layout/BoxScope;)V
So, may be add some exclusion option like excludeSubClassesOf(@Language("RegExp") vararg regexes: String)
? This way, user can configure plugin to ignore classes which extends kotlin.jvm.internal.Lambda
:
dependencyAnalysis {
abi {
exclusions {
excludeSubClassesOf("kotlin\\.jvm\\.internal\\.Lambda")
}
}
}
from dependency-analysis-gradle-plugin.
Thanks! Not a bad idea. Can you use the existing DSL to add the exclusions you'd need?
from dependency-analysis-gradle-plugin.
Yes, it is possible, but you have to manually add all files where this happens. The easiest way - is to exclude via excludeClasses
and put regex with kt file's name in it. But it increases config size and it is not granual, so you can exclude correct advices.
from dependency-analysis-gradle-plugin.
Related Issues (20)
- Adviced to add transitive which is exposed as Kotlin default value in used lib function HOT 1
- `reason` task only shows used classes if there are no exposed classes HOT 3
- Support coreLibraryDesugaring configuration HOT 1
- Incorrect module structure advice HOT 1
- Add flag to silent the console output for the ProjectHealthTask HOT 2
- Provide modularization advice based on dependency information HOT 1
- JPMS HOT 7
- Annotations used to annotate and things (enum constants, class literals, ...) used for annotation member values should not count to ABI HOT 1
- explodeXmlSourceDebugandroidTest task fails with `Premature end of file` exception when androidTest sources include an xml file with no content HOT 3
- How to change buildHealth task's dependencies HOT 1
- How can I ignore specific flavor & build type? HOT 1
- Unable to load class 'org.jetbrains.kotlin.incremental.IncrementalJvmCompilerRunnerKt'
- CompileOnly false positive with annotations used at runtime HOT 3
- Bug: caching issues for included builds HOT 1
- Kotlin plugin must be loaded in same (or parent) classloader to DAGP: add check and print actionable error message HOT 4
- Lots of false positive under "Unused dependencies" : project doesn't compile anymore when removed HOT 1
- Please add support for TYPESAFE_PROJECT_ACCESSORS HOT 1
- Allow bundles to be configured in DependencyAnalysisSubExtension HOT 1
- Kotlin 2: bug when using associateWith: redeclaring dependencies on child configurations, leading to erroneous advice to remove or change dependencies that don't exist in build scripts HOT 11
- java.lang.NoSuchMethodError: 'com.google.common.collect.ImmutableSet com.google.common.graph.Graphs.reachableNodes(com.google.common.graph.Graph, java.lang.Object)' HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dependency-analysis-gradle-plugin.