how to dump all gradle values used for build - groovy

we have a multi-project gradle build in android studio. every now and then we have to change something in it, and usually its only 1 or two lines of code, but its never easy knowing where to put those. I find it quite hard to know which properties exist where so I would love to have something like dump-everything where I could see all properties and their children at the point in time, this would make changes much easier
I have found this
def void explainMe(it){
//println "Examining $it.name:"
println "Meta:"
println it.metaClass.metaMethods*.name.sort().unique()
println "Methods:"
println it.metaClass.methods*.name.sort().unique()
println "Depends On:"
//println it.dependsOn.collect({it*.getName()})
println "Properties:"
println it.properties.entrySet()*.toString()
.sort().toString().replaceAll(", ","\n")
}
which is OK, but I would like to call it on top level scope and for all its children recursively, and in best case store output to file to be able to search through it. any idea would be appreciated? alternatively would it be possible to attach debugger to gradle build and inspect /watch variables inside?
thanks

Gradle has very specific support for inspecting certain parts of the build model (gradle tasks, gradle help --task taskName, gradle properties, gradle projects, gradle dependencies, gradle dependencyInsight, etc.), but doesn't currently have a generic feature for deep inspection of arbitrary build model properties and their values. Instead one would typically add some printlns to the build script and/or consult the Gradle Build Language Reference.
To answer your second question, a Gradle build can be debugged in the same way as any other external application. The necessary JVM args (typically provided by the debugger) can be set via the JAVA_OPTS or GRADLE_OPTS environment variable. It's probably best to execute Gradle with --no-daemon when debugging.

Related

How to convert picocli groovy-grape script to native standalone app?

