Experimental : 3.1.x jar in a maven repository

Yep, if you use those to include a random development version of a WIP library for a WIP application. It doesn’t help us one bit with testing.

Where is it included ?
jar under dist/ doesn’t include version in filename and internal META-INF are minimal (manifest version only). and jar published into local maven repo, use 3.1.0-github-snapshot.

Run an app with it.

I saw info at runtime, but runtime info are useless for build.
You (core team) do lot of improvement in 3.1, we just want to be able to play with them.

No it helps us a lot when we see what version you have issues with. And making maven repos isn’t completely set up in the build script yet, we can use the same info for that. Also you’re varying your intentions with every answer, before you wanted to be able to distribute a project with a certain commit build, now you want to play with the most recent version…

Where did I say I want the most recent version ? I’m not varying. But it’s possible I’m not clear (I do lot of error in english, sorry).

Whatever.

I think i have found a way to manage the dependecies. At least it seems a valid workflow to me. It allows to put the “+” modifier on the minor versions.

So regarding yadef:

apply plugin: 'java'

sourceCompatibility = 1.8
version = '1.0'

repositories {
    mavenCentral()
    maven {
        url 'http://updates.jmonkeyengine.org/maven'
    }
    maven {
        url "https://jitpack.io"
    }
}

def jme_version = "3.0.+"

dependencies {
    compile "com.jme3:jme3-core:$jme_version"
    compile "com.jme3:jme3-desktop:$jme_version"
    compile "com.jme3:jme3-lwjgl:$jme_version"
    compile "com.github.zzuegg:Yadef:$jme_version"
}

is going to be a valid buildfile that allows releasing plugins against the stable version, while still alowing minor version changes for both, yadef and jme

This is quite convenient from user point of view but it cannot be official, obviously.
I am still hoping we could have some official build system working … either a snapshot release per commit or have 3.1.x releases every month or so (kind of like LibGDX does it).

If at some point another working way is available i will switch/adapt of course.

Personally i am kind of against SNAPSHOT because usually that means autoupdate and a possible break every day. Beeing able to specify the exact version at compile time would be nice.

A possible solution could be:

git describe --tags

It returns the last tag as version plus “-#CommitsAhead

But to be completely save jme would require a 3.1.BREAKING_CHANGES.NOT_BREAKING_CHANGES format

The build already extracts the git hash as I said, we can simply use that. But actually I want a number since tags for the version so we get an actual version and not a huge hex number. Basically like it was with the 3.0 nightlies.

Yeah, the hash is not exaclty usefull since it is not incremental.
Quite a complex wide ranging topic once you start thinking more about it :frowning:

I found JitPack during my investigation to host snapshot, milestone,… released artifacts in a maven/gradle repo (published from CI Jenkins or Travis). This is the list :

  1. third party services
  • oss.sonatype : a set of rules, no space to experiment.
  • ojo (oss.jfrog): require that artifacts already exists in jcenter (I asked for derogation)
  • jitpack: ready to use with any changes, just need to tag on github to do release, and accept artifact uploaded under github’release (and no need to publish from CI)
  1. self hosted
  • setup artifactory or nexus (in a docker)
  • home made : setup a (s)ftp directory + http server + schedule task to monitor log, disk, purge snapshots (and no timestamps support)

I ask question ti JitPack before experimeting, and they are open to suggestion.
extract of JitPack’s email:

If there’s anything we can do on our side to support your workflow, please let us know. Feature requests are welcome

For example, we are considering version numbers for snapshots in
the form ‘master.123’ where 123 is the number of commits. That way you
could get the latest snapshot in gradle with ‘master.+’

So maybe we can found a solution that match our requirement with them.

EDIT: today you can use tag with JitPack like 3.1.0-dev20150621, simply add+push a tag and the nightly is available :wink: . and no need to use git commit-id (hex)

with the git tag, you will be allowed to use the release section of github to upload SDK,… (upload could be done my any commiter or from CI)

git allows you to basically get a number for “commits since tag X” for any checkout, that should work fine, also for actual releases. Like I said, basically like the old svn revision sub-version.

