If you use maven, you can just modify the gradle build of jme to upload all artifacts to your own nexus/artifactory server.
Btw, the gradle build also works fine with eclipse, just add eclipse plugin to subprojects.
Sorry but jme3-jogl is missing:
https://github.com/jMonkeyEngine/jmonkeyengine/tree/master/jme3-jogl
whereas JogAmp (JOGL, JOAL, JOCL, …) is on Maven Central:
http://search.maven.org/#search|ga|1|jogamp
Yeah, handling natives the way we do it with the packaged binaries (JOGL and LWJGL) as they are in maven isn’t really possible, although we did make it work theoretically (if you only include the correct platforms). We also have a dependency on our own build of jbullet so if we provide maven artifacts we’d have to provide that as well. Thats not to say that there will never be maven artifacts for the engine.
The main reason this isn’t a special focus of us is that jME sees itself more as a platform than a simple java library. We also abstract things like file access etc. to ultimately provide a truly platform independent system which then depends on deployment options of the SDK etc. again. Still you can use all the bits in your own setup if you are proficient enough. And we don’t reject the normal java economy either, you can easily use maven artifacts in SDK projects.
I don’t see how using an outdated pre-release version of the engine just because its maven does any good if we’re talking about maintaining standards so I presume this is mainly about laziness and IDE preferences.
Maybe I just don’t understand, how it is supposed to work in bigger teams then. I’m not a game developer, but a java enterprise application developer, so I’m just used to accessing as many dependencies as possible via Maven Central, and to coordinate version upgrades this way.
So I suppose with JMonkey the idea is to be bound to the complete set (IDE + libraries), and if you want to upgrade, the team all downloads the same new version (IDE + libraries)?
I have to admit, that I’m a fan of IntelliJ Idea, and I’ve used that until now to play around with JMonkey.
On the one hand, I think it’s cool, to just put a build file somewhere, execute e.g. ‘gradle run’, and my app pulls in EVERYTHING I need in the correct version, and if I import this file in any IDE with Gradle/Maven support, I can just start working.
On the other hand I’m not professional enough to judge the features I’m missing, if I don’t use the complete JMonkey IDE…
What I see though, is that I’ll need a build file anyway, and then I’ll manage some dependencies in my build file and some are included, makes it less easy to maintain in my view. While on the other hand, I think the JMonkey IDE would seamlessly integrate with Gradle/Maven to pull in the library itself 
If library and IDE develop in parallel and it always makes sense to upgrade library and IDE together, I can on the other hand see the argument to bind it together as strongly as it is now…
PS: I’m aware, that I can publish the lib version I want to my own Nexus and pull that in (I also did this in the past), but if everyone does that himself, it’s kind of beating the convenience Maven Central always offered
@pete83 said: Maybe I just don't understand, how it is supposed to work in bigger teams then. I'm not a game developer, but a java enterprise application developer, so I'm just used to accessing as many dependencies as possible via Maven Central, and to coordinate version upgrades this way. So I suppose with JMonkey the idea is to be bound to the complete set (IDE + libraries), and if you want to upgrade, the team all downloads the same new version (IDE + libraries)? I have to admit, that I'm a fan of IntelliJ Idea, and I've used that until now to play around with JMonkey. On the one hand, I think it's cool, to just put a build file somewhere, execute e.g. 'gradle run', and my app pulls in EVERYTHING I need in the correct version, and if I import this file in any IDE with Gradle/Maven support, I can just start working. On the other hand I'm not professional enough to judge the features I'm missing, if I don't use the complete JMonkey IDE... What I see though, is that I'll need a build file anyway, and then I'll manage some dependencies in my build file and some are included, makes it less easy to maintain in my view. While on the other hand, I think the JMonkey IDE would seamlessly integrate with Gradle/Maven to pull in the library itself ;-) If library and IDE develop in parallel and it always makes sense to upgrade library and IDE together, I can on the other hand see the argument to bind it together as strongly as it is now...PS: I’m aware, that I can publish the lib version I want to my own Nexus and pull that in (I also did this in the past), but if everyone does that himself, it’s kind of beating the convenience Maven Central always offered
As was explained, jME is not just a library that we can insert as is to maven central and be done with it. So what you effectively suggest is that we do the integration work for your desired platform for you, right now. I said that maven artifacts are possible in the future already.
And yes, as I explained as well, the IDE has functions that allow you to manipulate extended/external features of the engine which logically results in the projects being IDE specific. But we even use an universally compatible external project format, namely ANT, if your IDE supports ANT you can open a jME project as it is, so if “your developers” want to use another IDE they can.
Generally no java developer should have issues integrating jME into any build setup, one should expect a developer to be able to master the build environment of his choice. We never have heard of any professional development team that had issues embedding jME into their environment but we did have a lot of theorizing of people about why doing this or that would be better.
Please understand that when we explain why we don’t do something (right now) theres no need to further describe the benefits of still doing so, most of the time they are obvious anyway. For the whole engine and SDK, its an open source project that people created in their spare time and put out for free for others to use. None of the people involved need to be educated about development practices, fancy new build systems, new shader pipeline technologies or anything like that without a contribution or example for the implementation.
This thread is the best example for the lack of commitment that people who suggest that maintaining repositories, libraries or code is such an easy thing to do bring with them. The jME libraries here are outdated still people use them and we get the backlash in the form of lengthy explanations we heard hundreds of times or people experiencing bugs that were fixed long ago.
Sorry if I touched a sensitive point there, I didn’t mean any offense (or ‘educate’ anybody), I actually just wanted to understand the build best practices with JME better, not criticize how the build is done.
I’m aware that this is community work and it’s really cool that something like JME exists as open source software!!! (I did not want to sound ungrateful, I do appreciate all the hard work!!!)
And I didn’t ‘demand’ that JMonkey should be in Maven Central ‘right now’, I just said it would be cool, if it was, nothing more, so if that provoked any harsh feelings, I’m sorry, didn’t know this was such scorched earth
Well the main problem with this is, that you need custom modification to it sooner or later for any large project, so having it in maven would not give you that much.
@pete83 said: Sorry if I touched a sensitive point there, I didn't mean any offense (or 'educate' anybody), I actually just wanted to understand the build best practices with JME better, not criticize how the build is done. I'm aware that this is community work and it's really cool that something like JME exists as open source software!!! (I did not want to sound ungrateful, I do appreciate all the hard work!!!) And I didn't 'demand' that JMonkey should be in Maven Central 'right now', I just said it would be cool, if it was, nothing more, so if that provoked any harsh feelings, I'm sorry, didn't know this was such scorched earth ;-)
Its not the topic, its the pattern.
Regarding outdated-ness:
As I posted above on April 22, the latest version of JME3 engine published to
Sonatype-public repository is now based on the JME3 stable build of 2014-03-25.
Meanwhile, the latest stable build of JME3 engine now appears to be
jME3_2014-04-25.zip, which I have just downloaded to my desktop, but
not yet uploaded to Sonatype-public.
(@goussej, I don’t see where there is any “jme3-jogl” jar in either of these
stable builds. It appears to not be part of the JME3 released builds at this time.
That is an issue with the JME3 nightly build, not with the maven snapshot of it.
Please confirm by looking at the nightly build zips yourself).
So, as of right now, the Maven snapshot is exactly one month out of date.
Reviewing a few more specifics to help clarify where things stand today:
The procedure we follow for doing a release to sontaype-public is here:
jme3-maven/README_sonatype_upload.txt at master · erlend-sh/jme3-maven · GitHub
…with the key step being to update and run this script:
jme3-maven/upload_jme3_to_sonatype.sh at master · erlend-sh/jme3-maven · GitHub
You can see that all we’re doing here, really, is copying the JME3 engine jar files
into an online directory structure (sonatype public) that conforms with Maven
repository specifications. The jars themselves are not modified during this
process. This uploading is all we are are required to do in order to
deliver SNAPSHOTs usable for client code builds. To produce full releases
(visible through “Maven central” search engine) would require some additional
work, and provide additional benefits.
Example wrapper project using these snapshots, with one pom.xml file and one (trivial) .java file:
If you copy the dependencies from that pom.xml into your own, and then set:
<jmonkey.version>3.0.0.20140325-SNAPSHOT</jmonkey.version>
…you are all set for working with that (not terribly outdated) version.
@stub22 said: I don't see where there is any "jme3-jogl" jar in either of these stable builds
In the “opt” folder.
1 Like
Aha, thank you @Normen. I see now there are quite a few jars in the “opt/” folder. We have not so far made any of those part of the maven upload. It only uses the jars from “lib/”.
So, @goussej, you were right. Those “opt” jars are part of the JME3 download, but not in the sonatype maven repo. Thank you for pointing this out.
The jogl folder appears to include quite a lot of platform-native variant jars, as Normen referred to before, so we’ll probably want to think a minute about costs/benefits before simply uploading each of those to a separate maven artifact under the existing groupId (com.jme3). It might be better to create a new groupID: com.jme3.opt? Lots of other solutions are possible, naturally.
1 Like
Hi,
first of all: Thank you for putting your time into deploying the jme engine modules to the sonatype repo.
I have one small request: It would help a lot if you could also supply the corresponding source code to the repository. This would allow maven2eclipse to automatically download those sources when required, so we can view them.
Right now we have to download the sources from github using a commit that was made around the time of the snapshot. That’s not really precise as we don’t exactly know if the source corresponds to the binaries.
Thanks!
Some of you, could be interested by my workaround:
- download the zip
- publish each jar with “right” dependencies into my local maven repository
To automate the process I use “fake” gradle project.
I share the “project” GitHub - davidB/jme3_lib2repo: install jme3 (jmonkeyengine 3.0) into local maven repository.
git clone https://github.com/davidB/jme3_lib2repo.git
cd jme3_lib2repo
cd jme3 && ../gradlew downloadJme unzipJme install && cd ..In the github project, I did the similar job for lemur, zay-es (you can ask, PR for other).
@david.bernard.31 said: Some of you, could be interested by my workaround:
- download the zip
- publish each jar with “right” dependencies into my local maven repository
To automate the process I use “fake” gradle project.
I share the “project” GitHub - davidB/jme3_lib2repo: install jme3 (jmonkeyengine 3.0) into local maven repository.
[code]
git clone GitHub - davidB/jme3_lib2repo: install jme3 (jmonkeyengine 3.0) into local maven repository
cd jme3_lib2repo
cd jme3 && …/gradlew downloadJme unzipJme install && cd …[code]
In the github project, I did the similar job for lemur, zay-es (you can ask, PR for other).
Yep, as was indicated a lot of times, people who don’t just call themselves java developer should have no issue embedding jME in their build process.
no real issue except, some time “wasted” in setup (vs ready to used). It’s why I share it, to allow other dev to work on there main goal than to setup build env.
I used the same groupId/artifactId than in master branch of jme (on github), so “just” by changing version number of jme I can switch my project between releases and master.
Yep, as was indicated a lot of times, people who don’t just call themselves java developers write their code directly as byte code. Yes it sucks, yes it’s inconvenient, but hey, if you’re a “real developer” you will do it anyway, right?
Seriously, you don’t wanna offer maven, that’s fine, but don’t pretend that it has anything to do with being able to include a lib in a build, it’s about speed and convenience, not about capabilities. I can get a good old assembler lib up and running, too, but is it fun? -No…
So if this pisses off somebody, me dispiace, but statements like “if you want it more automated, more convenient, you’re not a real developer” piss me off…
Hi
I agree with pete and I hope nobody has felt offended. I just hope that maintaining two build paths (gradle, maven) won’t be a problem. I already maintain another engine supporting Maven and it’s really cool:
- mvn clean
- mvn install
- I copy all JARs located in /target/ into my projects not based on Maven, the others just point out to Maven Central or to an alternative Maven repository
It’s really convenient. Eclipse and Netbeans have an excellent Maven support. However, normen isn’t wrong. When you already know where to find JMonkeyEngine’s JARs, embedding them into your project isn’t difficult, you can even use your own script to do that. What I like is that when you use Maven, you don’t have to think about that, you obviously know where to find the JARs produced during the build process by convention, whatever your Maven project. I understand the wish of convenience but I wonder myself whether someone who doesn’t succeed in embedding JME into her/his project wouldn’t have some difficulties to write an application with it anyway. I hope I hurt nobody :s
@pete83 said: "if you want it more automated, more convenient, you're not a real developer" piss me off...
Well then you piss off yourself because nobody said that.
Gradle build can upload the artifacts with addition of a few lines in a maven compatible style.
uploadArchives {
repositories {
mavenDeployer {
repository(url: "$repositoryurl" {
authentication(userName: "$user", password: "$password")
}
pom.version = version
pom.artifactId = project.name
pom.groupId = "com.jme3"
}
}
}As a quick look at githubs forks show many users are customizing jme for their use anyway.
@EmpirePhoenix , your suggestion only work for upload, not for local install. I have to change it in JME3-JFX to be able to install in local repository (I’ll do PR)
build.gradle
apply plugin: 'maven'
...
version = ...
group = "com.jme3"
task packageSources(type: Jar) {
from sourceSets.main.allSource
classifier = 'sources'
}
artifacts {
archives(packageSources) {
type = 'jar'
}
}
uploadArchives {
repositories {
mavenDeployer {
repository(url: repositoryurl) {
authentication(userName: user, password: password)
}
}
}
}
settings.gradle (to explicit project name)
rootProject.name =...