I have a made my first groovy CLI app with picocli. Now, I want it to be available for use without any JVM installed on the client machine, maybe with the use of GraalVM.
This is for an opensource project:
https://github.com/kchaitanya863/db2csv
Another easy option is to dockerize your script (read this blog about how to do it https://groovy-lang.gitlab.io/101-scripts/docker/basico-en.html)
If you want to build a linux executable you need to change your project:
convert to a gradle project (maven is also an option but gradle has a lot of plugins)
change your script to a class with a tipical main (and move it to the standard directory src/main/groovy/mypackage)
add some tasks into you build.gradle similar to these https://gitlab.com/snippets/1797638
You will need to:
statically compile your groovy script
make the args variable available after static compilation with
final String[] args = getProperty("args") as String[]
specify a reflection configuration file for the classes dynamically loaded/invoked using reflection by Groovy (this may be useful)
specify a reflection configuration file for the classes loaded/invoked using reflection by picocli. The picocli-codegen module provides a picocli.codegen.aot.graalvm.ReflectionConfigGenerator tool to generate the configuration file.
If your script has any #Grape dependencies, you may need to turn off the Grape dependency manager with -Dgroovy.grape.enabled=false and add all dependencies to the classpath manually instead
Credit: I got most of these tips from this article by Szymon Stepniak
If you want to use Graal with Groovy, check out this article:
https://e.printstacktrace.blog/graalvm-and-groovy-how-to-start/

Gradle finished with non-zero exit value 1 (ic_launcher.png: error: Duplicate file)

I got this strange error with gradle, please help me!
/.../app/build/intermediates/res/debug/drawable-xxhdpi-v4/ic_launcher.png:
error: Duplicate file
/.../app/build/intermediates/res/debug/drawable-xxhdpi/ic_launcher.png:
Original is here. The version qualifier may be implied.
Error:Execution failed for task ':app:processDebugResources'.
com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException:
Process 'command '/.../sdk/build-tools/22.0.1/aapt'' finished with non-zero exit value 1
Before it was operating normally, but since I put classpath com.android.tools.build:gradle:1.2.2, this causes me errors
According to Xavier Durochet's explanation on G+, it's due to one of the libraries you use having it's own ic_launcher.png -- which they of course should not (more on that at the bottom).
Chances are the two icons mentioned in the log are different: one is yours and another one is most likely the generic android icon that someone forgot to remove from the library.
To see the offending dependency, hit Ctrl + Shift + N twice (for non-project matching) and type in ic_launcher.png (See the last line on the screenshot)
To work around the issue temporarily, add the -v4 qualifier to your drawable resouce folders (or move just ic_launcher.png to *dpi-v4 if you have your reasons) -- credits to Xavier Durochet for the solution. You can also just rename your icon into something else and make corresponding change to AndroidManifest.xml
The real issue is that the offending lib carries the useless icons. Libraries that have their own resources (like ActionBarSherlock or Google's own Support v7 library) use distinctive naming schemes to avoid collisions with your resource names (abs_, abc_).
Launcher icons have no business being in a library so I encourage you to notify the author of the lib you're using that they forgot to remove the redundant ic_launcher.png files.
Also worth mentioning, as Barry Carroll noted very precisely in the same discussion, this doesn't mean your resources should never overlap those in the library: there are a lot of legit reasons to override a lib's resources with your own (e.g. changing the looks of a library-provided activity) and gradle plugin's resource merging logic does allow this, on purpose.
It's just that in this particular case, the conflict occurs when the lib is behind on the android gradle plugin version (pre-1.2.2) in which case resources end up in two different *dpi folders -- with and without the -v4 qualifier; but they're actually in the same resource "bucket" so the system considers them to be duplicate.
This glitch does bring out the useless ic_launcher.png override (actually, a collision -- due to the glitch) but this situation is not universally bad for other kinds of resources.
I.e. sometimes you intentionally override a lib's resource and this glitch will still cause the error message to pop. This time there's no real problem with resource names, so the temporary solution above or holding back the plugin version are the way to go.
I had the same problem while using a third party library.(RomainPiel/Shimmer-android library on Github)
To solve it, I moved my ic_launcher.png files from drawable folder to mipmap folder. And problem solved.
Downgrading to com.android.tools.build:gradle:1.1.3 sloved my issue
Here is the general method to find the problem:
Run
./gradlew build --stacktrace --info
and You will find the details of errors.
I found my error : a duplicate class caused a TOP-Level error, and remove the duplicated one will solve the problem.
For me a simple "clean project" and "rebuild project" did the trick.
Upgrade to 1.2.3, but ensure that your gradle and buildToolsVersion are identically in your project and the used aars.
In case you use external libs where you can't control the gradle/build version:
Contact the author or check the sources by your own. Some libraries have unused launcher icons which will cause this conflict. Removing this icons will solve your problem. Identically named sources (e.g menu.xml) could also cause this issue in rare cases. An easy workaround would be to rename your ressource.
Just rename ic_launcher.png to something else (e.g ico_launcher.png)
In my case I have added apostrophe s ('s) to strings.xml file.
Do check guys for any such error and remove it will definitely help.
It's so annoying the IDE can't show the error properly rather makes all resources out of sync..
I know it's not the case which is asked in Question but error is quite same i.e. Gradle execution gets failed.
Simply Rename the Image (Rightclick on the Image, Select Refactor and select Rename). It will solve the issue as the Issue has arise as one of the library is also using the image with the same name.
I had the same problem and what follows worked for me:
rename your icon
add tools:replace="android:icon" to your <application> tag in the Manifest
You can try just the first step, but I still had problems when merging the manifest files. This way it should override whatever resource was used in the library.
Follow this link Here
Or
Make change like this.
repositories {
maven {url "https://clojars.org/repo/"}
}
dependencies {
compile 'frankiesardo:icepick:{{latest-version}}'
**provided** 'frankiesardo:icepick-processor:{{latest-version}}'
}
Update to newest gradle plugin 1.5.0 sloved this issue. Update following script in your root build.gradle file
buildscript {
...
dependencies {
classpath 'com.android.tools.build:gradle:1.5.0'
}
...
}
I managed to trigger this problem by inconsistent capitalisation of filename extensions. I had a .jpg image in one drawable directory, but an image of the same filename but .JPG in a different drawable directory. The filenames and directories were right, but the extensions weren't.

Deploying multiple build variants at a time - Android studio gradle

I recently discovered this awesome feature about gradle productFlavors. I currently have 3 variants (staging, sandbox and production) and I can deploy one of the variants at a time using build variant panel.
Is there a way I can deploy all variants at a time?
Yes,
In Android Studio, open the "Gradle Tasks" tab, which is usually on the right. You will see many tasks that start with 'assemble', double click on one of those.
For example, double clicking on 'assembleRelease' will create all your release apks.
From the docs:
Building and Tasks
We previously saw that each Build Type creates its own assemble
task, but that Build Variants are a combination of Build Type and
Product Flavor.
When Product Flavors are used, more assemble-type tasks are created.
These are:
1) assemble[Variant Name]
2) assemble[Build Type Name]
3) assemble[Product Flavor Name]
1) allows directly building a single variant. For instance
assembleFlavor1Debug.
2) allows building all APKs for a given Build Type. For instance
assembleDebug will build both Flavor1Debug and Flavor2Debug variants.
3) allows building all APKs for a given flavor. For instance
assembleFlavor1 will build both Flavor1Debug and Flavor1Release
variants.
The task assemble will build all possible variants.
If you know the names of the gradle tasks that install your variants you can run this from the root of your project in the terminal:
./gradlew install{VariantName1, VariantName2, VariantName3}Debug
This assumes you have a module build.gradle file with variants set up according to the guide. So something along these lines:
apply plugin: 'com.android.application'
android {
...
flavorDimensions "myFlavorDimension"
productFlavors {
VariantName1 {
...
}
VariantName2 {
...
}
VariantName3 {
...
}
}
...
}
dependencies {
...
}
You can find these gradle task names either in Android Studio in the Gradle Tab (right side of GUI) under you moduleName->Tasks->install
Or you can find them in the terminal with:
./gradlew tasks | grep install
I'm sure there is some Regex that could grab only the ones of interest programmatically as well, but I'm not a regex buff. If you want to leave a comment with something that would work, I'd be happy to edit and add later.

