I am working on an app that uses appengine as its backend. I would like to download the backend server side code for my app using gradle's command line.
I type gradlew appengineDownloadApp at the command prompt and this is what I get
FAILURE: Build failed with an exception.
What went wrong:
A problem was found with the configuration of task ':app_server:appengineDownloadApp'.
No value has been specified for property 'appId'.
Where do I enter the appId? I am assuming this is the project id from my appengine account but I am unsure where to stick this value for gradle to read it.
I have been looking for the answer and finally ended up on https://github.com/GoogleCloudPlatform/gradle-appengine-plugin#convention-properties page:
The task appengineDownloadApp requires you to at least define the application ID and directory to write the files to. Define the tasks properties in the closure app:
- id: The application ID.
- version: The current application version (defaults to current default version).
- outputDirectory: The directory where you wish to save the files (defaults to build/downloaded-app).
So the property "appId" in error message is a bit misleading... As described in plugin README, you only need to add to build.gradle:
appengine {
app {
id = 'your-app-id'
}
}
Related
I have a project that uses bazel and includes a demo Android app to show some functionality and widgets. I wanted to split this out as the base for a new demo/experimentation app to try out other widget combinations. So I copied the WORKSPACE file and the code from the demo app package into a new project (the package names changed but I modified the code and BUILD files to account for this). The original project builds just fine, but the new one consistently fails with the following error:
ERROR: D:/_bazel_out/s6wwoqrr/external/maven_android_everything/BUILD:568:11: Compiling Android resources for #maven_android_everything//:com
_google_android_material_material failed: (Exit 1): ResourceProcessorBusyBox.exe failed: error executing command bazel-out\x64_windows-opt-ex
ec-2B5CBBC6\bin\external\bazel_tools\src\tools\android\java\com\google\devtools\build\android\ResourceProcessorBusyBox.exe ... (remaining 1 a
rgument skipped)
Jul 29, 2022 3:04:29 PM java.util.stream.ForEachOps$ForEachOp$OfRef accept
SEVERE: Error during Compiling bazel-out\android-armeabi-v7a-fastbuild\bin\external\maven_android_everything\_aar\unzipped\resources\com_goog
le_android_material_material\res\animator\mtrl_extended_fab_change_size_collapse_motion_spec.xml:
Command: external\androidsdk\build-tools\33.0.0\aapt2.exe\
compile\
-v\
--legacy\
-o\
C:\Users\bdlei\AppData\Local\Temp\android_resources_tmp3839340977225638696\compiled\bazel-out\android-armeabi-v7a-fastbuild\bin\exter
nal\maven_android_everything\_aar\unzipped\resources\com_google_android_material_material\res\
bazel-out\android-armeabi-v7a-fastbuild\bin\external\maven_android_everything\_aar\unzipped\resources\com_google_android_material_mat
erial\res\animator\mtrl_extended_fab_change_size_collapse_motion_spec.xml
Output:
bazel-out\android-armeabi-v7a-fastbuild\bin\external\maven_android_everything\_aar\unzipped\resources\com_google_android_material_material\re
s\animator\mtrl_extended_fab_change_size_collapse_motion_spec.xml: error: file not found.
Exception in thread "main" com.google.devtools.build.android.aapt2.ResourceCompiler$CompileError
at com.google.devtools.build.android.aapt2.ResourceCompiler$CompileError.of(ResourceCompiler.java:111)
at com.google.devtools.build.android.aapt2.ResourceCompiler$CompilingVisitor.getCompiledArtifacts(ResourceCompiler.java:431)
at com.google.devtools.build.android.aapt2.ResourceCompiler.getCompiledArtifacts(ResourceCompiler.java:465)
at com.google.devtools.build.android.UnvalidatedAndroidData.compile(UnvalidatedAndroidData.java:103)
at com.google.devtools.build.android.CompileLibraryResourcesAction.main(CompileLibraryResourcesAction.java:143)
at com.google.devtools.build.android.ResourceProcessorBusyBox$Tool$6.call(ResourceProcessorBusyBox.java:99)
at com.google.devtools.build.android.ResourceProcessorBusyBox.processRequest(ResourceProcessorBusyBox.java:234)
at com.google.devtools.build.android.ResourceProcessorBusyBox.main(ResourceProcessorBusyBox.java:177)
Suppressed: java.lang.RuntimeException: Error during Compiling bazel-out\android-armeabi-v7a-fastbuild\bin\external\maven_android_eve
rything\_aar\unzipped\resources\com_google_android_material_material\res\animator\mtrl_extended_fab_change_size_collapse_motion_spec.xml:
Command: external\androidsdk\build-tools\33.0.0\aapt2.exe\
compile\
-v\
--legacy\
-o\
C:\Users\bdlei\AppData\Local\Temp\android_resources_tmp3839340977225638696\compiled\bazel-out\android-armeabi-v7a-fastbuild\bin\exter
nal\maven_android_everything\_aar\unzipped\resources\com_google_android_material_material\res\
bazel-out\android-armeabi-v7a-fastbuild\bin\external\maven_android_everything\_aar\unzipped\resources\com_google_android_material_mat
erial\res\animator\mtrl_extended_fab_change_size_collapse_motion_spec.xml
Output:
bazel-out\android-armeabi-v7a-fastbuild\bin\external\maven_android_everything\_aar\unzipped\resources\com_google_android_material_material\re
s\animator\mtrl_extended_fab_change_size_collapse_motion_spec.xml: error: file not found.
at com.google.devtools.build.android.CommandHelper.execute(CommandHelper.java:42)
at com.google.devtools.build.android.AaptCommandBuilder.execute(AaptCommandBuilder.java:297)
at com.google.devtools.build.android.aapt2.ResourceCompiler$CompileTask.compile(ResourceCompiler.java:234)
at com.google.devtools.build.android.aapt2.ResourceCompiler$CompileTask.call(ResourceCompiler.java:178)
at com.google.devtools.build.android.aapt2.ResourceCompiler$CompileTask.call(ResourceCompiler.java:125)
at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListe
nableFutureTask.java:125)
at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:69)
at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
INFO: Elapsed time: 335.194s, Critical Path: 145.75s
INFO: 1568 processes: 74 internal, 1308 local, 186 worker.
FAILED: Build did NOT complete successfully
The referenced file: bazel-out\android-armeabi-v7a-fastbuild\bin\external\maven_android_everything\_aar\unzipped\resources\com_google_android_material_mat erial\res\animator\mtrl_extended_fab_change_size_collapse_motion_spec.xml does exist under the bazel-out directory of my project, but after the build failure, the temp directory C:\Users\bdlei\AppData\Local\Temp\android_resources_tmp3839340977225638696 does not exist. I had an explorer window open to my AppData\Local\Temp directory last time I tried building and many such android_resources_temp... came and went during the build (which I expected). I removed older ones before trying the build again and while I wasn't able to track if the one named in the error ever existed, it does not exist afterwards (exactly one of these was left after the build failure).
The behavior is consistent: the original project consistently succeeds and the branched out fails. This persists through bazel clean, bazel sync, and bazel shutdown calls.
Both projects are depending on android via a call into a 3rd "dependencies" project that creates a maven repo and builds a repo out of that:
def android():
if 'maven_android_everything' not in native.existing_rules():
maven_install(
name = "maven_android_everything",
artifacts = [
"androidx.activity:activity:1.2.3", # using 1.4.0 causes indexing issues in dex without force-jumbo, even without dagger-views.
"androidx.appcompat:appcompat:1.3.1",
"androidx.appcompat:appcompat-resources:1.3.1",
"androidx.constraintlayout:constraintlayout:2.1.1",
"androidx.core:core:1.7.0",
"androidx.fragment:fragment:1.3.6",
"androidx.lifecycle:lifecycle-viewmodel:2.3.1",
"androidx.viewpager2:viewpager2:1.0.0",
"androidx.recyclerview:recyclerview:1.0.0",
"androidx.tracing:tracing:1.0.0",
"com.google.android.material:material:1.4.0",
],
excluded_artifacts = [
maven.exclusion(
group = "com.google.guava",
artifact = "guava",
),
],
repositories = [
"https://maven.google.com",
"https://repo1.maven.org/maven2/",
],
)
new_simple_repo( # Simple custom repo rule to make an #android repo for use elsewhere
name = "android",
build_file_content = """
package(default_visibility = ["//visibility:public"])
android_library(
name = "android",
exports = [
"#guava//:concurrent",
"#maven_android_everything//:androidx_activity_activity",
"#maven_android_everything//:androidx_appcompat_appcompat",
"#maven_android_everything//:androidx_appcompat_appcompat_resources",
"#maven_android_everything//:androidx_constraintlayout_constraintlayout",
"#maven_android_everything//:androidx_core_core",
"#maven_android_everything//:androidx_fragment_fragment",
"#maven_android_everything//:androidx_lifecycle_lifecycle_viewmodel",
"#maven_android_everything//:androidx_viewpager2_viewpager2",
"#maven_android_everything//:androidx_recyclerview_recyclerview",
"#maven_android_everything//:com_google_android_material_material",
],
)
""")
I've tried bumping versions to see if maybe that might help, but after slogging through dependency conflicts and finally getting bazel sync to succeed, I hit this bug.
I'm trying to pare my "playgroung" project down and see if I can isolate anything, but even removing a dependency on the original project doesn't help.
I had some time to come back to this today and after much experimenting, including trying to set up a minimal example to use when filing a bug with bazel, I believe I found the problem. It appears to relate to the lengths of resulting file names. By trying various lengths of the name of the maven repo used in the maven_install command, I was able to get the build to fail or pass consistently based on the length. Any name 21 characters or shorter and the build succeeded, while any name longer than 21 characters would result in the file-not-found error.
What I'm trying to achieve
I'm trying to generate my REST API client for Android using OpenAPI Generator from the build.gradle script. That way, I wouldn't have to run the generator command line every time the specs change. Ideally, this would be generated when I build/assemble my app, and the sources would end up in the java (generated) folder, where generated sources are then accessible from the code (this is what happens with the BuildConfig.java file for example).
What I've tried so far
Following this link from their official GitHub, here's the build.gradle file I ended up with:
apply plugin: 'com.android.application'
apply plugin: 'org.openapi.generator'
...
openApiValidate {
inputSpec = "$rootDir/app/src/main/openapi/my-api.yaml"
recommend = true
}
openApiGenerate {
generatorName = "java"
inputSpec = "$rootDir/app/src/main/openapi/my-api.yaml"
outputDir = "$buildDir/generated/openapi"
groupId = "$project.group"
id = "$project.name-openapi"
version = "$project.version"
apiPackage = "com.example.mypackage.api"
invokerPackage = "com.example.mypackage.invoker"
modelPackage = "com.example.mypackage.model"
configOptions = [
java8 : "true",
dateLibrary : "java8",
library : "retrofit2"
]
}
...
First, I've never managed to get the API generated with the build/assemble task, even when I tried adding:
compileJava.dependsOn tasks.openApiGenerate
or
assemble.dependsOn tasks.openApiGenerate
The only way I could generate the sources was by manually triggering the openApiGenerate task:
Then, when I do generate my sources this way, they end up in the build folder but aren't accessible from my code, and aren't visible in the java (generated) folder:
I then have to manually copy/paste the generated source files to my project sources in order to use the API.
Even though I'm able to work around these issues by adding manual procedures, it would be way more maintainable if the whole process was simply automatic. I was able to achieve a similar result with another tool, Protobuf. Indeed, my gradle task gets triggered every time I build the app, and the sources end up in the java (generated) folder, so I don't have to do any additional work. The task is much simpler though, so I assume the main work that I'm not able to replicate with OpenAPI Generator is handled by the Protobuf plugin itself.
You have to specify path to the generated sources as a custom source set for your Gradle module, which is app in this case, as described here – https://developer.android.com/studio/build/build-variants#configure-sourcesets. That way Gradle will treat your sources as accessible from your code.
Something like this:
android {
...
sourceSets {
main {
java.srcDirs = ['build/generated/openapi/src/main/java']
}
}
...
}
I solved the issue you described like this, I'm using gradle.kts however.
See my build.gradle.kts
plugins {
// Your other plugins
id("org.openapi.generator") version "5.3.0"
}
openApiGenerate {
generatorName.set("kotlin")
inputSpec.set("$rootDir/app/src/main/openapi/my-api.yaml")
outputDir.set("$buildDir/generated/api")
// Your other specification
}
application {
// Your other code
sourceSets {
main {
java {
// TODO: Set this path according to what was generated for you
srcDir("$buildDir/generated/api/src/main/kotlin")
}
}
}
}
tasks.compileKotlin {
dependsOn(tasks.openApiGenerate)
}
You need to build the application at least once for the IDE to detect the library (at least this is the case for me in Intellij)
Your build should automatically generate the open api classes , to refer the generated classes in your java project you should add the generated class path to your source directory like it was mentioned in the other answers
https://developer.android.com/studio/build/build-variants#configure-sourcesets
As far as the task dependency goes , in android tasks are generated after configuration thus for gradle to recognize the task , wrap it inside afterEvaluate block like
afterEvaluate {
tasks.compileDebugJavaWithJavac.dependsOn(tasks.openApiGenerate)
}
I had this issue, and this answer https://stackoverflow.com/a/55646891/14111809 led me to a more informative error:
error: incompatible types: Object cannot be converted to Annotation
#java.lang.Object()
Taking a look at the generated files that were causing this error, noticed:
import com.squareup.moshi.Json;
After including a Moshi in the app build.gradle, the build succeeded and the generated code was accessible.
implementation("com.squareup.moshi:moshi-kotlin:1.13.0")
About Bintray-release plugin
I am using bintray-release to upload my library to maven.Its doc says how to use it:
Use the publish closure to set the info of your package:
publish {
userOrg = 'novoda'
groupId = 'com.novoda'
artifactId = 'bintray-release'
publishVersion = '0.3.4'
desc = 'Oh hi, this is a nice description for a project, right?'
website = 'https://github.com/novoda/bintray-release'
}
Finally, use the task bintrayUpload to publish
$ ./gradlew clean build bintrayUpload -PbintrayUser=BINTRAY_USERNAME -PbintrayKey=BINTRAY_KEY -PdryRun=false
In my case
Then I define my publish closure:
publish {
groupId = 'com.uniquestudio'
artifactId = 'parsingplayer'
publishVersion = '2.0.6'
website = 'https://github.com/TedaLIEz/ParsingPlayer'
Properties properties = new Properties()
InputStream inputStream = project.rootProject.file('local.properties').newDataInputStream() ;
properties.load( inputStream )
bintrayUser = properties.getProperty('bintrayUser')
bintrayKey = properties.getProperty('bintrayKey')
}
As you can see,out of safety I put bintrayUser and bintrayKey into local.properties.
My Question
First
I know I can put bintrayUser and bintrayKey in loacal.properties and gradle.properties.Is there any other way to store private data while I don't think is't suitable to store private data within current project ?
Second
Everything is ok but when I push my project to CI.I get error:
/home/travis/build/TedaLIEz/ParsingPlayer/local.properties (No such file or directory)
So I want to know How gradle task deal with extension objects,in my case,publish object.Is there any way to fix it?
First, I have to tell you that it is not recommended to ask two questions at once via StackOverflow, mainly because it may be hard to choose a correct answer, if two answers help you with the different questions you asked.
Anyhow, I'll try to answer both of your questions:
First
To use an additional properties file (local.properties in your case) is not a Gradle approach. It is in fact pure Java. You should only read properties on your own in very rare cases and never in a build script. If you really need an additional properties file, develop a Gradle plugin, which handles the file access.
Gradle automatically reads the gradle.properties file, but not only in the project directory, but also in the user-specific gradle home directory (e.g. C:\Users\*<User>*\.gradle). This is helpful to define private data, which won't find its way into version control, even if you forget to ignore the files manually. The defined data will be accessible to any project.
Second
Well, I assume the file local.properties does not exist, because you did neither put it under version control nor let your CI add it automatically. Where should the login data come from?
The solution is simple. Just add the required data to the CI user gradle home directories (e.g. /home/travis/.gradle) gradle.properties file. This way, you can also simply add access right management, by entering the login data of a CI user. Local builds will be published by your local user account (if allowed), CI builds by the CI system.
Appendix
Your question includes the Gradle specific term 'extension', but, to be honest, it got nothing to do with your question. It is correct, that most configuration in Gradle is done via so-called extension objects, that are added to the Project object, but it is an internal term, you do not need to understand it to fix this problem.
Edit: Comment answer
Now I can understand your confusion. Gradle distinguishes between the configuration phase and the execution phase. Nearly everything in your build script is executed during the configuration phase, only task actions (what a task does, e.g. copying, deleting ...), doFirst and doLast closures (so basically tasks) are executed during execution phase. If you define the list of tasks to be executed (via command line), it only affects the execution phase, but your configuration code will be executed at every single build, even if only one independent task is executed afterwards.
To solve this problem, follow the solution in the First block and add your private data to the user-specific Gradle directory gradle.properties file. It will be added to the project object and therefor, it will be accessible from the build file. But, since the file (or the data) does not exist on your CI, accessing it directly will raise an error when building on the CI. You can use the findProperty(propertyName) method as a fail-safe way to access the property value. If the property does not exist, it returns null (in the configuration phase), so no error occurs, as long as you don not execute the bintrayUpload task (which is not your goal on the CI).
When building a project I get the following error:
Flavor 'nativescript-telerik-ui' has unknown dimension 'nativescript-telerik-ui'.
It happens only when using the pro version through the #progress registry. Doesn't happen with the local .tgz pro version.
I noticed the error has to do with the include.gradle file it generates. I read the following article: https://docs.nativescript.org/plugins/plugins#includegradle-specification
It says that when the plugin doesn't have the include.gradle, at build time gradle creates a default one with default elements. When I saw the include.gradle it generated for the plugin it seems to have generated a default one like so:
android {
productFlavors {
"nativescript-telerik-ui" {
dimension "nativescript-telerik-ui"
}
}
}
The include.gradle generated for the local .tgz version of the plugin is like this:
android {
productFlavors {
"F6" {
dimension "nativescripttelerikuipro"
}
}
}
I replaced the default include.gradle with the latter and it got past the error. You can recreate the problem by following these steps:
create a new hello world app
use the command npm login --registry=https://registry.npm.telerik.com/ --scope=#progress to log in if you're a paying customer.
use the command npm install --save #progress/nativescript-telerik-ui-pro to install the plugin
use tns run android
Is there anything I can do to solve this problem? Really need help on this.
My name is Vladimir and I am part of the nativescript-telerik-ui-pro team. Thank you for logging this issue in our feedback portal. We are going to review it as soon as possible and update you regarding its status, but from what I currently see there is some incorrect "parameters" passed to the 'pro' version of the plugin that are going to be resolved very fast.
We apologize for any inconvenience that this is causing.
Am trying out the recently released feature that allows uploading of ProGuard mapping file to Firebase (https://firebase.google.com/docs/crash/android) using gradle task. The following is the task I'm running.
./gradlew -PFirebaseServiceAccountFilePath=xxxxx.json :app:firebaseUploadReleaseProguardMapping
However, it doesn't seem to be recognizing service account file. Has anyone had any luck getting this working? I've also tried defining FirebaseServiceAccountFilePath in gradle.properties.
* What went wrong:
Execution failed for task ':app:firebaseUploadReleaseProguardMapping'.
> Service account file path has not been defined! Service accounts are used to authorize your mapping file uploads. Learn more at
https://firebase.google.com/docs/crash/android.
Set relative path to json in gradle.properties (in project root)
FirebaseServiceAccountFilePath = /firebase-crashreporting.json
and update this property in your build.gradle
apply plugin: 'com.android.application'
apply plugin: 'com.google.firebase.firebase-crash'
android {
...
}
setProperty("FirebaseServiceAccountFilePath", rootProject.rootDir.absolutePath + FirebaseServiceAccountFilePath)
dependencies {
...
}
The error message is misleading. You will see that if the file path that you give for the service account wasn't found. Try passing the full, unambiguous path of the service account file (try not to depend on relative paths).
I'll make sure that the next version of the plugin has a more meaningful error message for the case where the file isn't found. Sorry about the trouble.
In my case I was using Jenkins to upload the proguard mappings for me. I had to change the file permissions for the json private key file from 400 to 444.