I’m currently migrating our custom gradle plugins, tasks and projects to milestone-8a. While I read and understand the migration guide, I keep getting deprecation warnings like:
10:19:05.380 [WARN] [org.gradle.util.DeprecationLogger] The SourceSet.getClassesDir() method has been deprecated and
will be removed in the next version of Gradle. Please use the getOutput().getClassesDir() method instead.
10:19:05.391 [WARN] [org.gradle.util.DeprecationLogger] The reportsDir property has been deprecated and will be removed in the next version of Gradle. Please use the reporting.baseDir property instead.
My question is: is there a way of finding out exactly where these deprecated APIs are used? I searched our code over and over again but can’t seem to find any places where the classesDir and reportsDir properties are used.
It would be awesome if we had an option like --deprecation which, if present, would output something like a stacktrace allowing us to migrate our code and getting rid of deprecated Gradle APIs by pinpointing the places where they’re used.
Thanks a LOT, this is exactly what I meant and needed! You really should make this (or something similar) official, it’s very helpful for plugin / task developers.
Turned out my deprecation warnings come from the cobertura plugin I’m using.
I have the same deprecation message “The reportsDir property has been deprecated and is scheduled to be removed in Gradle 2.0. Please use the reporting.baseDir property instead.”
It seems I am not the only one having this problem, after having searched the internet, but there is no fix proposed.
I really do not know where this property is coming from… I do not use it so far, impossible to find it in my code.
Any idea how to fix this deprecation ?
Thanks,
Jean-Pierre
[17:08:56][Step 1/2] :makePom (3s)
[17:08:59][:makePom] The reportsDir property has been deprecated and is scheduled to be removed in Gradle 2.0. Please use the reporting.baseDir property instead.
[17:08:59][:makePom] org.gradle.util.SingleMessageLogger.logTraceIfNecessary(SingleMessageLogger.java:183)
[17:08:59][:makePom] org.gradle.util.SingleMessageLogger.nagUserWith(SingleMessageLogger.java:140)
[17:08:59][:makePom] org.gradle.util.SingleMessageLogger.nagUserOfReplacedProperty(SingleMessageLogger.java:108)
[17:08:59][:makePom] org.gradle.api.plugins.ReportingBasePluginConvention.getReportsDir(ReportingBasePluginConvention.java:85)
[17:08:59][:makePom] org.gradle.api.internal.BeanDynamicObject$MetaClassAdapter.getProperties(BeanDynamicObject.java:221)
[17:08:59][:makePom] org.gradle.api.internal.BeanDynamicObject.getProperties(BeanDynamicObject.java:124)
[17:08:59][:makePom] org.gradle.api.internal.plugins.DefaultConvention$ExtensionsDynamicObject.getProperties(DefaultConvention.java:175)
[17:08:59][:makePom] org.gradle.api.internal.CompositeDynamicObject.getProperties(CompositeDynamicObject.java:127)
[17:08:59][:makePom] org.gradle.groovy.scripts.BasicScript.getProperties(BasicScript.java:75)
[17:08:59][:makePom] makeParentDescriptor_4plf5b5mjieq2gh9ct45mht6t8$_run_closure1.doCall(/local/toolsnms/ingress/git_localnms/public/build/generic/makeParentDescriptor.gradle:30)
Peter, my understanding is that the deprecation trace is working for him, but that he still can’t find the claimed usage of the reportsDir property in the source at the location the trace is pointing at.
Yes, I found the offending piece of code back then. But in my case, the trace pinpointed an obvious use of the property. In your case, I can’t see anything obvious neither.
I see. Looks like a generic ‘getProperties()’ call triggers a deprecated property. There are plans to improve on this (i.e. a generic ‘getProperties()’ call should not trigger deprecated properties).
Basically, if the JVM system property ‘org.gradle.deprecation.trace’ is true while Gradle is running, it will print a stacktrace when a deprecated item is hit.
We are working on making this more user friendly. The above mechanism may stop working at some point in time, when we replace it with something better.