When I build my Android project from the command line with
gradlew assembleRelease
It works, but when I run it from my teamcity build agent the build gives a lot of warnings and fails witht he following errors:
[11:40:43][Step 4/10] Warning: there were 75 unresolved references to program class members.
[11:40:43][Step 4/10] Your input classes appear to be inconsistent.
[11:40:43][Step 4/10] You may need to recompile the code.
[11:40:43][Step 4/10] (http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedprogramclassmember)
[11:40:43][Step 4/10] :proguardRelease FAILED
I've tried modifying my build config to run gradlew from command line instead of using the gradle build runner but it is still broken. There is obviously something different between running the command from TeamCity versus running it manually through command line, but I don't know what that could be. Where to look?
Your problem and solution are right what it says on the tin:
Your input classes appear to be inconsistent.
You may need to recompile the code.
Given you're using Gradle, it's possible one version of gradle doesn't match the other or doesn't behave the same. This is particularly true if e.g. you've upgraded gradle from an older version.
Fix is simple: gradle clean or gradlew clean then try again.
Related
The following error occurs when gradle builds
Duplicate class androidx.lifecycle.ViewModelLazy found in modules lifecycle-viewmodel-2.5.1-runtime (androidx.lifecycle:lifecycle-viewmodel:2.5.1) and lifecycle-viewmodel-ktx-2.3.1-runtime (androidx.lifecycle:lifecycle-viewmodel-ktx:2.3.1)
Duplicate class androidx.lifecycle.ViewTreeViewModelKt found in modules lifecycle-viewmodel-2.5.1-runtime (androidx.lifecycle:lifecycle-viewmodel:2.5.1) and lifecycle-viewmodel-ktx-2.3.1-runtime (androidx.lifecycle:lifecycle-viewmodel-ktx:2.3.1)
Go to the documentation to learn how to Fix dependency resolution errors.
So I found the following documentation:
link
But I can't find AppName > Tasks > android. I noticed the following tip:
So I opened the settings and unchecked the Do not build Gradle task list during Gradle sync
but this still doesn't work.
I already know the answer to this question, when you run the gradle command once, the interface will appear.
gradle app:dependencies
We wired https://github.com/sherter/google-java-format-gradle-plugin into our project per the readme.
We also wired in a pre-commit hook to run the plugin before committing, which ensures that all of the code in a changelist is formatted before pushing it, which avoids errors in Jenkins when we run the verGJF task.
But we have to keep remembering to run goJF locally before running ./gradlew build, or the build fails with formatting errors.
We worked around this by adding the https://plugins.jetbrains.com/plugin/8527-google-java-format and https://plugins.jetbrains.com/plugin/7642-save-actions plugins for IntelliJ, enabling the google-java-format plugin, and configuring the save-actions plugin to format on save.
But that's a lot of extra configuration a developer has to remember to go through, plus it means they can't format code the way they want while working on it, and only have it be reformatted at the point of build or commit.
We'd prefer an all-Gradle solution, so that the goJF task is run before the build task (and before the verGJF task, which is already bound to the build task by the google-java-format Gradle plugin).
We couldn't figure out how to do that. Does someone else know?
It sounds like you want to essentially always ensure that the code is properly formatted before the verifyGoogleJavaFormat task is run (and could complain). In that case, I’d simply make the googleJavaFormat task a dependency of the verifyGoogleJavaFormat task. In your build.gradle file, after you have applied the google-java-format plugin, simply add the following:
verifyGoogleJavaFormat.dependsOn(tasks.googleJavaFormat)
Alternatively, if you really only want to run the code formatter when the build task is run (as opposed to when the verifyGoogleJavaFormat task is run only), you could add this instead:
build.dependsOn(tasks.googleJavaFormat)
verifyGoogleJavaFormat.mustRunAfter(tasks.googleJavaFormat)
I have a go lang application which exposes a rest API and logs the information to DB. I am trying to convert the make file to gradle build. Is there any default way similar to maven2gradle plugin or the gradle build file should be written manually? I checked the syntactical differences between gradle and make file but still not clear about passing run time arguments to gradle that is similar to
run:build
./hello -conf=/apps/content/properties/prop.json -v=0 -logDest="FILE" -log_dir="/var/log/logdir"
hello is my executable and others are the runtime arguments. This is my first attempt in migrating make to gradle and I couldnt find any clear documentation. Please help.
As far as I have checked, there is no direct plugin that could do this task. As a workaround, the build execution could be written as seperate tasks in gradle and ordered accordingly. Tasks here would contain setting Go path, installing dependencies and building the application and would be run as command line process in Gradle. Gradle provides support to run command line processes as described in gradle documentation. Hope it helps.
Why would I run gradle clean build instead of gradle build?
From what I understand, Gradle can detect source changes and update the final artifacts if needed. So why would I still need to clean?
The clean task is defined by the java plugin and it simply removes the buildDir folder, thus cleaning everything including leftovers from previous builds which are no longer relevant. Not doing so may result in an unclean build which may be broken due to build artifacts produced by previous builds.
As an example assume that your build contains several tests that were failed and you decided that these are obsolete thus needs to be removed. Without cleaning the test results (using cleanTest task) or the build entirely (by running the clean task) you'll get stuck with the failed tests results which will cause your build to fail. Similar side effects can happen also with resources/classes removed from the sources but remained in the build folder that was not cleaned.
It removes the build directory. (Build contains the output of the gradle operation)
Other build tools like buck will detect that some tests are removed and won't run them without the needs to run clean target. I think this is pitfall of gradle.
You don't need to run the clean task.
Gradle will track task dependencies and clean appropriate parts for you.
Here's an example Gradle project I created to show that the accepted answer is incorrect.
If custom tasks don't track their dependencies well (they're bugged), then clean is a workaround.
I have a series of projects within a workspace, and trying to use the following type of command to build them via the command line:
"Xcodebuild -project XXX"
or
"Xcodebuild -workspace XXX -scheme YYY"
Some of my projects build fine but others give strange errors, like "'XXX' for instance message does not declare a method with selector" or "ld: library not found for -lMyLibrary"
However all these projects build fine from within the XCode UI without issues.
Based on this is seems that the command line and UI builds are using a different toolset, but that seems like a very bad idea so I'm hoping I'm wrong about this. Or possibly there are just a few different build flags being set on the command line build.
I can try to troubleshoot the issues one by one but I'm hoping I can write a script which does the exact same type of build as the UI.
Any ideas?
Without including -configuration, xcodebuild is going to use the default configuration for each project. Generally that's Release. In Xcode, the Configuration you select will be applied to every project regardless of default.
Given your errors, your most likely problem is that you've used the build pane (why I hate the build pane for large projects), and you've made the classic mistake of applying some settings for Debug rather than all configurations.