Consider shading the JGit dependency in Grade plugin
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- java
- Domain
- build-system
Research direction
Start by reproducing the conflict with Spotless 4.0.1, GitPublish, and the Scala scalafmt configuration shown, then inspect the Gradle plugin's JGit dependency setup. Compare the result with Gradle's guidance on minimizing external plugin dependencies. Done means GitPublish and Spotless can coexist without the reported generic class-linkage errors from incompatible JGit versions.
Written by the indexing model from the issue text.
Description
Summary
In Gradle, all plugins share the same classpath. This makes it very hard, if not impossible, to use plugins which depend on different incompatible versions of the same library. This is the case with Spotless and GitPublish:
- Spotless depends on 5.7.0.202003110725-r
- GitPublish depends on the "latest release" version, which for the latest version of the plugin itself is 5.6.0.201912101111-r
Downgrading the JGit dependency in Spotless, I believe, is not an option, but maybe you could consider shading this dependency, building it into the Gradle plugin JAR file? I believe that the official Gradle guidelines recommend minimizing the number of external dependencies, and shading is one of the ways to mitigate issues like this one.
Gradle version
Happens with any Gradle version, including the latest one, 6.4.1
Spotless version
4.0.1
Operating system and version
Probably not relevant, but macOS 10.15.3
Spotless configuration
Having something as simple as
spotless {
scala {
scalafmt("2.3.2").configFile(layout.projectDirectory.file(".scalafmt.conf"))
}
}
in the build configuration will reproduce the issue,.
Console errors
In all my test cases any Spotless tasks don't cause errors; exceptions can be observed when the GitPublish plugin is used, and they are generic class linkage errors which happen when binary incompatible libraries with the same class names are present in the one classpath.
- Dominant language
- Java
- Stars
- 5.7k
- Forks
- 560
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 43
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from diffplug/spotless
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Difficulty 3/5 1-2 days Newbie friendliness 66/100
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
All issues in diffplug/spotless
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
checkstyle/test-configs#263 ·
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
apache/cloudstack#14222 ·
-
[BUG]茶杯方块在取茶时会引发崩溃 Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
1.0.0-alpha2 Type/Improvement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
wso2/dpdp-accelerator#272 ·