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).
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.
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.
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.
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?
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.
Javadocs are published on bintray along with source and binary archives for each version - see Service End for Bintray, JCenter, GoCenter, and ChartCenter | JFrog. 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.)
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 jmonkeyengine.org 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.