Cucumber/gradle example not generating report?

I'm investigating using gradle and cucumber together, and found this lovely example in cucumber's github.
So, I cloned the repository and ran it myself. It failed, as it's configured to do, but I couldn't find the HTML or JSON report that it appears to be configured to output. I say appear because I'm brand new to cucumber, but this class would seem to indicate where it'll put it:
#RunWith(Cucumber.class)
#Cucumber.Options(format = {"pretty", "html:build/cucumber-html-report", "json-pretty:build/cucumber-report.json"})
public class RunCukesTest {
}
However, it's not appearing in the build directory after running gradle cucumber.There's no cucumber-html-report directory, not is there a cucumber-report.json file. I'm running it with Java 7 and Gradle 1.6, if it matters.
Ideas? Is this a known issue with the Cucumber/Gradle integration?
The class name changed depending on the version of Cucumber you are using. It changed from json-pretty to json.
When running the 'cucumber' task on this example the generated cucumber report is located at 'build/cucumber-html-report/index.html'. Running the 'test' task fails as it seems that gradle has problems to create the test report for the cucumber created tests (file name contains spaces) I need to dig a bit into this to see how this can be fixed in gradle.
cheers,
René
The cucumber-jvm-example doesn't do reporting using gradle cucumber, but does do it with gradle test. However, gradle test will have a couple issues, namely showing a "null" test of sorts.
A workaround to this, if need be, is to add the formats to the args of the javaexec that runs cucumber. For example, in build.gradle:
javaexec {
main = "cucumber.api.cli.Main"
classpath = configurations.cucumberRuntime + sourceSets.main.output + sourceSets.test.output
args = ['--format', 'html:cucumber-html-report', '-f', 'pretty', '--glue', 'gradle.cucumber', 'src/test/resources']
}
I had an error with that very same line (taken from this tutorial).
In order to resolve, had to change the third parameter from "json-pretty" to just "pretty"
So this is my final code line:
#CucumberOptions(format = {"pretty", "html:target/cucumber-html-report", "pretty:target/cucumber-report.json"})
BTW,
#Cucumber.Options is deprecated, we should use CucumberOptions

Groovy and IntelliJ - getting code compiled

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'
}
}
}

Resources