Why are there no maven packages for Jmonkeyengine? It’s nice that there is a complete IDE out of the box, but it seems like proper packages would exist also. Trying to use JmonkeyEngine within a maven or gradle project is turning out to be a real pain.
Chris
@snacktime said: Why are there no maven packages for Jmonkeyengine? It's nice that there is a complete IDE out of the box, but it seems like proper packages would exist also. Trying to use JmonkeyEngine within a maven or gradle project is turning out to be a real pain.Chris
Well, gradle at least would be easy. Put the jars in a directory, add those jars to your compile dependencies.
Maven is a challenge but none of us use maven and it’s “one of many alternatives” that do the same things as the SDK’s plug-in capabilities… ie: we’d be duplicating effort to support it.
There are a few threads around I think about how you can easily integrate JME builds into a maven project. There have been a few upstart-then-died attempts at the community keeping maven POMs ready to go.
<cite>@pspeed said:</cite> Well, gradle at least would be easy. Put the jars in a directory, add those jars to your compile dependencies.Maven is a challenge but none of us use maven and it’s “one of many alternatives” that do the same things as the SDK’s plug-in capabilities… ie: we’d be duplicating effort to support it.
There are a few threads around I think about how you can easily integrate JME builds into a maven project. There have been a few upstart-then-died attempts at the community keeping maven POMs ready to go.
reinventing the wheel because you don’t know how to use one of the existing package management systems seems a rather weak argument. I can tell just by looking at the jars that whoever put the build system together doesn’t know what they are doing. They should learn.
And just adding the jars as a dependency in gradle or maven doesn’t ‘just work’, because native libraries are not referenced correctly.
Don’t mean to be too harsh here, but seriously, it’s really not a defensible position. If the answer was we don’t have the time, or are waiting for someone to do it, I’d understand. But it sounds like even if someone put in the effort to do it the right way,the core team wouldn’t accept it. And that kind of deserves a rant imo:)
Chris
For the IDE, mavenization doesn’t help much. People hacking on the IDE already use the IDE, and all the build tools are already there and preconfigured.
For the engine, putting the jars on Maven Central would help. Almost all build tools can import code from that, it provides a standard place to look for sources and javadoc for each jar, and the uploader can tell it what the dependencies are. For the consumers of a library, it’s a tremendous help because it’s essentially a one-stop shopping point and their build tool will automatically import any indirect dependencies.
Uploading to Maven Central requires an account (easy), some pretty standard guidelines to follow (could be contentious), and jar signing (now that would require some setup).
Reasons why mavenizations might have failed:
@snacktime Native libs are simply included as resources, so nothing special needs to happen there. (There’s the obvious disadvantages but building Bullet or LWJGL from scratch isn’t easily mavenizable anyway.)
Just to demonstrate that “doesn’t know what he’s doing” is a double-edged sword that cuts both ways:
If you knew what you’re doing, you’d have noticed that the natives get included as resources.
The problem with an external contributor doing it, BTW, is a bit more involved than you make it out to be.
The core team won’t know whether the contributor will stay around to do any ongoing maintenance.
And the core team, since is has little Maven experience, has no easy way to assess the quality of a pom, so that’s a problem, too.
I’d prefer the jars to be on Maven Central myself, but since I’m neither willing nor able to guarantee that I’ll do that for any useful duration, I’m not pushing towards that goal.
Give that kind of guarantee in a convincing manner, and policy may change. Still, the proof of the pudding is in the eating - you’d need to demonstrate that it works and is useful.
@snacktime said: reinventing the wheel because you don't know how to use one of the existing package management systems seems a rather weak argument. I can tell just by looking at the jars that whoever put the build system together doesn't know what they are doing. They should learn.
Good luck with your game development.
I want to say OP was extremely rude and his tone was uncalled for.
I understand the core team does not have Maven experience and it makes sense that they will not switch to something they cannot maintain.
After reading this post there are some misconceptions about Maven that I feel I need to point out.
- The upload needs to be automated as part of the nightly build process. Independent attempts incur a high constant workload and/or process fragility.There is a command in maven for automated deployment to repositories. If Jmonkey team is using a build server (such as jenkins) this is extremely trivial.
Maven gets somewhat complicated if you need to include native components. It is workable and in fact not too difficult if you don’t build from sources but simply include the binaries, but any push towards Maven Central needs to recognize that.
I would opt to make the native libraries artifacts instead of resources.
The natural reflex is to upload each jar as a separate artifact. However, you get into a lot of work trying to find out what dependencies exist, and you’re promply in for a lot of work with nothing to show for it. The alternative is to merge all jars into a single jar and upload that as a single artifact, but that requires an extra plugin (maven-shade-plugin).
Dependency management is an important part of software development. In maven there are built in tools to find out your dependencies. Literally the command is “dependency:tree”. There are also plugins which will give you a nice looking graph. As far as the shading plugin goes, its extremely simple to use.
The JME directory structure does not follow Maven guidelines. Maven can adapt to that but it’s an extra hurdle to deal with.Yes Maven can adapt. The hurdle would be adding about 3 extra lines to the pom file to tell it the path to your sources.
Other notes
Again, I understand if the team doesn’t switch. I just wanted to point that some of the misconceptions about using Maven. I would be willing to answer any questions you may have.
Thanks for reading!
Source: I am a developer who is a lead on a large program that has roughly 80 projects/ libraries all managed by Maven and a Jenkins server.
After all you can always just upload the jme build result it to your local nexus and you are fine.
(If you dont use a local nexus / repository proxy, you probably don’t think maven trough anyway)
if its such an easy thing to do, why dont you just do it and make a contribution to the project, rather than post on the forums and complain about others not doing it for you?
(“you” being everyone complaining about the lack of POMs)
We do have a community effort to maintain an interim set of snapshots uploaded to a
Sonatype repo here:
https://oss.sonatype.org/content/repositories/public/com/jme3/
Basics of using such snapshots are discussed here.
The last snapshot was uploaded Dec. 20, 2012.
I am ready to post an update, but I first I need a current nightly-build snapshot
from the JME3 website, or else we need to decide that some equivalent download
is now the “best” set of such jars. But the nightly-download link at jmonkeyengine
website is broken.
Says “nightly builds” are at this URL http://jmonkeyengine.com/nightly/
which resolves to this URL http://www.jmonkeyengine.org/nightly/
which says “file not found” (in text, not a 404 error?)
Once we get past that, I will follow these steps to upload a snapshot.to sonatype.
The history of this community effort is documentent on the last few pages of this long trail
(see pages 5,6,7 for my involvement):
http://hub.jmonkeyengine.org/forum/topic/maven-hosting/
You can also find released versions of a single OSGi bundle/jar that exports a large fraction
of the core JME3 functionality under the Cogchar project (part of the larger http://glue.ai space that
my team works on). Last release is here in Maven central, but it uses the same underlying snapshot
from 2012-12-20.
http://search.maven.org/#artifactdetails|org.cogchar|ext.bundle.opengl.jmonkey|1.0.6.2|bundle
You could pull this bundle with the single dependency:
<dependency>
<groupId>org.cogchar</groupId>
<artifactId>ext.bundle.opengl.jmonkey</artifactId>
<version>1.0.6.2</version>
</dependency>
Working examples of that bundle in application use can be found in the friendularity.org project, specificially in the
subproject org.friendularity.bundle.demo.ccrk. If you build the whole friendularity tree from the root, it should automatically
download all the JME3 deps you need, and bring up a visualization that includes sinbad and some other stuff.
Soon we expect to post an updated youtube video showing some of the fun things we are doing with JME3 in Glue-AI, and
perhaps some stills from that video can be added to some JME3 showcase page or somesuch. All the glue.ai stuff is maven
based, so it can be seen as a working example of a large set of maven projects that use JME3, although our stuff
is also intended to run indepenedently of JME3, in physical robots. JME3 is essentially our simulation visualization canvas.
Thanks again to the awesome JME3 core team and community for building such a bodacious platform!
Thanks, that’s awesome.
It’s a bit behind - jbullet is going to be replaced by native bullet, I think some of the listed “dubious” dependencies are actually not part of the build anymore, and the finally the JME3 version number (once such a thing exists) should be used as the artifact version number.
But it’s good that this is being addressed at all 
We will move the build process to gradle at some point, then maven artifacts should be no issue at all. We will certainly not move to a maven build process, maven is only a choice if you don’t know about gradle I suppose 
The dependencies could be an issue for themselves, in the worst case we’ll have to supply some versions of libraries ourselves as there might be changes (jbullet) or the packaging might be not what we want (lwjgl/jogl) in the existing maven artifacts.
I understand some people only worked with maven and eclipse but please, it is NOT a standard by any means. ANT is still the java standard and we’re happy to skip maven in favor of gradle. The repositories and versioning is the only good thing that ever came from maven.
I can only agree (and its rarly that normen and i are 100% same opinion on anything ^^) Grade is far superior, and a better choice.
This tarts with stuff like global excludes for all dependencies and ends with a dynamic flow (wheras maven has pretty much hardcoded phases and you cannot do much about)
Well, I have to disagree on one account: Maven is superior to Ant, so until the Gradle build comes out, a Maven build is progress.
The question is whether the Maven team can pull that off - seems like they’re roadblocked by the failing nightlies. (Building from sources should work.)
Oh, and one more thing: The Gradle build (when it finally comes) will have to upload artifacts to some Maven repository. Leverage the experience the maven guys are collecting instead of jeering at them. You’re about to chase away people who want to contribute after all.
I don’t “jeer” at anything but maven itself and we will not change the build process to maven “just because”. But I don’t think thats the aim of this project anyway.
You can embed the engine into a maven build process easily, as you indicated its more powerful than just having a list of precompiled libraries. This (making your own repo) is one way, another is outlined in the wiki.
Its great that people make the things that work for them available, thats what we do too
<cite>@normen said:</cite> we will not change the build process to maven "just because".
Nobody is asking anybody in the JME team to.
<cite>@normen said:</cite> But I don't think thats the aim of this project anyway.
Then I don’t understand what point you were making.
<cite>@normen said:</cite> You can embed the engine into a maven build process easily, as you indicated its more powerful than just having a list of precompiled libraries. This (making your own repo) is one way
Embedding the engine into a build is far from easy.
It would be FAR easier if the engine were available from a Maven build.
(I could go into details but I’m trying to keep this focused.)
<cite>@normen said:</cite> another is outlined in the wiki.
Except “ant zip” fails because no zip files are generated into sdk/dist.
@toolforger: I can’t see the big issue adding the jme to a local repository (or a central if you work in a team). What’s the problem about that?
@toolforger said: Nobody is asking anybody in the JME team to.Then I don’t understand what point you were making.
Embedding the engine into a build is far from easy.
It would be FAR easier if the engine were available from a Maven build.
(I could go into details but I’m trying to keep this focused.)Except “ant zip” fails because no zip files are generated into sdk/dist.
@ceiphren Having a central repo saves everybody the hassle of trying to get a build to work.
Also, setting up and managing your own Maven repo isn’t in scope for all teams at all times. You need to commit to running a server reachable from all team members (the repo server), even before you know whether the project will even work out. I.e. yet another barrier to adoption. (Sometimes I suspect that’s on purpose, at least by some team members.)
Lastly, Gradle users don’t need or want to set up a Maven repo.
@normen
a) nobody was talking about turning the build process to maven, nobody wants to branch JME, that’s just irrelevant aspects
b) maven users want stuff at Maven Central; a repo on the jme website is an acceptable substitute as long as it stays up but Central can throw more resources at keeping the servers up and running so Central is still somewhat better
c) I know and loathe Maven as anybody else here but no it’s not easy, partly because Maven, partly because JME is a pretty complicated project from a Maven perspective, partly because no nightlies are availble and you’d have to build from source - so: doable but definitely not easy
d) The wiki pages on Maven are outdated (Dec 2011 it seems), post a link to the pages you’re talking about
@toolforger said: @ceiphren Having a central repo saves everybody the hassle of trying to get a build to work. Also, setting up and managing your own Maven repo isn't in scope for all teams at all times. You need to commit to running a server reachable from all team members (the repo server), even before you know whether the project will even work out. I.e. yet another barrier to adoption. (Sometimes I suspect that's on purpose, at least by some team members.) Lastly, Gradle users don't need or want to set up a Maven repo.@normen
a) nobody was talking about turning the build process to maven, nobody wants to branch JME, that’s just irrelevant aspects
b) maven users want stuff at Maven Central; a repo on the jme website is an acceptable substitute as long as it stays up but Central can throw more resources at keeping the servers up and running so Central is still somewhat better
c) I know and loathe Maven as anybody else here but no it’s not easy, partly because Maven, partly because JME is a pretty complicated project from a Maven perspective, partly because no nightlies are availble and you’d have to build from source - so: doable but definitely not easy
d) The wiki pages on Maven are outdated (Dec 2011 it seems), post a link to the pages you’re talking about
a1) No you don’t need to set up a repo to embed jME in maven, did you even readthe wiki page on it? Note that many people do changes to the engine anyway, very common esp. for game engines, so users should better be able to build it.
a) So what would be the “contribution” I seem to keep somebody from making in your opinion? Was that just irrelevant aspects?
b) I didn’t talk about where to host it, irrelevant aspect.
c) Effin childs play.
d) Pff https://wiki.jmonkeyengine.org/legacy/doku.php/?do=search&id=maven