I am working with Jetpack Compose and I came across "com.diffplug.spotless" plugin in the app's build.gradle file of many examples, but I am not sure if I need it in my project. Can anyone explain the purpose of using it in the Jetpack compose projects?
''' apply plugin: "com.diffplug.spotless" '''
Spotless: Keep your code spotless with Gradle
While working, Many a times you will get formatting issues at the stage of every commit like removing empty lines, cutting white spaces correct, indentation and other minor formatting mistakes.
Using tool/plugin called “Spotless” will reduce time in addressing code review comments.
Spotless provides support for a variety of languages.
Spotless consists of a list of format and each format has:-
1.a target (the files to format), which you set with target.
2.a list of FormatterStep, which are just String -> String functions, such as replace, replaceRegex, trimTrailingWhitespace, custom, prettier, eclipseWtp, licenseHeader etc.
To start integration with Gradle:-
1.Add the following dependency to your build.gradle file
classpath(“com.diffplug.spotless:spotless-plugin-gradle:$spotlessVersion”)
2.Apply the following plugin
apply plugin: ‘com.diffplug.gradle.spotless’
3.Applying spotless to your gradle file in Android Java source
spotless {
java {
// ...
target '**/*.java'
// ...
}
}
Note:- Be sure to add target '**/*.java' otherwise spotless will not detect Java code
inside Android modules.
For more detail you can refer this link : 1
Related
I stumbled into an issue where all my unit test classes fail to run, providing the following error:
java.lang.IllegalStateException: Failed to transform class with name <my class name>. Reason: toPrettyPrint (Ljava/lang/String;)Ljava/lang/String; in <my class name>: inconsistent stack height -1
One user commented on the following github thread for powermock, that the same error first happened to them after updating their kotlin plugin:
https://github.com/powermock/powermock/issues/779
After reading this, I have checked with my colleagues to see maybe they have a different kotlin version, and saw that their kotlin plugin version is
203.1.6.0-release-798-AS7717.8, whereas mine is 1.4.32-release-Studio4.1-1.
What I find peculiar abbout this, is that these versions dont follow the same conventions, they look more like two completely different sofware. Is there any way for me to get the same version for my kotlin plugin ?
Any help or clarification is much appreciated, thanks!
They probably just changed the naming scheme for the plugin. Looks like you have one that is about one and a half years out of date.
Anyway, go to File -> Settings -> Languages & Frameworks -> Kotlin and click the Install button.
Updated to Android Studio 3.0.0 with new android gradle plugin.
While buildin project got message:
What went wrong:
Execution failed for task `':app:externalNativeBuildDebug'`.
Expected output file at `gst-build-arm64-v8a/libgstreamer_android.so` for target `gstreamer_android` but there was none
but libgstreamer_android.so library file is already there. For native code I use ndk-build. Does anyone have this issue?
Add to build.gradle file of our android module field targets.
android {
defaultConfig {
externalNativeBuild {
ndkBuild {
targets "name_of_native_module_in_android_mk_file"
}
...
}
Don't add gstreamer_android.
UPDATE: Valery's answer works!
Obsolete answer:
That's not the perfect fix, it's just temporary until I have time to take a deep look into the problem. Downgrade your gradle plugin:
File -> Project Structure
Click at "Project"
At "Gradle version" field put:
3.3
At "Android Plugin Version" field put:
2.3.3
Hit "OK"
Accept the messages, sync the project, etc... Android Studio may prompt a windown asking for update gradle plugin again, just don't accept it for now...
I guess the update on gradle changed the way the builds are made, maybe something on Android.mk will have to change or some other parameter on build.grade...
edit: I found some clue at: https://developer.android.com/studio/build/gradle-plugin-3-0-0-migration.html
API changes Android plugin 3.0.0 introduces API changes that removes
certain functionalities and may break your existing builds. Later
versions of the plugin may introduce new public APIs that replace
broken functionalities.
Modifying variant outputs at build time may not work Using the Variant
API to manipulate variant outputs is broken with the new plugin. It
still works for simple tasks, such as changing the APK name during
build time, as shown below:...
So, I guess we should keep using the temporary fix (not updated version of gradle)...
Since upgrading to Gradle 3.3 I'm having trouble building my code due to missing-translation errors:
Error: xxx is not translated in "af" (Afrikaans), "am" (Amharic), "ar" (Arabic), "az" (Azerbaijani), "az-AZ" (Azerbaijani: Azerbaijan), "be" (Belarusian), "bg" (Bulgarian), "ca" (Catalan), [...], "zh-TW" (Chinese: Taiwan), "zu" (Zulu) [MissingTranslation]
The majority of the reported languages are those supported by a 3rd-party module included in my project, and it now seems to define the supported languages for the entire project, giving me this kind of error for all strings that are not translated into above languages. Before upgrading to Gradle 3.3 this was not causing any problems.
I considered the following solutions:
Remove surplus translations from other modules. I want to avoid that because those modules are external and needlessly altering them would really hurt maintainability of my project.
Disable the "incomplete translation" Lint inspection - the most common suggestion for similar questions on SO. This is sub-optimal because I want to be made aware of translations that are missing in my code (working so far). Besides that, disabling the check does not get rid of the error.
Define the supported configurations in build.gradle as described in this answer. I like this option (specifying languages instead of relying on translations available in the modules), but it also does something strange: I'm getting missing-translation errors for strings that are marked translatable = false.
For now, I'm downgrading again to the previous Gradle version. But what is the best apporach for fixing these build errors?
Hoping that there might have been corrections since I posted this question a few months ago, I checked the situation.
It seems that the issues were introduced with the Gradle plugin 2.3.0 and not Gradle 3.3 itself as I suggested in the question. Downgrading the plugin avoids the errors but can hardly be a long-term solution.
I found that option 3 in the question is the best way to handle it: add this to the app's build.gradle:
android {
defaultConfig {
...
resConfigs "en", "fr"
}
}
This is described in Googles documentation and, as mentioned, also in this answer. It removes all unnecessary resources - and the warnings/errors along with them.
Quoting the documentation:
The Gradle resource shrinker removes only resources that are not referenced by your app code, which means it will not remove alternative resources for different device configurations. If necessary, you can use the Android Gradle plugin's resConfigs property to remove alternative resource files that your app does not need.
For example, if you are using a library that includes language
resources (such as AppCompat or Google Play Services), then your APK
includes all translated language strings for the messages in those
libraries whether the rest of your app is translated to the same
languages or not. If you'd like to keep only the languages that your
app officially supports, you can specify those languages using the
resConfig property. Any resources for languages not specified are
removed.
The "false positives" (missing translation error for a non-translatable string) I got were for strings that were defined in more than one module. Renaming the strings or providing translations for them solved the problem. This, too, seems to be introduced with Gradle plugin 2.3.0.
In build.gradle add below code
lintOptions {
disable 'MissingTranslation'
}
I'm trying to name the artifact that gets built by gradle. Look at this build.gradle:
archivesBaseName='this_is_ignored'
apply plugin: 'groovy'
archivesBaseName='this_is_also_ignored'
repositories {
mavenCentral()
}
dependencies {
compile 'org.codehaus.groovy:groovy-all:2.+'
}
I also tried in gradle.properties:
archivesBaseName=`this_is_ignored_too`
In every case ./gradlew build generates a .jar file based on the folder where the project resides (which as I understand it is project.name, I was just hoping to override that with archivesBaseName).
In other words, I want:
~/gradle-helloworld > ./gradlew build
to generate this_is_ignored.jar, but it's generating gradle-helloworld.jar instead.
Any ideas?
(Turning Peter's comment into a CW answer.)
If you set archivesBaseName before applying the plugin, you'll introduce a dynamic property (which gives a deprecation warning). This dynamic property will then shadow the one introduced by the plugin, which is why the second assignment doesn't have the desired effect either. The solution is to only set the property after applying the plugin.
I have IntelliJ 12 and some groovy code (along with a pile of java code) in a project.
In intelliJ, i can see class A's import of some groovy code, and i have also included the library that has that code.
However, while the package itself is in one colour (for the import), the actual class being imported is in red, which implies an issue of some sort. Hovering the mouse over it reveals no issue though.
When i run a "make" or a "rebuild project" is where the problems start - i get
Groovyc: unable to resolve class com.blah.blah.blah.A
How can i resolve this?
Currently, my project setup is like so:
Under "Libraries" in (Project Structure -> Project Settings -> Libraries) I have:
the jar file with all the groovy code
the src jar file with all the groovy code
In the "Modules" section i have the - well, i don't know what to call it, the column isn't labelled - the library name from the libraries section associated with the src and class files, and the little "export" button beside it is ticked.
Incidentally, opening the class in intelliJ never shows the source code, which given the source is included struck me as weird.
Is there anything else I should need to do?
I've worked this one out, but if anybody knows why groovy cannot be in the "Resource Patterns" list and wants an upvote, do chime in
Oh, right.
I removed the !?*.groovy entry from the list of, um, entries in the File : Settings -> Compiler -> Resource Patterns thingy.
It doesn't seem to matter if "use external build" is on or off for this, but the !?*.groovy; entry cannot be there.
I wonder if anybody knows why?
I had the same problem and had to Add Framework Support and add Groovy to the project to get round this problem.
I created the project using gradle.
I just got your question in my Google results as I had a similar issue. My problem was that I was able to get the groovy code in my IntelliJ 12 project to compile ok, but it wasn't getting wired in properly when I tried to run unit tests within the IDE.
After some investigation, I uncovered that groovy and logback libraries were all set up in the project to be available in the runtime stage of the Maven build of the project, but that resulted in them not being available in the test stage. To fix this, I ended up manually updating the groovy-all and the logback libraries scope from runtime to provided under File->Project Structure->Modules->Dependencies. This allowed me to both compile and test within the IDE while including the Groovy modules as well as the Java modules.
Perhaps you had something similar going on in your project?
Six years later, I also just got this question near the top of my search results.
In my project my Unable to load class 'groovy.text.SimpleTemplateEngine' problem was actually due to a codenarc issue. I was able to resolve the issue by adding the following to build.gradle:
// codenarc version issue work-around
configurations.codenarc {
resolutionStrategy.eachDependency { DependencyResolveDetails d ->
if (d.requested.group == 'org.codehaus.groovy') {
d.useVersion '2.4.7'
}
}
}