I was reading the documentation for dependency locking in gradle. I put the following incantation in my deps.gradle file and versions are still sliding around.
dependencyLocking {
lockAllConfigurations()
}
I then noticed the caveat "The above will lock all project configurations, but not the buildscript ones" but I could not find docs that explained the difference.
What is the difference and how can I lock all dependencies?
Note that I'm aware of one other way of locking depenencies that does seem to work, but it seems very verbose so I'd like to avoid it if possible:
implementation('com.github.jnr:jffi') {
version {
strictly '1.2.23'
}
}
lockAllConfigurations()
only makes all of you configurations eligible for dependency locking. It does not automatically lock the dependencies. Otherwise the dynamic version will become useless and you can simply specify the exact version number when adding dependencies.
To actually produce the dependency lock file, you need to pass --write-locks to gradle when running a task, e.g.:
gradle dependencies --write-locks
See this part of the documentation.
Related
I'm working on a SpotBugs plugin (to add extra rules to catch more bugs), and I would like to provide some optional checks that consumers can decide to include or not. Ideally when people add this plugin to their SpotBugs configuration (in their pom.xml file for example), they can add a variable specifying if they want a "full scan", or just a "basic" one.
The idea is somewhat similar to the already existing "effort" configuration, so if there's a way to read that already existing configuration inside my own SpotBugs plugin, that would work too, but I couldn't find one.
The fact that the plugin is not running directly, but it runs as part of SpotBugs makes it more tricky to actually try to define properties directly. And I tried to find that effort but I wasn't successful.
(And most of the information out there is from the point of view of the final consumer and not as a plugin developer)
I have a Gradle (v6.6.1) platform module that I publish to our internal maven repo. It's a constraints-only platform, and intended to be used by a large number of projects in my org so that we can standardize on versions of common dependencies.
So far it's working fine: I periodically review each dependency to look for an updated release, update those versions in my build.gradle.kts file, bump the version number of the platform itself (major or minor, depending on the changes), and publish that new platform to the maven repo.
However, doing so is a time-consuming and manual process. I'd much rather specify my version range constraints in build.gradle.kts (for example, latest patch version, or the latest minor version), and then use dependency locking to update the recommended version to for each dependency to a new specific version.
The problem is, Gradle seems to forbid this. Even when I use the following, it will only produce an empty api.lockfile:
dependencyLocking {
lockAllConfigurations()
}
task("resolveAndLockAll") {
doFirst {
require(gradle.startParameter.isWriteDependencyLocks,
{ "You must specify `--write-locks` to update the dependency version lock" })
configurations["api"].setCanBeResolved(true) // `api` not resolvable by default
}
doLast {
configurations.forEach {
println("Reviewing configuration ${it}...")
if (it.isCanBeResolved && it.name != "archives" && it.name != "default") {
it.resolve()
}
}
}
}
dependencies {
constraints {
api("com.google.guava:guava:${ property("guavaVersion") }")
api("com.google.inject:guice:${ property("guiceVersion") }")
... // many more
}
}
I think I understand the logic behind this: my platform only publishes constraints (not dependencies) so dependency locking doesn't apply. However, I want to specify exact constraints, allowing the consuming projects to jump from release to release of my platform project with exact versions recommended to them.
I also understand that those consuming projects can use dependency locking to get reproducible builds (and they do), but again, I want to specify exact constraints so that everyone on version, say, 17.4 of my platform is using exactly the same dependencies, and they can coordinate on issues they encounter.
Workaround(s)
The best idea I've got is to have a second, private module that defines the same set of dependencies (as actual dependencies) but with broader version ranges (e.g. [1.1, 2.0) instead of 1.4.3). I can use that module to generate a lock file, and then write a script that will update the platform's build.gradle.kts file with the newly-resolved specific dependency versions.
I have a Scala Akka Application which connects to HBase (currently CDP earlier HDP) deployed on rancher; Never faced any trouble when connecting to HDP hbase; Since recent HDP to CDP change, with the same image we are getting no method found on one of the dependency's class in one of the container, where as another container of same image connects to hbase properly.; even though the jar exists in the same image and classpath also.
one of the noticeable difference is change in the order of classpath.
Does change in the classpath order will effect the jars availability.
Does java libraries/classes would load in different order when they would hit a faster CPU cycle at startup.
What could be the reason for such "no class method found".
It certainly can, if the same class file is present in different classpath entries. For example, if your classpath is: java -cp a.jar:b.jar com.foo.App, and:
a.jar:
pkg/SomeClass.class
b.jar:
pkg/SomeClass.class
Then this can happen - usually because one of the jars on your classpath is an older version than the other, or the same but more complicated: one of the jars of your classpath contains a whole heap of different libraries all squished together and one of those components is an older version.
There are some basic hygiene rules to observe:
Don't squish jars together. If you have 500 deps, put 500 entries on your classpath. We have tools to manage this stuff, use them. Don't make striped jars, uber jars, etc.
Use dependency trackers to check if there are version difference in your dependency chain. If your app depends on, say, 'hibernate' and 'jersey', and they both depend on google's guava libraries, but hibernate imports v26 and jersey imports v29, that's problematic. Be aware of it and ensure that you explicitly decide which version ends up making it. Presumably, you'd want to explicitly pick v29 and perhaps check that hibernate also runs on v29*. If it doesn't, you have bigger problems. They are fixable (with modular classloaders), but not easily.
*) Neither hibernate nor jersey actually depend on guava, I'm just using them as hypothetical examples.
For example, if you use maven, check out the enforcer plugin. (groupId: org.apache.maven.plugins, artifactId: maven-enforcer-plugin).
My bet is that there is another version of the jar somewhere in CDP, and occasionally it is loaded before the version that you ship with your project, causing the error.
So, when your container starts, try logging from which location the conflicting class is loaded. This question might help you: Determine which JAR file a class is from
When using Firebase Performance in Android Studio the gradle task app:transformClassesWithFirebasePerformancePluginForDebug is taking significantly longer than any other task and is therefore dramatically slowing down my gradle build times.
Slow Build shown in Profiler
Firebase in our project caused 40% build time increase. To speed up debug builds we added a possibility to switch it on/off using build parameters in app/build.gradle and root build.gradle files:
app:
if (!project.hasProperty("disable-performance-plugin")) {
apply plugin: 'com.google.firebase.firebase-perf'
}
root/buildscript/dependencies:
if (!project.hasProperty("disable-performance-plugin")) {
classpath('com.google.firebase:firebase-plugins:1.1.5') {
exclude group: 'com.google.guava', module: 'guava-jdk5'
}
}
when running from the command line use
./gradlew your-task -Pdisable-performance-plugin
when working from Android Studio, add the flag to compiler options:
All of the existing answers are valid, but they all miss something.
To deal with this issue, you have 2 major options to choose from.
1. Use firebasePerformanceInstrumentationEnabled property
This is the official way provided by the SDK itself to disable it during the build process.
What this does:
Reduces transformClassesWithFirebasePerformancePluginFor* task execution time to ~5-10s.
Disables automatic traces and request monitoring, but leaves custom traces enabled. You can control the latter with AndroidManifest <meta-data> tags and calls to FirebasePerformance.getInstance().setPerformanceCollectionEnabled(). More info in the docs.
How to do this:
I think it's much easier to only enable plugin in those rare cases when we need it (usually it will be only when we publish the app) rather than disable it in all other cases.
Note: Of course, with manual builds you might forget to enable it. So if you don't have CI, it might be worth adding some other automatic scripting in Gradle, or sticking to the opposite approach that is used in other answers.
In general though, we only need two steps:
Add the following line to gradle.properties file:
firebasePerformanceInstrumentationEnabled=false
Use the following command in your CI config or manual builds:
./gradlew assembleRelease -PfirebasePerformanceInstrumentationEnabled=true
Pros:
Only one property to set up.
Cons:
Plugin still adds additional ~5-15s to the build time.
2. Use custom Gradle project property to avoid applying firebase-perf Gradle plugin
What this does:
transformClassesWithFirebasePerformancePluginFor* task is not executed at all. Also we save some additional ~5–10s overhead that is present when using the first solution.
Same as the first method – disables automatic traces and request monitoring, but leaves custom traces enabled. You can control the latter with AndroidManifest <meta-data> tags and calls to FirebasePerformance.getInstance().setPerformanceCollectionEnabled(). More info in the docs.
How to do this:
This approach has similar points and warnings, and also includes two steps:
Modify your app module's build.gradle file:
if (project.hasProperty('useFirebasePerf')) {
apply plugin: 'com.google.firebase.firebase-perf'
}
Note: you don't need to apply the same check to your project-level build.gradle:
classpath "com.google.firebase:firebase-plugins:$firebase_plugins_version"
This declaration won't be used in any way by Gradle when the plugin itself is not enabled.
And you don't need to exclude guava-jdk5 dependency there, if you're using firebase-plugins v1.1.1 or later as stated in the docs.
Use the following command in your CI config or manual builds:
./gradlew assembleRelease -PuseFirebasePerf
Pros:
Completely eliminates time expenses associated with Firebase Performance Gradle plugin.
Cons:
Introduces conditional check for applying plugin in your Gradle script, some might argue that it's not an idiomatic approach.
* (Bonus option) Use custom Gradle project property to exclude firebase-perf SDK
If you don't use custom traces or any other features from Firebase Performance SDK and only rely on automatic monitoring (that is, you don't have any dependencies on SDK in your code), then you can exclude this dependency for non-production builds.
How to do this:
All you need to do is update your app module's build.gradle file:
If you chose to use the first option, then change your dependency like this:
if (project.property('firebasePerformanceInstrumentationEnabled') == 'true') {
implementation "com.google.firebase:firebase-perf:${firebase_perf_version}"
}
If you chose the second one:
if (project.hasProperty('useFirebasePerf')) {
implementation "com.google.firebase:firebase-perf:${firebase_perf_version}"
}
Advantage:
This might save you some additional ~5-10s, spent on configuring dependency and
"ProGuarding" it.
Drawbacks:
Your production APK size will be larger than debug one by ~0.5mb. This might disrupt your reports or predictions, so you need to be aware of it.
If you were close to surpassing 64K method count limit, you might suddenly step over it on production builds and find yourself in the MultiDex zone. And that means extra work to do and tests to run. All because Firebase Performance brings a formidable number of almost 5K method references (after applying ProGuard with optimizations).
You can also check out my article where I expand a bit more on this topic.
Firebase Performance has released a new version of perf-plugin (v1.3.0). This would enable disabling the Firebase Performance Monitoring Gradle plugin for a specific build variant (including buildTypes or productFlavors).
An example below:
android {
// ...
debug {
FirebasePerformance {
// Set this flag to 'false' to disable #AddTrace annotation processing and
// automatic HTTP/S network request monitoring
// for a specific build variant at compile time.
instrumentationEnabled false
}
}
}
Reference to release notes:
https://firebase.google.com/support/release-notes/android#2019-07-10
All comments in this thread are valid. I want to suggest a very simple way to disable that for debug builds:
if (getGradle().getStartParameter().getTaskRequests().toString().contains("Release")) {
apply plugin: 'com.google.firebase.firebase-perf'
}
For newer versions of the Firebase perf plugin (1.3.0 and up) with Kotlin DSL you'll need to add the following:
android {
...
buildTypes {
...
all {
with((this as ExtensionAware).extensions["FirebasePerformance"] as FirebasePerfExtension) {
setInstrumentationEnabled(!isDebuggable)
}
}
...
}
}
For the Groovy version you can check out the Firebase documentation.
Just to give another option to disable transformClassesWithFirebasePerformancePluginForDebug, here's my recipe:
In main build.gradle folder:
if (!project.gradle.startParameter.taskNames.any { taskName ->
taskName.toLowerCase().contains('assemble') && taskName.toLowerCase().contains('debug') }) {
classpath("com.google.firebase:firebase-plugins:$firebasePluginVersion") {
exclude group: 'com.google.guava', module: 'guava-jdk5'
}
}
In the build.gradle app file:
if (!project.gradle.startParameter.taskNames.any { taskName ->
taskName.toLowerCase().contains('assemble') && taskName.toLowerCase().contains('debug') }) {
apply plugin: 'com.google.firebase.firebase-perf'
}
I ran into this problem as well. Originally we had been using a variant of the answer provided by R. Zagórski, but based on a similar thread from the Gradle forums it seems like conditionally applying a plugin to a project isn't the right way to go:
Plugins can’t be applied to only “part of your project”. They are either applied or not.
Conditionally applying plugins does seem to work if you can do it right, but it's not an officially supported feature. Further down the same thread, another point is made:
But the plugin should allow you to configure it at a finer grained level.
Sure enough, there actually is a property exposed by the Firebase plugin that lets you toggle instrumentation on or off (therefore toggling the increased build time). Using this property is tricky, though, since you have to apply it at exactly the right time during the building process, but once you've got that then you can essentially pivot it on whatever you want.
The following code snippet is how we're pivoting instrumentation based on Debug vs. Non-Debug build variants. It's written in Kotlin, but I imagine it would translate to Groovy just as well:
plugins {
...
id ("com.google.firebase.firebase-perf")
}
...
android {
...
applicationVariants.all {
val variant = this
val isFirebaseEnabled = !variant.javaCompiler.name.contains("Debug", true)
gradle.taskGraph.whenReady {
if (this.hasTask(variant.javaCompiler))
{
project.FirebasePerformance.isInstrumentationEnabled = isFirebaseEnabled
}
}
}
...
}
Note that with this in place, the transformClassesWithFirebasePerformancePluginFor* task will still always run for every build variant, but it will complete almost immediately for a variant that doesn't have instrumentation enabled.
I think the clearest way is this with kotlin DSL gradle 👇
in app level build.gradle
buildTypes {
getByName(BuildType.DEBUG) {
extensions.configure<com.google.firebase.perf.plugin.FirebasePerfExtension>{
setInstrumentationEnabled(false)
}
}
}
in dependendencies part:
dependencies {
releaseImplementation(Dependencies.FIREBASE_PERFORMANCE) //implementation for only release mode (you can vary for other variants)
}
I have simplified option 2 of this answer https://stackoverflow.com/a/53270530/1635488
Define a property in gradle.properties
useFirebasePerf=false
Disable perf plugin
if (useFirebasePerf.toBoolean()) {
apply plugin: 'com.google.firebase.firebase-perf'
}
Remove dependency
if (useFirebasePerf.toBoolean()) {
implementation 'com.google.firebase:firebase-perf:16.2.3'
}
Enable Performance Monitoring only for CI builds (i would recommend only for release builds)
gradlew assembleRelease -PuseFirebasePerf=true
A much cleaner way in kotlin DSL
buildTypes {
//My custom extension
forName("debug") {
roject.ext.set("firebasePerformanceInstrumentationEnabled", "false")
}
}
Implementation of forName
fun <T> NamedDomainObjectContainer<T>.forName(name: String, action: T.() -> Unit) {
this.maybeCreate(name)
this.getByName(name, object: Action<T>{
override fun execute(t: T) {
t.action()
}
})
}
For reasons I don't even want to begin to get into.. I have a maven hierarchy that looks like the one below. In a nutshell, everything requires commonslang3, except one ancient artifact that requires commonslang2.
We have no issues with compile or runtime, the dependencies work as expected. The challenge we are having is at development time.
We'd like to ensure everyone on the team uses the commonslang3 APIs, but occasionally (because of the ancient artifact and Eclipse auto suggest), someone accidentally uses the commonslang2 APIs.
Normally, we would just force the desired version in our POM, but commonslang is a special snowflake. The package signature changed between comonslang2 and commonslang3, which means we would have compile failures if we excluded the older library. E.g.,
org.apache.commons.lang3.StringUtils
org.apache.commons.lang.StringUtils
My question is this, how can I configure maven/Eclipse, to use commonlang2 as needed during compile... but not populate it in the Eclipse class autosuggest list? My desired end state is that someone types 'stringuti' + ctrl + space, and the only option they see is commonslang3. I am aware that each developer can remove individual classes via (Window->Preferences->Java->Appearance->Type Filters) but that is not a viable solution for two reasons: 1) It's a large team with frequently changing resources... 2) I need an entire artifact removed, as in hundreds of classes.
Example Tree:
MyWar
-- MyModuleJar1
-- ...
-- MyModuleJar2
-- LibA
-- commonslang
-- ...
-- LibB
-- commonslang3
-- ...
-- LibC
-- commonslang3
-- ...
-- ...
In Eclipse:
Window->Preferences->Java->Appearance->Type Filters
Add org.apache.commons.lang.*
Because you want to affect auto-complete which is a function of the IDE, you are forced to change the setting in the IDE. You can export the preferences and share them of the rest of the team.
There is not much you can do about it in Eclipse other than type filters #JustinKSU mentioned.
But with Maven you can use Takari to access rules to prevent accidental inclusion of transitive dependencies. Of course this comes with a plethora of caveats with one ironically being that the Eclipse JDT compiler has to be used instead of plain javac.