Release this project as an Android library to jCenter and Maven Central. about exoplayer HOT 27 CLOSED

I assume it is something like:

repositories {
   jcenter()
}

dependencies {
   compile 'com.google.android.exoplayer:exoplayer:r1.2.3'
}

Can be found here: https://bintray.com/google/exoplayer/exoplayer/view#files

from exoplayer.

Out of interest, why do you suggest putting it somewhere like Maven Central would discourage fork-and-hoard? Fundamentally people either want to change the source or they don't. Admittedly people are slightly more likely to do it in a clean way if they're using a binary (i.e. extension in their own codebase rather than modifying the library directly). Are there any other reasons?

As a second question, since I'm not familiar with things like Maven Central: Do you know how API incompatibility is handled? We're not trying to keep the API completely compatible from one release to the next, at least not at this stage, so it wouldn't be possible for us to just replace the binary with a new one each time. We'd probably have to version them. Does that negate the benefit?

from exoplayer.

Maven central doesn't specify anything about making sure your API is backwards compatible. There are tons of projects out there that break API all the time that are in maven central. In general that is handled by the project and it's versioning mechanism.

There are restrictions on how the POMs have to be setup and what has to go in to those poms. Those are documented here:

http://central.sonatype.org/pages/ossrh-guide.html

The Sonatype OSS repository is free to open source projects to use to get their projects into Maven Central.

I agree also, that it would be great to have this in maven central. It'll just make it easier to consume from a gradle or maven build to have it in central.

from exoplayer.

Being forced to use ExoPlayer via a fork will make it less likely that I will contribute back bug fixes and/or enhancements in that I have to maintain those fixes locally forever rather than only for the small amount of time I might actually invest in making bug fixes and enhancements if someone else is doing the releasing. The general model of open source that I am used to consists of consuming artifacts and only contributing source code level changes when I am forced to because of bugs or features that I add, which is much smaller than the time I actually use the package/library. So I don't pay the maintenance cost of having a forked project. Basically programmers are lazy (mea culpa) and only do as little as they have to which is a good thing in that less code is better from a maintenance point of view. @kingargyle answered your other questions quite well.

from exoplayer.

Ok, thanks for the info. I'll take a look.

I don't think you're forced to fork in the existing model though. You can just pull the Google version, build the jar, and then use it. Which seems equivalent, except with the added overhead of having to build it yourself.

from exoplayer.

Which in general you want to avoid having to have people do. That is why place like Maven Central exist, so that a common version can be retrieved. Plus there are plenty of places that won't pull down and build the code from source. Binaries are preferred whether that comes from maven central or downloaded from a projects site. Having it in Maven Central just makes it much easier for potential adopters to get up and running.

from exoplayer.

Has a decision been made on this? Keeping the library updated would definitely be easier if we could fetch it from Maven Central.

from exoplayer.

Yes. We'll do this for stable releases. You'll still need to use the source directly if you want to make modifications and/or work against the development branches, obviously.

from exoplayer.

👍 fyi JCenter has a much easier release process than Maven Central

from exoplayer.

before there is a stable release, and assume it will take more than a few weeks to become stable, may I suggest to release it as a "alpha", "beta", "rc" etc.? just make it very clear it is unstable and use it at your own risk...

from exoplayer.

We use ExoPlayer from inhouse maven repo. And add some code to publish it via gradle #314

May be it would be useful when you

We'll do this for stable releases.

from exoplayer.

Update - Our intention is to publish through https://bintray.com/google in due course.

from exoplayer.

fyi we made it super easy with this plugin https://github.com/novoda/bintray-release

publish {
    userOrg = 'google'
    groupId = 'com.google'
    artifactId = 'exoplayer'
    version = '1.0.0'
    description = 'Insert desc here'
    website = 'https://github.com/google/ExoPlayer'
}

/gradlew clean build bintrayUpload -PbintrayUser=BINTRAY_USERNAME -PbintrayKey=BINTRAY_KEY -PdryRun=false

from exoplayer.

Added use of bintray-release in: 85be2ae

from exoplayer.

Added here: https://bintray.com/google/exoplayer

This is now just pending a bintray "add to jCenter" request. Once that gets done, we can close this issue.

from exoplayer.

This is now done. @blundell , it would be great if novoda could stop publishing a version, now that we're publishing one officially? In particular, you've got the "exoplayer" name, where-as the official version is "exoplayer-google", which doesn't make much sense here.

from exoplayer.

Yes we will switch to using the official upload and drop our release when yours is available 👍

from exoplayer.

Thanks! Closing this now.

from exoplayer.

💯

from exoplayer.

What's the appropriate build.gradle command to depend on ExoPlayer's bintray release? Something like this (which fails with a "failed to resolve" error):

repositories {
   maven {
      url  "http://dl.bintray.com/google/exoplayer"
   }
}

dependencies {
   compile 'google:exoplayer:1.2.3'
}

from exoplayer.

Ah, that’s it, thanks for the help.

On Mar 30, 2015, at 5:53PM, Xavi Rigau [email protected] wrote:

I assume it is something like:

repositories {
jcenter()
}

dependencies {
compile 'com.google.android.exoplayer:exoplayer:r1.2.3'
}
—
Reply to this email directly or view it on GitHub.

from exoplayer.

repositories {
   jcenter()
}

dependencies {
   compile 'com.google.android.exoplayer:exoplayer:r1.2.3'
}

I think it should be in README

from exoplayer.

@zayass, second that!

from exoplayer.

Me too!

from exoplayer.

@zayass thank you, don't know why they still not update README.

from exoplayer.

@VAdaihiep maybe someone should make a pull request

from exoplayer.

I've juste created one : #476

from exoplayer.