[Case Study] Bintray Automation for a Tedious Situation: Automating Package Distribution

Did you ever find yourself spending large amounts of time on a manual process, just wishing there was an automatic way to do it?

This case study will take you through how James Ward, Engineering and Open Source Ambassador at Salesforce.com, developed an automated process using JFrog Bintray for on-demand deployments of WebJars, that are created, distributed and available within the community.

After realizing that his many hours of manually deploying WebJars during his free time were unrealistic to maintain in the long run, Ward chose to use Bintray’s extensive and easy-to-use REST API to automate the process and make it available to the community on demand using JCenter, Bintray’s public Maven repository.

Ward’s WebJars project is a classic example of how JFrog Bintray can be used to scale up a tedious and time-consuming manual procedure into an easy and automated one.

Download the case study to learn more on how James Ward chose Bintray to scale thousands of WebJar Files.

The ABCs of Distributing Android Libraries

ABCDistributionFeatureBintray’s central repositories, JCenter and Conan-Center, are binary hubs for public OSS Maven and Conan (C++) packages respectively. They offer a great channel to distribute your public OSS packages. Having been around for a while, JCenter has become one of the most comprehensive sources for public OSS Maven packages, and is the channel-of-choice for many Maven projects. So we weren’t surprised to discover this blog post that describes how easy it is to distribute Android libraries through Bintray and JCenter.

Distributing Android libraries (or any other Maven package for that matter) through JCenter has its advantages. As one of the most popular Maven hubs, it exposes your package to a huge audience, and yet, you retain full ownership and can control how your package evolves. Basically, you upload your package to one of your public Maven repositories and ask for it to be included in JCenter. Once approved by the Bintray team, your package will be searchable on JCenter and freely available for download. You can learn about the details in the blog or look it up in the Bintray User Manual.

So if you’re ready to give your package world-wide fame, go ahead and open an account on Bintray. Bear in mind that since JCenter is a curated repository with trusted content, you need to be on a fully registered OSS or Premium account (as opposed to being on a trial) before you can link your package.

To start with a free OSS account, you can sign up here.

If you’re ready to go Premium (Pro or Enterprise), go here.

And if you want the full Enterprise experience, without committing to it yet, you can start a free trial (just remember to switch to an OSS or Premium account if you want to use JCenter).

Another one bites the Maven Central dust (and saved by Bintray)

Today, I encountered another very detailed blog post on the woes of publishing on Maven Central. Jose Maria Arranz (@jmarranz) explains why he doesn’t like Maven in general and publishing to Maven Central in particular (I am with him on a lot of valid points).

I can’t help quoting:

Fortunately when searching for how-to articles and commenting in Twitter, @jbaruch an employee of JFrog contacts with me offering Bintray.com alternative to publish to Maven Central, the people behind JCenter, I read the article “The easy way to maven central” and I was sold. Bintray provides a GUI to upload and self sign your artifacts if you provides your public and private GnuPG keys, and with a simple UI action you are published in JCenter repository, and providing the Sontaype user and password you can finally easily publish in Maven Central.

Bintray helped me to break the wall of Sonatype process. I’m saved!!

Currently I’ve released RelProxy on JCenter and Maven Central. For releasing I use Ant calling to Maven tasks to generate the required Maven artifacts and to generate a distribution zip with everything. Everything could be automated, I could add signing and uploading from Ant (or maybe by the POM) without Bintray, but Bintray auto-signing and uploading UI is enough for me, releasing is done from time to time and most of releasing process is already automated, and releasing in JCenter is a plus.

Note: Don’t forget JCenter, for instance Maven Central is no longer pre-configured in Google Android environment.

That’s what I call “success”!

Thanks for the kind words, Jose Maria! I am happy that we managed to help 🙂

Android Studio – Migration from Maven Central to JCenter

This post was originally published in Techno Talkative blog by Paresh Mayani. Feel free to comment here or there.

 

During the android workshop, in the office and in the chat with some of the android developers, I have received some questions around build script and repository:

  • Why earlier versions of android studio were using maven central?
  • Why android project, getting created using android studio, is using jcenter?
  • What are the reasons/benefits/purpose that android studio has gone with JCenter repository?
  • JCenter Vs. Maven Central

I had shared some of the points at that time, but I tried to go into the deep to know more about the migration made from maven central to jcenter. I have found interesting details from the couple of links:

Before going ahead and we discuss about the migration made from maven central to jcenter, here is brief about the repository (in case if you really don’t know!)

What is repository?

In Maven terminology, a repository is a place i.e. directory where all the project jars, library jar, plugins or any other project specific artifacts are stored and can be used by Maven easily.

In build.gradle file, you need to specify which repository to use when resolving dependencies for building your project, so you need to put something like the following in your build.gradle file:

repositories {
    jcenter()
}    

Yes, you need to specify at least one repository before you use any external dependency. Read more about Dependency Management Basics and repositories.

Maven central to jcenter migration

Now, here are the details and interesting points about the jcenter and the transition made from maven central to jcenter:

  • As said earlier, jcenter is the new default repository used with Android’s gradle plugin.
  • jcenter is a Java repository in Bintray, which is the largest repo in the world for Java and Android OSS libraries, packages and components.
  • All the content in jcenter is served over a CDN, with a secure https connection. Back in the time of the migration (Android Studio 0.8) The central maven 2 repository was HTTP only and HTTPS wasn’t supported. Reference: 51.6.2. Maven central repository. (This might be one of the reasons as Google is a fan of HTTPs!).
  • jcenter() is a superset of mavenCentral(), that encompasses many additional repositories and artifacts. Reference: Blog @ Bintray.
  • The jcenter guys claim, that they have a better performance than maven central.
  • Bintray has a different approach to package identification than the legacy Maven Central.
  • If you really need to get your package to Maven Central (for supporting legacy tools) you can do it from Bintray as well, in a click of a button or even automatically.

Regarding performance improvements, couple of android developer advocates had faced/noticed the issue of huge indexing with maven central.

In the words of Tor Norbye:

I ran AndroidStudio with a brand new settings directory, so it went and connected maven central and downloaded an index of the available artifacts.

Then I happened to look at the size of my directory.

My ~/Library/Cache/AndroidStudioPreview is 1.5G, and 1.2G of those are taken by the “Maven” subdirectory.

That’s ridiculous. We barely use the index at all. The primary use for it is the Dependency editor in the Project Structure Dialog, but we really don’t need to have a precomputed index for it. MavenCentral has a fast online JSON search we can use on demand when somebody searches for artifacts. In https://android-review.googlesource.com/#/c/94843/ we added a lint check which checks whether the dependencies are up to date, and the search for a handful of artifacts is near instant.

In short, we really don’t need the cache; it may help with code completion in .gradle and maven .pom files, but that’s not a super important usecase, and certainly not something *all* users should have to sacrifice 1.5G of download speed and diskspace to have the possibility of one day doing.

Read more on: The Maven index is *huge*!

I must say, after this migration from maven cetnral to jcenter, performance of the android studio is noticeable. Earlier loading android studio in even 4GB RAM configuration laptop, was all like:

code-21

Any way, this is not the ending of this study here, I still want to know more about the improvements or strong points (if any). If you know or have played enough with jcenter and maven central, please share your inputs. And also, as this is almost an undocumented point, I am really looking forward to hear about this migration, from the android developers advocates or engineers working in android tools team.

Nodeclipse: 500k downloads per month and counting!

Paul Verest

Paul Verest

Paul Verest, the Nodeclipse project lead posted to the Nodeclipse blog about his experiences with Bintray.

He talks about how the Bintray distribution platform freed up resources to take care of the truly important things – driving Nodeclipse and Enide Studio forward!

The main benefits Paul mentions are:

  • Speed – almost 3 times faster than GitHub and more than 5 times faster than SourceForge!
  • Eclipse Plugins Update Site (P2) Support –  allows users to define a unified Eclipse Update Site for a bunch of Nodeclipse related plugins (with a single URL that always points to the latest versions)
  • Simple UI – simplifies the release process for the Nodeclipse team
  • Additional small perks – flexible statistics and new release notifications.

Read on the original article on the Nodecipse site and join the discussion.