Fix AndroidThemis publishing #669
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Introducing desktop Java build has moved Android project into a subproject, not a top-level project. This changes the artifact name which is based on the directory where build.gradle resides. It changes from "projects" (repo directory name in the Docker container we use) to "android" (that is "src/wrappers/themis/android"). Also, Gradle seems to be really confused with $buildDir when subprojects are used so replace it with just "build" (relative to "build.gradle").
For now, we don't publish any additional archives except for the AAR. Later on we will need to publish source code and Javadoc JARs to be able to host Themis on JCenter, but for now remove the configuration-based uploads as recommended by Bintray plugin docs [1]. [1]: https://github.com/bintray/gradle-bintray-plugin#buildgradle I guess later it will be possible to just add more artifacts to the publication and avoid messing with configurations and manual pom.xml generation. Or I hope, at least...
Current version tends to do silly things after switching to subprojects.
For example, it fails to locate the subproject artifacts and attempts to
upload some nonsensical files instead, which fails with cryptic errors:
> Task :android:bintrayUpload FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':android:bintrayUpload'.
> Could not upload to 'https://api.bintray.com/content/cossacklabs/maven/themis/0.13.0/property(class java/lang/String, fixed(class java/lang/String, com/cossacklabs/com))/property(class java.lang.String, fixed(class java.lang.String, themis))/property(class java.lang.String, fixed(class java.lang.String, 0.13.0))/property(class java.lang.String, fixed(class java.lang.String, themis))-property(class java.lang.String, fixed(class java.lang.String, 0.13.0)).pom': HTTP/1.1 400 Bad Request [message:Unable to upload files: Maven group, artifact or version defined in the pom file do not match the file path 'property(class java/lang/String, fixed(class java/lang/String, com/cossacklabs/com))/property(class java.lang.String, fixed(class java.lang.String, themis))/property(class java.lang.String, fixed(class java.lang.String, 0.13.0))/property(class java.lang.String, fixed(class java.lang.String, themis))-property(class java.lang.String, fixed(class java.lang.String, 0.13.0)).pom']
Java being Java, there's always an XML and a stacktrace somewhere, with
one thing being converted into the other. But not in my file names, ffs!
The wisdom of the Internet says that upgrading the plugin helps [1, 2].
It does. Upgrade the plugin to avoid publishing issues in the future.
[1]: bintray/gradle-bintray-plugin#253
[2]: bintray/gradle-bintray-plugin#287
Bintray publishing task started to throw errors like this after
successfully publishing Android Themis:
> Task :bintrayPublish FAILED
FAILURE: Build failed with an exception.
* Where:
Build file '/projects/src/wrappers/themis/java/build.gradle' line: 7
* What went wrong:
A problem occurred evaluating project ':desktop'.
> Cannot change dependencies of configuration ':desktop:classpath' after it has been resolved.
How is ":desktop" project related to the ":android" subproject? No idea,
they shouldn't depend on each other.
The Internet suggests that disabling on-demand configuration helps [1].
It does. Though, this is the feature designed for to avoid this
situation in the first place -- to not have ":desktop" configured when
only ":android" is used. But whatever. At least they are honest about
this feature being experimental.
Gradle only knows what happens here.
Yes, this change means that you will have to have Android SDK installed
and configured to build desktop Java Themis. I'm sorry.
[1]: https://stackoverflow.com/questions/42552511/cannot-change-dependencies-of-configuration-compile-after-it-has-been-resolve
ilammy
added
W-JavaThemis ☕
vixentael
approved these changes
Jul 9, 2020
shadinua
approved these changes
Jul 9, 2020
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
During the release procedures we have found that AndroidThemis fails to publish correctly. This seems to be a side effect brought by Gradle configuration changes such as #633 and #637. Since we don't release that often and there is no automated testing for the release flow, the issues have been discovered only now.
Initially I suspected that the configuration was wrong in some way—and it was, but it's not that broken. After several attempts to revert and roll back version of Gradle, its plugin, etc. I have finally found that the Bintray publishing plugin should be upgraded. Apparently, it is required to work with new Gradle plugin. (We need to upgrade Gradle to at least 4.9 to support Kotlin.)
Technical details are in the commit messages. On visible side effect is that Android SDK now must be installed and configured to build desktop JavaThemis. This is because we keep both Android and desktop Java in the same Gradle configuration and Gradle build dependencies are resolved for all subprojects (regardless of what you're building).
Checklist