Move to Bintray for Mapbox Java SDK releases

[osana]

Right now, Mapbox Java Sdk uses Sonatype to pass release files on to MavenCentral.
Recently, Maps SDK Android switched to using Bintray.
We want to align the release process used in those two projects and to use Bintray for Mapbox Java Sdk releases.

Here is the PR used to move to Bintray in Maps SDK Android for reference.

[langsmith]

Love the idea of getting more projects on to the same platform. Bintray integrations and its UI are all great.

[langsmith]

I added the needed environment variables to the Java SDK project in CircleCI

[langsmith]

I've added an initial setup for this on https://github.com/mapbox/mapbox-java/pull/new/ls-moving-release-process-to-bintray

I've made good progress but I'm running into a crash that probably has to do with where I'm (not) adding Gradle apply from statements

https://discuss.gradle.org/t/problem-with-publishing-with-maven-publish-in-a-multi-module-project-ii/22318

https://discuss.gradle.org/t/problem-with-publishing-with-maven-publish-in-a-multi-module-project/1695/3

novoda/bintray-release#24

[langsmith]

Ok @osana & @LukasPaczos , https://github.com/mapbox/mapbox-java/pull/new/ls-moving-release-process-to-bintray has my most up-to-date work.

One thing I thought about looking into is using a different Bintray publishing plugin, such as https://github.com/novoda/bintray-release . Perhaps a different plugin can handle the multiple components that are in the services package.

[LukasPaczos]

Perhaps a different plugin can handle the multiple components that are in the services package.

Now that I think about it, what's the issue with pushing each artifact separately to Bintray? We'll probably still need to click the sync button on each artifact separately. Your current setup seems to be adapted well to do that, are you running into any issues?

The only piece that I think might be missing is that we need to recognize in the Makefile#publish or CI script whether a version is a SNAPSHOT or a stable/alpha version which was previously handled by the maven-release plugin.

[langsmith]

pushing each artifact separately to Bintray

Not sure what you mean. Can you elaborate? You're suggesting each API wrapper artifact (optimization, mapmatching, etc.) should be sent separately to Bintray first? Or something different?

The only piece that I think might be missing is that we need to recognize in the Makefile#publish or CI script whether a version is a SNAPSHOT or a stable/alpha version which was previously handled by the maven-release plugin.

Ok, will look into this. Working off of mapbox/mapbox-gl-native#14067, I pushed/re-based changes to start the work of setting the SNAPSHOT repository to https://oss.jfrog.org/artifactory/oss-snapshot-local/. If this shouldn't be done, let me know.

[LukasPaczos]

You're suggesting each API wrapper artifact (optimization, mapmatching, etc.) should be sent separately to Bintray first? Or something different?

No, phrased that poorly. We have 4 releasable modules, core, services, geojson, turf. All those non-releasable modules are declared as code source sets for services, not as dependencies, so there should be no issues here.

Perhaps a different plugin can handle the multiple components that are in the services package.

Just a hunch, but this error might be thrown because you are first applying the bintray plugin that defines a publication to, for example, core and then using that as a dependency in services which applies the bintray plugin again.

Another issue might arise when we get to dependencies on other projects, for example:

mapbox-java/services-turf/build.gradle

Line 8 in 7120a50

api project(":services-geojson")

or

mapbox-java/services/build.gradle

Lines 13 to 14 in 7120a50

	api project(":services-core")
	api project(":services-geojson")

those dependencies might not be picked up in POM (or are represented poorly, like unknown or wrong artifact names).

References in the POM to those modules need to be based on their Maven releases. Gradle is unable to determine if, or which version of the artifact it should use because we are consuming a local module.

So, whenever we release a module, during the POM generation we need to iterate through all of its dependencies and for each local dependency we need to overwrite that module value with a correct artifact name and version of the most recent Maven release of that dependency. We can either store those locally, next to the current SNAPSHOT version name or query them from the Maven repository.

[LukasPaczos]

When it comes to snapshots, we need to first create a new project in https://bintray.com/mapbox/mapbox/ (this is needed for regular releases as well) and request JCenter access to be able to push to the snapshot repository.

[osana]

A bit of a side note but maybe it would be helpful.

It is easy to merge service-core into services.
Dependency on service-core in services-geojson is minimal.

But if we want to be able to release each of the sub-services individually than this is not actionable.