Ah ok, I somehow assumed a artifactory/nexus repository.
But of course a local install should also be supported.
(-> it is really easy to install, and then your whole team can use the same artifacts.)
…just that the gradle build isn’t stable.
I did some experimentation to publish artifacts to sonatype repositories (and local repository):
- from “master” -> snapshots repository
see Index of /repositories/snapshots/net/alchim31 - from version 3.0.0+2014-06-12 -> staging repository
I didn’t deploy to central, missing javadoc + sources + list of developers
For master, I modified the build :
- to use the gradle-nexus-plugin
- to use the groupId net.alchim31.com.jme3, where I can deploy
- to not deploy javadoc, (failed to generate)
- to include pom info (licences, homepage, …)
- to try to not publish testdata-sources (it’s the longest to upload 45MB x 2 (jar + sources) )
On the command line I disable SDK and force version to be -SNAPSHOT to publish on snapshot repository (else it’s release)
gradle -PbuildSdkProject=false -PjmeVersionTag=SNAPSHOT uploadArchives -Psigning.password=...the commit : build: deploy to sonatype's nexus · davidB/jmonkeyengine@7edabc0 · GitHub
For release, I customise my project jme3_lib2repo to use gradle-nexus-plugin.
If jme’s developer are OK.
- I can PR my change
- I’ll try to deploy ~ 1 SNAPSHOT / Week (until manage by CI), I’ll need to be authorized to deploy to com.jme3
using lib, and repo, will be a big simplification for lib and final app that used jme, (eg: my projects ;-), jME3-JFX )
For the last few years, I have been responsible for publishing SNAPSHOTs to the com.jme3 group on oss.sonatype.org.
I am very pleased to see that there is a new stream of snapshots being pubished to group net.alchim31.com.jme3,
using these gradle based scripts.
However, I would have some concerns to work through before we replaced the current SNAPSHOT publishing process for group com.jme3, as David just proposed.
I think what would be most valuable to the jme3-maven community right now is to focus on getting a RELEASED delivery of JME 3.0 engine published as a permanent, public release in oss.sonatype.org (and thus in Maven Central).
@david.bernard.31, is that full-release of 3.0 something you would like to be involved in and do you think your gradle scripts are a good path towards a maintainable full-release process? Once that full release of 3.0 engine is permanently committed to Sonatype+Maven Central, I would feel better about revising the SNAPSHOT process for 3.1 going forward, and possibly turning it over to @david.bernard.31
Please do not do this. We don’t want our engine to be available via the official maven repo right now. Especially not with a different build script.
About the release, my script extract jar from official download and it currently miss to provide source.jar and javadoc. It is very similar to yours but :
- it uses gradle (instead of shell + maven)
- it is younger, I should miss some lib (opt,…) not used (except by me )
- it defines dependencies (not flat jar) in the pom.xml (based on 3.1 project info, in fact 3.0.10-github when I did it)
I try to keep same name groupId, artifactId as 3.1.0 / gradle project to ease the version switch (I often only change the variable for jme’s version).
Also, I use 3.0.0+YYYY-MM-DD as version, because in the distribution I didn’t see info like “it’s 3.0.10”.
About the missing jars (required to publish on central). I’ll try to create :
- a jme3-core-3.0.0-source with all source/**/*.java from the distrib
- an empty jar for source, other than jme3-core
- an empty jar for javadoc
I’ll publish on snapshot for review before than to central.
OK, I stop experiment to deploy 3.0.0 to central. But what about :
- 3.0.0+YYYY-MM-DD-SNAPHOT on snapshot repository, I can adapt the script quickly
- 3.1.0-SNAPSHOT on snapshot repository (via the change I made into official build script or others)
??
Normen,
I understand you can’t trust me as “publisher”. Let me introduce myself, I’ve got some XP as publisher (can be committed with google) :
- few years ago, I was mavenizer and publisher for some projects (openid4j, spoon, lift (a scala web framefork, may be the first), …)
- I was co-founder (and first admin) of scala-tools.org the maven repository for scala core and libs. (before oss.sonatype exists)
- I create few maven plugins for scala, yuicompressor, winstone, applet/jws
- for private (startup, …) I setup and managed nexus, artifactory (+ hudson/jenkins + sbt plugins)
- I also create a dependencies/download management in 199x before maven, but with lot of less success ;-).
I hope, it gives some info to help me gain trust point (at least about deployement on a maven repo).
Thats not the point, I trust any halfway intelligent programmer that he can pull this off. You can make a private maven repo for this any time but please don’t publish it to the public maven registry, it would automatically be associated with us. If somebody does this he should be in the core team. And for 3.1, it should not appear anywhere really, its definitely too unstable for use (in terms of coming changes).
I offer you, a near to zero overcost, to be available on public repo (for 3.0 and 3.1). With the switch to gradle I hope of “official” snapshot (nightly / weekly / montly) available on a public repository .
short version :
5 x Why “you don’t want com.jme3 on public repo” ?
Why “If somebody does this he should be in the core team” ?
long version :
SNAPSHOTs are unstables by definition. Snapshot’s users know the risk (breaking api, compatibility, availiablity of the jar …) : it’s at your own risk.
we (users) can used SNAPSHOT because :
- we need some of changes only available in master (in my case some bullet commit, some SDK update)
- we want to experiment the future (eg: gamma correction)
- …
- we want to improve the publication of snapshot and release (via feedback, patch,…)
you (jme’s dev) can used publication of snapshot to test the deployement before release.
Having jars (Release or snapshot) available in repo is a plus :
- no need to store jar into the scm repo :
- often jars are version less, scope less (test, runtime, ???)
- use storage space on server
- lot of less time wasted in tracking dependencies when you add/upgrade/remove libs
- ease to test/rollback version change in the dependencies
- to publish release to central, it’s mandary to have every dependencies available on central repo.
- allow dev to use it’s favorite java toolchain (ant, maven, sbt, gradle, …, eclipse, netbeans, idea,…). I used eclipse to code, because I prefer it and jmonkeySDK doesn’t support jdk8 (I used the SDK only for asset).
- avoid dev to have to checkout every dependencies’ project to build them or to retreive it’s dependencies…
- other missing plus
With the absence of com.jme3 you block publication of some libs. If every lib’s creator have to publish jme (in it’s own groupId) it’s more confusion for the user (lib creator and user) : Which version to use ? Should I also publish my own jme ? How to merge/remap jme from 2 libs ?
=> no jme extension / lib on central (no lemur, no zay-es, no jme-jfx, no …)
I’m OK to be in the core team as “artifact publisher”
-
Because we have a different idea of how to use the engine and don’t want to walk people through their IDE of choice, especially for things like Android and iOS deployment and things like that. We don’t see jME as a java library but as a platform to build applications on. With the SDK theres none of the questions you pose, everything is included and you can use your favorite java libraries with that.
-
Because we want to make sure that the person is available and we trust them. We have 10+ years of experience with people coming, making a fuss and then walking off leaving us with the remnants of whatever they built. Or, even better, causing havoc constantly by telling us what they think should be done and how the engine should be different and in the end only causing fruitless discussions and frustration. If theres discussions we want them to happen with people that we know have some culture of discussion.
-
(Which you didn’t ask) Because we need to make jME3 actually compatible to maven before we release it there, which includes making a proper build process for native bullet (our modified jbullet version isn’t available on maven) and moving to native bullet in the first place. Additionally our way of handling the native binaries of lwjgl/jogl isn’t really compatible with their maven artifacts, there is a workaround for lwjgl which is possible due to their (accidental) binary naming scheme but we still intend to move to JOGL, which has name conflicts. So, as we always said, we do want to add jME to maven eventually but not in its current form.
Do I have to justify our decisions further or can you get along with these explanations for now?
Thanks for your response (and time).
@normen said: 1) Because we have a different idea of how to use the engine and don't want to walk people through their IDE of choice, especially for things like Android and iOS deployment and things like that. We don't see jME as a java library but as a platform to build applications on. With the SDK theres none of the questions you pose, everything is included and you can use your favorite java libraries with that.
You can’t force people to use the SDK. It’s not often the optimal solution.
- I switch out of the SDK to be able to use jdk8
- Managing lib and there dependencies with netbeans is not as friendly as via repository (+ version info) and sharing project become very unfriendly if you create netbeans’library,…
@normen said: 2) Because we want to make sure that the person is available and we trust them. We have 10+ years of experience with people coming, making a fuss and then walking off leaving us with the remnants of whatever they built. Or, even better, causing havoc constantly by telling us what they think should be done and how the engine should be different and in the end only causing fruitless discussions and frustration. If theres discussions we want them to happen with people that we know have some culture of discussion.
+1. (I hope, I’m not a Troll)
Mainly why I propose a solution with near to zero change/cost why your current process. IMHO it’s more an ADD than a request to change existing (I didn’t ask for mavenization of the project).
@normen said: 3) (Which you didn't ask) Because we need to make jME3 actually compatible to maven before we release it there, which includes making a proper build process for native bullet (our modified jbullet version isn't available on maven) and moving to native bullet in the first place. Additionally our way of handling the native binaries of lwjgl/jogl isn't really compatible with their maven artifacts, there is a workaround for lwjgl which is possible due to their (accidental) binary naming scheme but we still intend to move to JOGL, which has name conflicts. So, as we always said, we do want to add jME to maven eventually but not in its current form.
publishing snapshot will help to setup/experiment/tune the distribution before the release.
About native : May be I can help with native (I work on internal repo and the distribution of Mamba Nation a java game with native (lwjgl, fmodex))
About jbullet/stackalloc fork : in this case, the simple solution : deploy it under groupId com.jme3 (I did it for my fork (jmbullet) of your fork 
)
@normen said: Do I have to justify our decisions further or can you get along with these explanations for now?
I would have appreciate more explanation, and not a “NO GO” ;-).
But, for now, I’ll live with the status-quo (I’ll probably go back to the suject later).
If you need help on this subject, I’ll be happy to contribute.
@david.bernard.31 said: Thanks for your response (and time).You can’t force people to use the SDK. It’s not often the optimal solution.
- I switch out of the SDK to be able to use jdk8
- Managing lib and there dependencies with netbeans is not as friendly as via repository (+ version info) and sharing project become very unfriendly if you create netbeans’library,…
You can import maven artifacts to SDK projects no problem, you can use JDK8 with the SDK no problem. And we don’t force anyone to do anything, we just don’t supply maven artifacts as if it was meant to be used this way, which it simply isn’t. If you know your IDE you have no problem whatsoever getting a build with jME going or using this maven repo here.
@david.bernard.31 said: +1. (I hope, I'm not a Troll) Mainly why I propose a solution with near to zero change/cost why your current process. IMHO it's more an ADD than a request to change existing (I didn't ask for mavenization of the project).
See, just as you went away from using the SDK and contributing to that we would sit with your implementation, build system etc. and might not like it, gnomesayin’?
@david.bernard.31 said: publishing snapshot will help to setup/experiment/tune the distribution before the release. About native : May be I can help with native (I work on internal repo and the distribution of Mamba Nation a java game with native (lwjgl, fmodex)) About jbullet/stackalloc fork : in this case, the simple solution : deploy it under groupId com.jme3 (I did it for my fork (jmbullet) of your fork :-) )
We have/had nightly SDK versions for that (not at the moment though due to the transition to 3.1), why would we use maven for that when everything else is not using maven? We’ll put out an experimental 3.1 SDK at some point with current nightlies again.
@david.bernard.31 said: I would have appreciate more explanation, and not a "NO GO" ;-). But, for now, I'll live with the status-quo (I'll probably go back to the suject later).If you need help on this subject, I’ll be happy to contribute.
I thought my whole post was an explanation for our decision for a no-go? Yes, we’ll keep you in mind, you seem very capable.
few comments.
@normen said: You can import maven artifacts to SDK projects no problem,no problem and not friendly (manual dependency management)
@normen said: you can use JDK8 with the SDK no problem.
unless I miss something :
- 3.0 SDK is based on netbeans 7.3 => jdk8 unavailable
- jdk8 only for netbeans 8.x => using jme 3.1
I used the SDK 3.1.0 build & launched from a netbeans 8 but for assets only.
After 3 months with SDK (3.0/3.1) I switch to gradle+eclipse to manage java code. (I also tried to patch SDK to support gradle project with no netbeans/ant script and asset in other location).
@normen said: See, just as you went away from using the SDK and contributing to that we would sit with your implementation, build system etc. and might not like it, gnomesayin'? :)
I not sur to understand the sentence. I don’t request to ignore or replace SDK, I just request to open support to maven/gradle’s users.
@normen said: We have/had nightly versions for that (not at the moment though), why would we use maven for that when everything else is not using maven?
chicken and egg.
So
if ( I (or other user) start using maven/gradle for jme)
then {
maven’repository support will be added ? (it is not the purpose of this thread)
}
?
@normen said: I thought my whole post was an explanation for our decision for a no-go? Yes, we'll keep you in mind, you seem very capable.
Thanks for you support and patience.
@david.bernard.31 said: no problem and not friendly (manual dependency management)
No, theres ANT libraries that let you use maven with ANT, you can add them to the SDK project and use maven libraries with it.
@david.bernard.31 said: unless I miss something : * 3.0 SDK is based on netbeans 7.3 => jdk8 unavailable * jdk8 only for netbeans 8.x => using jme 3.1
Yes, you miss that you can compile with JDK8 no problem, you just don’t get IDE support for the new features.
@david.bernard.31 said: I used the SDK 3.1.0 build & launched from a netbeans 8 but for assets only. After 3 months with SDK (3.0/3.1) I switch to gradle+eclipse to manage java code. (I also tried to patch SDK to support gradle project with no netbeans/ant script and asset in other location).
So, as you see theres no issue doing that. Also the SDK supports any folder, no matter what build system, for assets only already.
@david.bernard.31 said: I not sur to understand the sentence. I don't request to ignore or replace SDK, I just request to open support to maven/gradle's users.
And I said there is no support thats worth the name yet so we don’t let somebody do that without it being under our control. I explained who “not somebody” is in the previous post, it has nothing to do with abilities.
@david.bernard.31 said: chicken and egg. So if ( I (or other user) start using maven/gradle for jme) then { maven'repository support will be added ? (it is not the purpose of this thread) } ?
??
Its not chicken and egg, you just made it chicken and hatchling and its egg to make a point… Our software, that is the software that we wrote and put for free on the web is not based in any way on maven and we have another way to give users a nightly version, which was your argument in the first place. Theres just no good reason to make it available for maven users before we get to a point where its actually compatible with maven, which I said might even be when 3.1 takes real shape. If we put out 3.1 as maven artifacts now, what do you think will people who are just too lazy to use the jar files and love maven do? Use the stable version? I doubt so.
And yes, it is time I invest here. Time I could use talking to the others about how to go about for 3.1, time I could use to clean up the build script or fix the niftygui editor integration. And you are not the first one asking for maven support and not the first one who thinks he has good arguments why we should do something another way.
FYI: I start an other topic about jme3stuff-a-dedicated-maven-repository-for-jme3
Due to circumstances beyond our control theres now an official maven repo for jME3 available, see this post: http://hub.jmonkeyengine.org/forum/topic/official-maven-repo-for-jme3-0-stable-available-please-test/