Maven central deployment (inofficial, script, for testing)

I started a little bash script to deploy jme jars to maven central. It is located at:

Feel free to fork and contribute. It can also easily be modified to install files plus javadoc into your local maven repository.

There is also a test project for the results:

That’s a maven project which extracts some of the jme examples and runs them. It can be used as an example on how to currently use the deployed jars.

Nothing has been released to maven central yet because I need a few people testing the results first, ie. switch full-blown projects to using the produced jars. A preliminary deployment is at:


Current and official maven-compatible deployment is at org.jmonkeyengine - Maven - Bintray - though it has currently (as of 3.2.1) no javadocs attached. So, current differences between the two deployments is: official vs inofficial, no javadocs vs javadocs, jcenter vs maven central (eventually).

JME is already in jcenter which is waaaay easier to post releases to. There is 0 reason to have it in maven central, really.

There are plenty.

  1. Maven does not recognize jcenter by default. Adding repo statements to descriptors is discouraged.
  2. jfrog is a commercial company, they can dump/do whatever they want, maven central isn’t.
  3. The released stuff at jcenter is outdated.
  4. That jcenter is easier to use is pure PR. I know how to use maven central. It’s extremely easy to use.

No. The stuff in jcenter is the latest official release. Are you suggesting to upload snapshots to maven central? I was pretty sure that was forbidden.

Well, I’m only going by a few years ago when I tried. The requirements of the POM were extensive just to get approved. There is none of that with Jcenter. You uploaded and click publish. One certainly sounds easier to me. Maybe they have removed these restrictions.

If so, then publishing to maven central is just a matter of clicking a button on the bintray site.

Edit: the requirements for central are much easier than they used to be… but still not as easy as jcenter:

this shows 3.0.10. or do I have the wrong site?

Central sets some absolute minimum requirements, yes. I don’t see how any halfway decent project would want to omit them, ie. like adding authors/maintainers, license, inception year etc.

That’s generally true of pretty much any service, commercial or otherwise. If jFrog did decide to drop jME/open source projects/etc., it’d be easy to redeploy elsewhere.

jME’s project identifier changed after 3.0. Up to date builds are at: org.jmonkeyengine - Maven - Bintray

Caveat: I’m just a jME end user - I have absolutely zero connections to the development team or say in where/what gets published. Just my 2 cents, for what they’re worth.

hm kay, ty.

But no javadoc files. Maybe some of the devs would want to fix that and include javadoc with the maven deployment. I think adding javadocJar argument to gradle build could be enough for that.

I heard that deploying from jcenter to maven central is as easy as clicking a button somewhere. Meybe someone can do that? :slight_smile:

And to redeploy to somewhere else is only easy if you don’t use external dependencies from some mixture of sources, too. GL with that. Because then you are really screwed. And that’s exactly why external repositories are discouraged.

You can find up-to-date Javadocs at: (just in case you hadn’t seen those already).

Javadocs are published on bintray along with source and binary archives for each version - see Package jme3-core - jmonkeyengine. I’m using Buildship on Eclipse and it’s kind enough to automatically download the Javadoc jars and provide documentation with completion suggestions.

Ah, good ol’ dependency hell. So far as I know, jME does not have many (any?) external dependencies. At least one dependency I’m about 99% sure is hosted alongside jME code on GitHub, and I’m not sure if it bundles LWJGL/JOGL itself or relies on them as external dependencies. I do know that its external dependencies are minimal and are themselves major projects (not going away if hosting situations change).

(In general I do agree with your concerns about spreading dependencies around - I’ve had to use NodeJS at my day job, and even when everything is coming from NPM it gets nasty at times.)

sry, but I really can’t find any javadoc jars. I only see the main jar and -sources.

My bad - Javadocs are up for the 3.1.0 series of releases, but not the 3.2.0 series.

Something may have gotten broken in the scripts that build the releases. javadoc is always supposed to be built and uploaded with the release. Unfortunately, I don’t maintain those and barely understand them.

That’s a serious problem, though. @Momoko_Fan any idea why the javadoc jars stopped being generated/uploaded?

Yep, because com.jme3 isn’t a domain we own or plan to. Someone else already has it and we already had the domain.


Actually, this is the part that I hate the most. It either implies that it’s completely stale and useless information (who would we put for JME? Core devs? Only active core devs? How active? What is activity?) or has to be compiled all the time from contributors. Yuck.

The developers section is one of the things I stumbled on when I looked this a long time ago… it’s kind of too bad that it’s still there. Being able to leave it as just an organization would be so much more useful for many open source projects.


It looks like it broke with this commit: build: upgrade to gradle 3.2.1 · jMonkeyEngine/jmonkeyengine@f895d88 · GitHub

It disabled building javadoc by default. I re-enabled it, so the next release should have javadoc included