Sunset on May 1st: Bintray, JCenter

General Discussion
1

How does this affect jME?

3 Likes
2

@Darkchaos notified about it before on discord.

well we use jcenter() in gradle, but we will probably need switch to mavenCentral()

tho not sure if repos will need to be reuploaded or not. (or if there is github action that need update)

1 Like
3

Sucks.

4 Likes
4

So if I’m understanding this correctly, JCenter is going away entirely? So no more centralized Maven-compatible repo outside of Maven Central?

1 Like
5

looks like :smiley: Paul reply explain everything

2 Likes
6

I’m having flashbacks to 2015, when everything had to migrate from Google Code to GitHub.

1 Like
7

I’ve done a little research. So far, the best plan I’ve got is to migrate all our Maven repos to OSSRH:

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

Looks like the first step would be to create a JIRA account. I haven’t done that yet. Does anyone here have a JIRA account?

1 Like
8

i had JIRA account in previous work, but isnt this just tool for work-managment tickets?

also not sure if its free to have account, also how OSSRH is related to it.(except it need account)

Cant we have repos just in mavenCentral? i seen some old JME repos were there already.

There is also just option if Riccardo could host Nexus repository website where we could store any repos.

1 Like
9

A custom hosted repository is the single worst option though, I guess.
We need to maintain it, everyone depends on us keeping the service up and it’s stability etc.

But yeah, can’t we get approved for MavenCentral?

2 Likes
10

yes, i also agree its worst option to host it, but just say its possible, since we host HUB/etc anyway :slight_smile:

11

My recollection of maven central is that the approval process is very difficult. JCenter was really nice and easy.

Maybe it’s gotten easier in the last ten years, though.

The biggest crappy thing will be all of the projects I have that have jcenter script to upload releases. :frowning:

2 Likes
12

Yes, but it looks like a Jira account on Sonatype is required to publish artifacts. See this step-by-step on DZone. There is also a gradle plug-in available that is supposed to turn tasks related to publishing easier.

I agree with @sgold and I also think that OSSRH is the way to go.

1 Like
13

We could use github packages.

EDIT: Imagine all the software that won’t compile anymore… I need to go though my company’s code and make sure we are not impacted :frowning:

2 Likes
14

Requiring users to add non-standard repositories is not an answer.

We’ll have to jump through the hoops to get into maven central. Then everyone’s builds will continue to work. The really painful part will be moving all of the older versions over as I don’t think bintray provides a convenient ‘download everything’ button.

I wonder if jfrog will survive one more year or two before shuttering completely. This is the kind of business decision only made because of desperate cashflow projections because of the brand-damage that will occur. I guess they must have felt it was the only way. Just a shame that their business model must have been broken.

3 Likes
15

My last experience with Maven Central and Sonatype was… fine… I guess.

You have to prove ownership of the jmonkeyengine.org TLD via a DNS entry - Then, your ticket gets approved manually (You create only 1 for the org.jmonkeyengine group and afterwards, you can do everything in there as you please without interaction with them directly). And everything following is fully automated. I don’t know how it works for jCenter, but for Maven Central you have to sign all jars, so there is a bit of setup you have to do in the build and in your settings.xml (with the credentials), but once that is setup, it’s really just a “mvn clean deploy” and the rest is automated. It also doesn’t take more then a few minutes until a new version is available to the world.

So, it’s not the mooooooost convenient pipeline (for good reasons, i.e. preventing phishing), but it works fine enough I would say. Ultimately, I think it’s a good step to move directly to the official maven central, but that’s just a personal opinion as I don’t know anything about jCenter and might miss a few points. Good luck with the transition!

3 Likes
16

Last time i checked, github packages required the users to be logged in to github to pull the artifacts. So i guess this option is off the table, at least until they will (if ever) allow anonymous pull.

It seems migrating to maven central might be the best option, however we would probably need to do something about the jme3-testData artifact, that is pretty large and contains only assets (iirc we couldn’t push that to jcenter either), this one can be hosted on our http server (or anywhere else…).
Also the natives are snapshotted on bintray, so we would need to provide a replacement for that too (that can be again our server).

So, to summarize, we can have this setup:

something.jmonkeyengine.org can be a Minio instance, a very minimalistic object storage that requires basically no setup and is api compatible with aws s3 (that’s defacto the industry standard for object storage), it can also function as a proxy to other s3 compatible backends.

3 Likes
17

If I have to run maven for my non-day-job projects, I think I may abandon them. Hopefully there is a gradle solution.

2 Likes
18

Oh, I’m 99% sure (Haven’t tried yet) that all of this is also possible with Gradle - I just happened to use Maven for the 2 projects I did in the Sonatype repo so far.

2 Likes
19

We thought that this is the case but eventually did it.
Same with jbullet where we thought we had lost the source code.
Maybe MavenCentral is more strict with that, we need to check all of that.
That doesn’t solve the natives issue, though.
I’m also affected with Service End for Bintray, JCenter, GoCenter, and ChartCenter | JFrog,
it’s required for the iOS deployment [but that’s a minor thing, mostly writing it here so someone can remind me in case I forget]

1 Like
20

I’ve created a JIRA account. As a test case, I submitted my “Heart” library for publication.

2 Likes