-
Notifications
You must be signed in to change notification settings - Fork 198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
400 Response but Successful Upload #81
Comments
This issue and #88 |
@samtstern , |
@eyalbe4 I'm having the same issue. Unfortunately the artifact ID is different from the project name for a reason (naming of the artifact needs to be different) and changing it to match the project name is not feasible. The exact behavior I'm observing is that my binary artifact (aar) gets deployed to the correct path (group/artifact) however my pom gets deployed to the incorrect path (group is correct, but the artifact id is the project name). I've tried quite a few combinations of things and none of them seem to fix this issue, which is odd because the pom contains the correct details (group/artifact/version) - just the path it's getting deployed to is incorrect. |
It looks like it is this section of the BintrayUploadTask, this section always uses the project.name for the POM.
|
You are correct @INRIX-Owais-Ali. The code indeed adds the pom artifact and names it as the project name. To help us come up with the best solution, can you please share some details about your project? Can you list the names of your build artifacts, including the pom file? |
One of the artifacts we're producing (first one we're trying to get up on Bintray) is com.inrix.sdk.cache - this is the artifact name. The project name for this artifact is inrix-cache. The produced POM includes the correct details (from the install closure). I worked around this by switching to the publishing closure (which produces the results I want), however since this doesn't have Android support yet I have to manually populate the dependencies in the POM. Would it be feasible to switch to using the group/version/name from the install closure instead of using the project name/group/version? |
pd-for-android is seeing this as well. (See writeup for details.) |
Would it be reasonable to base it off project.archivesBaseName instead of project.name? I believe archivesBaseName needs to be overridden to generate the expected source and javadoc jars as well. |
That would work, since we are specifying archivesBaseName. |
bintray/gradle-bintray-plugin#81 Change-Id: I3ba742f373d63d75e0f5c046f3e7b5acbac5c89a
@samtstern, @INRIX-Owais-Ali, @AsturaPhoenix, @joebowbeer and all, |
That seems reasonable and looks like it will work for my case. |
Same here - it meets the requirements and looks reasonable. |
archivesBaseName works for pd-for-android. Thanks |
It would be nice! Waiting for the release. |
Version 1.6 has just been released and it includes the following change (as discussed above): |
Nice update! Can this issue and #103 now be closed? |
The issue mentioned by @joebowbeer that we had with on pd-for-android was fixed in version 1.6 which we are currently using. |
Thanks for the feedback @tkirshboim :) I'm closing this issue. |
When I include the lines
version = "0.1"
andgroup = "pub.devrel"
in my gradle files, I get the following error when runningbintrayUpload
:Execution failed for task ':easygoogle:bintrayUpload'.
However when I go on
bintray.com
and check the Files tab, I see exactly what I want to see. When I don't include those lines, thebintrayUpload
task succeeds but I get a bad result (aar
file is under the wrong group and has versionunspecified
).Here is my
build.gradle
:This is my maven.gradle:
And this is my bintray.gradle:
The text was updated successfully, but these errors were encountered: