Publishing Your Maven Project to Bintray

Bintray gives you everything you need to share your Maven project, and much more: you will be able to monitor downloads and users with the statistics that Bintray keeps for you. You can also share your project via Bintray’s JCenter repository (which is the largest public Maven repository out there), and effortlessly sync it with Maven Central, if you wish.

Just follow these 5 simple steps to upload your Maven project to Bintray:

1. Have your Maven project ready

  • For this use case we will assume we have a maven project with the following groupId: org.jfrog.example.bintray.maven

2. Create a Maven package in Bintray

  • Open a Bintray account if you have not done so before.
  • Use the default Maven repository under your account or create a new one. The is where your Maven files will be hosted.

Create New Maven Repository

  • Under the Maven repository create a new package for your project. The package is merely a logical container that holds metadata about your project and annotates your files to allow Bintray to collect package and version level statistics.
    A good name for your package would be your main artifactId, but any name that logically identifies your project will do just as well.
    In our case, a good example would be: maven-example

3. Add the Bintray distribution URL

Next thing you need to do is to add a distribution section to your project’s pom.xml, and specify the URL from which to distribute your project. We will use our Bintray Maven repository and package as the target for deployment (remember? files in Bintray are always associated with a logical software package).


For your project to be visible to others, Bintray requires that you publish it. One way to do that is to add the publish directive to the distribution URL as a matrix parameter (;publish=1) as I did in the above example. You can also publish your projects at a later time using  the Bintray UI or via REST.

This block also includes an <id> tag. The id can be any string, but it should match the id in the settings.xml file described in the next step.

4. Provide your credentials to Bintray

In order to work with Bintray you need to provide your Bintray username and API Key as upload credentials in the username and password tags of your Maven settings.xml file. The API Key can be found when editing your Bintray profile page.


5. Time to deploy!

You are almost there. This is the time to run

mvn deploy

The project will be built, uploaded to the the Bintray repository target URL you provided, and published. You can now see your files in your Maven package in Bintray.

Maven Package Files List.
At this point, you can add your project to JCenter, the most comprehensive public Maven repository, so your project is well exposed. To read more about that, stay tuned for my next post.

A sample project similar to what I used in this post can be found in GitHub: bintray-examples/maven-examples.

Good Luck!

Creating a Signed URL Using the Bintray UI

Creating a Signed URL is now available to you through the Bintray friendly User Interface, from start to end.
If you are new to Signed URLs, you would rather check out this cool feature. Refer to the REST API Guide at URL Signing, and to the Sign me up! blog, discussing generating Signed URL using REST APIs.

Signed URLs are great for handing off a link to a single file download. They allow you to provide a link to download a published file from a private repository to a person that is not even a Bintray user! You are still able to track and monitor downloads volume and the identity of the users.

If you want to share a package or repository, or need to have more fine grained permissions control, take a look at Download Keys and Entitlements.

The scope here is files, hence, the option to generate a signed URL is available in the files view, under ‘Actions’:

Generate Signed URL

Once hitting ‘Generate signed URL’, the following form is opened:

Generate Signed URL Scrrenshot

This is where you wish to provide some extra parameters that make the Signed URL even smarter. All parameters are optional, except to the expiry field that is set to 30 minutes by default. The other parameters are described in the REST API guide.
The URL will be generated once you click ‘Create URL’. The file can be downloaded using curl in command line:

curl –X GET “signed URL” > filename.ext

Or just by copying and pasting the Signed URL into your browser.

Creating a Signed URL has never been easier!

Even more Vagrant love in Bintray

You, of course, know, that for nearly the last two years, you have been downloading your Vagrant software from JFrog Bintray. But recently, Bintray has taken Vagrant support to a whole new level; it is now is a fully fledged Vagrant repository allowing you to distribute your public and private Vagrant boxes from Bintray! As for everything in Bintray, it’s simple and powerful:

Publishing Vagrant Boxes

1. Create a Vagrant repository (if you’re a new user it is likely that you already have a default Vagrant repository named “boxes”):

Create a Vagrant repository

2. Click on “Set Me Up!” and copy/paste the REST command to upload the boxes:

Create a Vagrant repository

Consuming Vagrant Boxes

Follow the “Downloading” section under “Set Me Up!” to configure box resolution for downloading Vagrant boxes, and be able to enjoy automatic box update during ‘vagrant up’ a box either by an explicit call to  ‘vagrant box update’. That’s it, now you can benefit from all the power behind Bintray distribution: CDN, stats, logs, version notifications and more. So give it a try, put a box or two on JFrog Bintray today!

Enterprise Level Access Control with Keys and Entitlements


“Private repositories”, “Teams and Organizations”, “Permissions”…, sounds like that’s all you need to provide secure private downloads. Well, not quite. Those are great features that fit the bill if your consumer is a Bintray user. But what if she isn’t? Well, then there are signed URLs. Those should do the trick. Just sign your file and send your consumer the URL. But what if you want to share an entire repository, package or version with a group of people, but need to give each of them different privileges. Some can only view or download your files, but others should be able to delete your files or upload new ones. Signed URLs don’t cover that kind of control. They are great for single files, but for more fine-grained access control, you need a more sophisticated feature. That’s where entitlements and keys come in.

“Entitlements,” you said? What are those?

Entitlements are privileges you can give anyone…yes anyone, not only Bintray users, to entities in your private repositories. “Entities” means anything that can contain files – a whole repository, a path within the repository, a specific package or a specific version. “Privileges” means “rw”  – download, upload and delete, or “r” – download only. If you didn’t notice, the combination of entities and privileges gives you any level of granularity that you need for providing access.

But how do you unlock entitlements?

I guess you get the hint. Keys unlock entitlements. You generate a key along with its password (or Bintray can generate one for you automatically). Your user will have to provide the username and password to enable the key that unlocks the entitlement. That’s where the security lies. Only users who have both the username and the password of the key that you provide to them can access your repository entities according to the entitlements you created.

So how does it all work?

Two simple steps using Bintray’s REST API:

  1. Create keys. You can supply a password for each key you create, or Bintray can generate one for you.

  2. Create entitlements. When you create entitlements, you specify which keys to apply to them.

Now all you need to do is provide your user with the username and password for one of those keys. Your user now applies a REST API to access your private Bintray resource while including the key and password you provided as parameters to the API call. Bintray will check if there is an entitlement that allows access to that resource, and if that entitlement has the key that the user specified associated with it.

Let’s see an example at work

Let’s say user “ACMECorp” has a private repository called “acme”.

This private repo contains several versions of acprod under the “acmecorprod” directory that are protected from public access.

ACMECorp wants to authorize a “platinum customer” to download the different versions. Needless to say, “Ms. Platinum” does not have a Bintray account.

First, ACMECorp needs to create a key. Bintray offers two ways to maintain control over keys that are distributed to outside users. The easy way is to just put an expiry date on the key. A more advanced method is to set up an internal server that is used to validate and authenticate keys, and provide the server URL to Bintray when a key is created. Every time a user tries to access ACMECorp’s repositories, Bintray will validate the key using  the URL that ACMECorp provided when creating it. Since ACMECorp is very careful with its key, let’s assume they want to validate keys with their own systems:

curl -XPOST -uacmecorp:APIKEY “
“id”: “key1″,
“expiry”: 7956915742000
      “url”: “,password=:password”,
      “cache_for_secs”: 60

Bintray creates a key and its associated password

Status: 201 Created
"username": "key1@acmecorp",
"password": "8fdf84d2a814783f0fc2ce869b5e7f6ce9f286a0"

ACMECorp now creates an entitlement that provides download privileges to the acmecorprod directory, while assigning key1 that was just created

curl -XPOST -uacmecorp:APIKEY "
"access": "r",
"download_keys": ["key1"]

Bintray responds:

Status: 201 Created
"id": "7f8d57b16c1046e38062ea3db91838ff77758eca",
"access": "r",
"download_keys": ["key1"]

Basically, that’s it. ACMECorp can now just provide the username “key1@acmecorp” and its password to Ms. Platinum who can now use them to access the acmecorprod directory in ACMECorp’s repository.

For example, to download version 1.0 of acprod, Ms. Platinum would use:

curl -XGET “” -ukey1@acmecorp -p”8fdf84d2a814783f0fc2ce869b5e7f6ce9f286a0”

But what happens now if ACMECorp and Ms. Platinum have a falling out. When that happens, ACMECorp can just delete the download key from their validation server and “Hey presto”, Ms. Platinum is now locked out of ACMECorp’s repositories.

Try doing that on Docker Hub,, NuGet Gallery, Maven Central or any other repository or download center out there. Bintray is the only one that provides you with this level of control over access to your private resources.

Is Docker Hub really the best way to distribute your images?

Docker is definitely one of the biggest things to hit the software industry in the last few years. Everyone is using Docker, and Docker Hub is growing rapidly serving over 45,000 images by now. But did you ever ask yourself if Docker Hub is really the best platform to distribute your Docker images. It stands to reason, but reason be damned; We think Bintray has an edge over Docker Hub and here are the reasons why.

1. Fine-grained access control

Yes, Docker Hub recognizes organizations and teams. You can have all the relevant people open an account on Docker Hub and then organize them in whatever way serves your needs to expose or hide registries as you see fit.

But then you want to send your #1 strategic client an early release

How does Docker Hub handle that? Well, you can ask for your customer’s account, and then include him in the right organization or team. But then, you need to be really careful with what you put in the repository you have exposed to him. Or you need to add him to a team, and later remove him. Manageable so far… But now he also wants his boss to see it, and later the CTO, and two weeks later, you find that your guy has just changed jobs and is working for your competitor. Did you remember to remove him from that team or can he still access your private repository?

Bintray removes this pain-point with entitlements and download keys

Bintray lets you create entitlements which define, in minute detail, exactly what part of a repository can be accessed – from a whole repository down to the level of a single path within a repository. You can define who has access by name, geographic region, IP domain and pretty much anything else. You can also limit that access to a very specific period of time. Once you have defined your entitlements, you can then create keys which unlock the access the entitlements provide. Your user needs to provide the key and its associated password each time he accesses a resource which he is entitled to. You can even define what kind of access each entitlement provides. It can be for download only, or for download, upload and delete.

2. Image and Version Level Stats and Logs

Ever wondered how many times your image has been downloaded? Of course you have; it’s a measure of success. But going beyond self-flattery, it’s not enough to know that magic number of downloads. Wouldn’t it be helpful to be able to know who downloaded your images and from where? Bintray gives you that. The stats pages on Bintray give you total numbers, but download logs let you segment the downloads by region, country, IP address, and even down to the specific user and organization. For your public repositories this can be really useful, but for your private repositories it’s critical for you to know who is accessing your packages and what they are doing in your repositories. You can read more about stats and logs in this post the Bintray Blog.

3. There is more to the world than Docker

allforone4Docker may be the best container to have ever hit the software docks, but at the end of the day, you are only using Docker to create a virtual world in which to run your products. And your products are built with packages that are Java, Ruby, NuGet, Python, Debian … and new formats hit the news all the time. How are you going to distribute those? Not on Docker Hub. So should you use Docker Hub for Docker and something else for all the rest? Well, if you can use that something else, aka Bintray, for Docker images too, then why not simplify your life (and scripts) and distribute all packages through Bintray.

All for one and one download center for all.

3.5. For Bintray, distribution is a core competency

Docker is making huge waves in container technology. This is their core competency; not software distribution. You can use Docker Hub to distribute your images, but you must ask yourself, “Will Docker Hub receive the same level of attention from its makers as container technology does?” Bintray’s scalable infrastructure is deployed on clustered servers in multiple data centers around the world, and currently serves over 200 million downloads per month of 200 thousand packages that reside in 50 thousand repositories.

That’s what we call a core competency!

Like Docker Hub, Bintray offers a host of great features like fast CDN downloads, a rich REST API for automation, searchable metadata and more. But like Docker is redefining container technology, Bintray is redefining software distribution. The service tiers offered by Bintray make it the best choice for distribution of both free OSS images as well as for commercial organizations that need enterprise grade software distribution features. Bintray lives and breathes software distribution; that’s what it does, and that’s where it will continue to evolve to stay the best solution for a download center, for Docker images and indeed for all other software package formats.  

Download stats and logs – now with deep user insights

Ever wondered who exactly downloaded your software? I don’t mean just “someone from the United States.” I’m talking about getting down to the organization level in terms of “someone from Acme Corp. NY office”.

Now you can get this information, from Bintray:
Bintray Live Download Feed

This information is available for any package type for Bintray Premium users, but that’s not all. It is also available, for free, for every OSS package in JCenter!!! This means that if you own a package that is linked to JCenter you already have this information available today!

And not only can you get rich live logs of your downloads, you can retrieve fully parsable logs in CSV or Apache common format! Just use the REST API, or click the preferred log format link:
Bintray Download Logs

Log format options include the Apache-style logs, which can be analyzed by dozens of tools out there, or you can download the logs as CSV files. CSV files are usually easier to understand, and actually contain more data, such as ZIP code, geolocation etc. Download the CSV log and hack on! Or, you can even open it in Excel and show it to your boss:
Bintray Logs in CSV Format
Excel jokes aside, that’s the most powerful downloads analytics one can get and it’s there at your fingertips.

With Live Logs and Download Logs you get much more detail about activity within your repositories. This can be very helpful in analyzing peaks as it provides immediate feedback on the popularity of your software, and how this popularity is distributed by version, geo-location and organization. Naturally, it can also be used to direct you to where you should be focusing your marketing efforts.

It’s time to learn about your users!