Hi, ok just for understanding.
in the Roadmap 3.1 (see here Roadmap for v3.1, Upcoming Release · Issue #199 · jMonkeyEngine/jmonkeyengine · GitHub ) are plans for having nightly snapshots. Can we help the core-team to realize this?
The easiest way for developers which want to use the 3.1 experimental jars is to download it from a maven-repo, isn’t.

1 Like

Hi,

Some update from Jitpack (I didn’t test it yet):

We now have a new feature where you can easily get the latest snapshot.
Simply replace the version number with ‘-SNAPSHOT’.

It works even nicer if your repository has a git tag because it will resolve to version:

Tag-commitHash-Commits

Where commits is number of commits since the tag. Essentially it is what git describe gives.

So Jitpack could be used as repo for SNAPSHOT (hourly :wink: ), and it will allow to be able to used the lastest or a special commit (on any branch) without the need to setup a dedicated infra.

I’m not interested by always running my code with the latest SNAPSHOT, any volunter to test it ?

1 Like

With Jitpack, you can have SNAPSHOT of master branch.

See your build tool doc for update frequency, eg Gradle Chapter 50. Dependency Management.

I did a quick test (take time, jitpack build on first demand) :

with the following config (fragment):

repositories {
    mavenLocal()
    mavenCentral()
    jcenter()
    maven { url "http://updates.jmonkeyengine.org/maven/"}
    maven { url "http://dl.bintray.com/jmonkeyengine/contrib" }
    maven { url "https://jitpack.io" }
}

def jme_version = "-SNAPSHOT"
def jme_group = 'com.github.jMonkeyEngine.jmonkeyengine'

dependencies {
    compile "${jme_group}:jme3-core:${jme_version}"
    compile "${jme_group}:jme3-lwjgl:${jme_version}"
    testRuntime "${jme_group}:jme3-desktop:${jme_version}"
    ...
}


I’ve got a snapshot in the project:

:compileJava
Download https://jitpack.io/com/github/jMonkeyEngine/jmonkeyengine/jme3-core/-SNAPSHOT/jme3-core--2b8898b7b2-0.pom
Download https://jitpack.io/com/github/jMonkeyEngine/jmonkeyengine/jme3-lwjgl/-SNAPSHOT/jme3-lwjgl--2b8898b7b2-0.pom
Download https://jitpack.io/com/github/jMonkeyEngine/jmonkeyengine/jme3-desktop/-SNAPSHOT/jme3-desktop--2b8898b7b2-0.pom
Download https://jitpack.io/com/github/jMonkeyEngine/jmonkeyengine/jme3-core/-SNAPSHOT/jme3-core--2b8898b7b2-0.jar
Download https://jitpack.io/com/github/jMonkeyEngine/jmonkeyengine/jme3-lwjgl/-SNAPSHOT/jme3-lwjgl--2b8898b7b2-0.jar
Download https://jitpack.io/com/github/jMonkeyEngine/jmonkeyengine/jme3-desktop/-SNAPSHOT/jme3-desktop--2b8898b7b2-0.jar

Give it a try.

2 Likes

The easiest way for jME SDK users is checking the “nightly” checkbox - when nightlies will be available again.

And note that jME nightlies are not a carefully maintained branch that gets only checked fixes or new features applied but a active development version that breaks and contains WIP code that for all we know might cause a nuclear meltdown on your computer. Its where the developers develop the code, make experiments and show each other what they do. This has always worked out best for us and yes, we’re aware that other projects create branches for each developer and development strain but thats just not how we roll.

Hi, @david_bernard_31

I LIKE and NEED this!

Our team work in multiples machines and of course we need a distributed and specific way to share libraries. And I need It now, so let see if we don’t have an official solution, how can we work around it… I’ve read through this topic but maybe I missed some point, tell me if I did?

  • Fork JME3-git repo and use it as my source code repo to let Jitpack to compile the jar
  • Tag the branches and commits to descible attributes of the Jars like Snapshot or Stable or what ever as I need
  • Use some gradle skeleton to build my game? (Don’t know if you have a working one yet?) like jme3_skel : my jme3 skeleton/bootstrap project - #4 by david_bernard_31
  • Benefit!