bintray / gradle-bintray-plugin

Apache License 2.0
1.28k stars 197 forks source link

400 Response but Successful Upload #81

Closed samtstern closed 8 years ago

samtstern commented 9 years ago

When I include the lines version = "0.1" and group = "pub.devrel" in my gradle files, I get the following error when running 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, the bintrayUpload task succeeds but I get a bad result (aar file is under the wrong group and has version unspecified).

Here is my build.gradle:

apply plugin: 'com.android.library'
apply from: 'maven.gradle'
apply from: 'bintray.gradle'

android {
    compileSdkVersion 22
    buildToolsVersion "22.0.1"

    defaultConfig {
        minSdkVersion 15
        targetSdkVersion 22
        versionCode 1
        versionName "0.1"
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }

}

dependencies {
    compile 'com.android.support:appcompat-v7:22.2.0'
    compile 'com.google.android.gms:play-services:7.5.0'
}

This is my maven.gradle:

apply plugin: 'com.github.dcendents.android-maven'

install {
    repositories.mavenInstaller {
        pom.project {
            name 'EasyGoogle'
            description 'A wrapper library for basic functions of Google Play Services APIs'
            url 'https://github.com/googlesamples/easygoogle'
            inceptionYear '2015'

            packaging 'aar'
            groupId 'pub.devrel'
            artifactId 'easygoogle'
            version '0.1'

            licenses {
                license {
                    name 'The Apache Software License, Version 2.0'
                    url 'http://www.apache.org/licenses/LICENSE-2.0.txt'
                    distribution 'repo'
                }
            }
            scm {
                connection 'https://github.com/googlesamples/easygoogle.git'
                url 'https://github.com/googlesamples/easygoogle'

            }
            developers {
                developer {
                    name 'Google'
                }
            }
        }
    }
}

And this is my bintray.gradle:

apply plugin: 'com.jfrog.bintray'

// TODO(samstern): when I include these two lines I get the desired result but I get a 400, when
// I do not include them I get a 200 but I get the wrong result...
//group = 'pub.devrel'
//version = '0.1'

bintray {
    user = System.getenv('BINTRAY_USER')
    key = System.getenv('BINTRAY_KEY')

    configurations = ['archives']

    pkg {
        // TODO(samstern): create an org and set userorg
        repo = 'EasyGoogle'
        name = 'easygoogle'
        licenses = ['Apache-2.0']
        vcsUrl = 'https://github.com/googlesamples/easygoogle.git'

        version {
            name = '0.1'
            vcsTag = '0.1'
        }
    }
}
eyalbe4 commented 9 years ago

This issue and https://github.com/bintray/gradle-bintray-plugin/issues/88 seem to provide the same error message. In both cases, the com.github.dcendents.android-maven Plugin is used with the Bintray Plugin. We will soon update with our investigation results.

eyalbe4 commented 9 years ago

@samtstern , I think I know what causes this issue. First of all, since the error message you got from Bintray talks about the pom file, I'm guessing that your pom file fails to be deployed to Bintray (you other build artifacts may be deployed successfully though). The text of the message says: "...Maven group, artifact or version defined in the pom file do not match the file path...". This error might be generated in case your gradle project name does not match the artifact ID as defined in the pom.project closure in your Gradle build script (BTW, if the project name is not defined in the build script, Gradle uses the project directory as the project name). Changing your artifact ID to match the project name should fix this issue. To help troubleshoot this issue (and also to help other maven-android users to upload to Bintray), we added a new example named "android-maven-example" which is available here. Building this example according to the instructions should deploy the artifacts successfully.

INRIX-Owais-Ali commented 9 years ago

@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.

INRIX-Owais-Ali commented 9 years ago

It looks like it is this section of the BintrayUploadTask, this section always uses the project.name for the POM.

        artifacts << new Artifact(name: project.name, groupId: project.group, version: project.version,
                extension: 'pom', type: 'pom',
                file: new File(getProject().convention.plugins['maven'].mavenPomDir, "pom-default.xml"))
eyalbe4 commented 9 years ago

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? Thanks!

INRIX-Owais-Ali commented 9 years ago

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?

joebowbeer commented 9 years ago

pd-for-android is seeing this as well. (See writeup for details.)

AsturaPhoenix commented 9 years ago

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.

INRIX-Owais-Ali commented 9 years ago

That would work, since we are specifying archivesBaseName.

eyalbe4 commented 8 years ago

@samtstern, @INRIX-Owais-Ali, @AsturaPhoenix, @joebowbeer and all, We're considering adding the following change to the plugin. It should resolve this issue. The plugin will read the value of the artifactId from the pom file created by the maven-plugin and will use it for the pom artifact name instead of the project.name value used today. We'd appreciate your feedback for this.

AsturaPhoenix commented 8 years ago

That seems reasonable and looks like it will work for my case.

INRIX-Owais-Ali commented 8 years ago

Same here - it meets the requirements and looks reasonable.

joebowbeer commented 8 years ago

archivesBaseName works for pd-for-android. Thanks

galenlin commented 8 years ago

It would be nice! Waiting for the release.

eyalbe4 commented 8 years ago

Version 1.6 has just been released and it includes the following change (as discussed above): The plugin reads the value of the artifactId from the pom file generated by the maven-plugin and then uses it for the pom artifact name, instead of the project.name value used in previous versions.

stkent commented 8 years ago

Nice update! Can this issue and #103 now be closed?

tkirshboim commented 8 years ago

The issue mentioned by @joebowbeer that we had with on pd-for-android was fixed in version 1.6 which we are currently using.

eyalbe4 commented 8 years ago

Thanks for the feedback @tkirshboim :) I'm closing this issue.