Artifact path broken using >= Gradle 4.9 #253
Comments
This was referenced Oct 6, 2018
|
It seems like the issue is gone in recent versions of the plugin (1.8.1+). This issue can be closed. |
|
Thanks for the update @mr-archano! |
|
I'm facing the same issue with gradle version 4.10.1 and |
rnorth
added a commit
to testcontainers/testcontainers-java
that referenced
this issue
Nov 5, 2018
gluck
added a commit
to Itiviti/gradle-nunit-plugin
that referenced
this issue
Nov 27, 2018
ilammy
added a commit
to ilammy/themis
that referenced
this issue
Jul 9, 2020
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
ilammy
added a commit
to cossacklabs/themis
that referenced
this issue
Jul 9, 2020
* Update Android artifact path for publishing 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"). * Use only publication-based uploads 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... * Update Gradle Bintray plugin to 1.8.1 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 * Reorder dependencies to avoid publishing issues 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When the consumer project uses Gradle 4.9 or 4.10, the artifact path is resolved wrong.
What we can see in the log:
How it should look like:
This can be reproduced using the official publications-example. Just bump the Gradle Version to 4.9 and run
bintrayUpload -PbintrayUser=foo -PbintrayApiKey=barwhich will prompt the broken path.The text was updated successfully, but these errors were encountered: