Bintray alternative?

We recently started using bintray for some of the Micro-Manager dependencies. It appears that bintray will soon close down. What alternatives will people be using? The free tier on JFrog (10GB transfer per month) may or may not be good enough. Back to setting up self-hosted repos?

2 Likes

Hello! Sorry to just jump in, but have you considered Cloudsmith as an alternative? It more than matches the capability of Bintray. I work there, so happy to help with any questions. :slight_smile:

1 Like

Hey @nicost ,

How do you know? The website looks ok :upside_down_face:

Thanks for the pre-warning!

Cheers,
Robert

May 1st, 2021: Bintray services will no longer be available.
see here

2 Likes

Is maven central an option ? If not, why not ?

1 Like

@skalarproduktraum has experience with maven central. Ulrik, can you tell us how complicated it is to deploy there?

I have deployed there in the past as well (Maven Repository: edu.ucsf.valelab.tsf » tsfproto). Rules for deployment there are more strict, and demand that all requirements are provided, which in the case of Micro-Manager has not been easy. Also, uploads are a multi-stage process (through Sonatype?) that take some time to become active. Sonatype may offer a service for snapshots. My memory is vague, would be great if someone has current advice.

1 Like

TL;DR: Setting up Maven Central is a bit of a pain, publishing then is simply mvn deploy (plus some parameters).

Hi there! We’re deploying to Sonatype, and after initial (slightly painful) setup it works pretty well and without issues. You need to register your package ID with them (and provide proof that the domain or URL belongs to you or you have access to it, so you can’t have any fantasy IDs), after that you can deploy. In contrast to Bintray or SciJava’s Maven, all packages have to be signed, so if you are deploying from CI, that’ll be a bit of a pain.

Snapshot releases are auto-deployed, while releases, as @nicost mentioned, are first staged, and then manually released. This is a bit more cumbersome, but all in all a good process, as you can check if your release is complete before putting it out in the wild. Releases, once published on Maven Central are immutable, so it’s good to check them before clicking “Release” :slight_smile:

When I was setting the entire thing up for scenery, I was following some guide. Happy to dig that one out or provide more interactive help on gitter :+1:

EDIT: This guide provides quite a good summary on how to publish to Maven Central.

2 Likes

Why not use maven.scijava.org ? It aims at making deployment of Maven artifacts easy for the ImageJ and related communities, without all the requirements that Maven Central has.

In addition, if your project inherits from pom-scijava, there’s a lot of tooling in place in scijava-scripts to make deployment easy.

If you just want an easy way to pin to a specific commit in your git repository, you can also use https://jitpack.io/ (@skalarproduktraum is using that as well, right?)

1 Like

I agree with @imagejan. LOCI maintains maven.scijava.org as a stable binary deployment target. It works especially well for JAR files, but you can deploy whatever binaries you want there, including bare native libraries and/or executables, if that’s useful to you.

We also have downloads.imagej.net for binary ImageJ things e.g. ZIP files. I’d also be happy to spin up downloads.scijava.org to serve Micro-Manager binaries, if you’d rather Micro-Manager be branded under the SciJava umbrella rather than specifically ImageJ. (Sorry I don’t have a more general umbrella layer that isn’t “Java” flavored… I wish we’d been able to think of a better name than SciJava back in 2011, but it is what it is. What about downloads.image.sc? Eh? Eh? :smile:)

Both maven.scijava.org and downloads.imagej.net are publicly accessible via read-only rsync, so that other organizations can mirror them, and some already do so (e.g. Oxford). In future, I hope to add a CDN layer to make downloads faster for people all over the world.

@nicost If you want to use either or both of these resources, please let me know. Another option to consider is GitHub Releases, depending on your needs.

Finally, about deploying to Maven Central: we did a lot of work to make deploying to Central easy as long as you use Maven for builds and extend the pom-scijava parent. There is a script release-version.sh that makes doing releases trivial. See the docs.

2 Likes

Is there some kind of of step by step protocol how to do this. For starters, when I follow the link Nexus Repository Manager it brings me to a page with a Login link, but no link to make a new account (and my very old Sonatype password does not work). So step 1 for me, is how to get an account on that site (or do I already have something that should work?)

1 Like

I think this is what comes closest:

You can either:

  • activate your repository on Travis (you can log in with your GitHub account), and then ask here that one of the ImageJ/SciJava developers files a pull request on your repository (e.g. I can do that), adding the deployment part; or
  • directly ask @ctrueden for the (encrypted) SciJava credentials, so you can run travisify.sh on your own.

I am very sorry, but there is a lot here I do not understand. Travis appears to be some kind of continuous Integration (CI) tool that we are not using or were planning on using. Does this mean that we can only publish on maven.scijava.org if we go through this Travis tool? That adds extra complexity that I am not looking for.

What is the simplest way to get the packages that we now publish on bintray (Bintray) in maven.scijava.org (or elsewhere)?

1 Like

Sorry, I misunderstood your intent and thought you’d also want to adapt the “SciJava way” of deploying via continuous integration (as it’s the only way I know of, and it’s really easy once set up, so I’d recommend it).
But it’s certainly possible to deploy directly to maven.scijava.org with valid credentials. I’ll have to leave it to @ctrueden to answer this, as I don’t know any details.

The complexity for us is that the project also contains loads of C++ code that is build on multiple OSes, and that there are bindings to Java and Python build using Swig. We are in the process of compartmentalizing that build infrastructure as much as we can, but the “SciJava way” is not a 1:1 fit that we can adopt at moments notice.
I can create a maven compatible deployment that I can drop wherever. For me the most important thing is to discover the best place to do this, not to set up a completely new build system in the interim.

2 Likes