Experimental : 3.1.x jar in a maven repository


In my quest to find a way to host nightly, beta, rc,… jar. Today I try JitPack. It’s not a host like oss.sonatype or bintray. It’s a frontal to access artifact (jar) available on github or bitbucket. By default it will build and provide you the jar, but can also serve the jar provide by the project owner if it’s released use github release.

Eg to use it with gradle :

repositories {
    maven { url "https://jitpack.io" } //should be the last, because it can trigger a build

//def jme_version = '72e1213'
//def jme_group = 'com.github.davidB.jmonkeyengine'

def jme_version = 'b8fe36e'
def jme_group = 'com.github.jMonkeyEngine.jmonkeyengine'

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

You can use it with jme forks (change the groupId)

The first call will take few minutes (~6 or 10 min in my test), time to build the modules (on jitpack’s server) the artifact. I already have the right native lib on my desktop so any feedback on a “fresh env” are welcomes.

Hope it will allow more people to give a try to 3.1.x. (or code in other branch like PBR, or on fork ), and to share WIP code, lib, …
It will also become easier to core team to make milestone, beta ,… (at least just a tag).

PS: JitPack | Easy to use package repository is currently beta stage

EDIT: update the code fragment


The gradle build script can export a maven repo just fine, I don’t think we’ll need this.

Hi Normen,

If this solution works, you don’t need to setup/maintain a repo for nightly,… x branch. And simply by reading the jme_version I know the commit use by a project, lib (mine or other), more info than ‘3.1.0-snapshot-github’, I can try a more recent version, and rollback just by editing the jme_version.

I don’t say it’s perfect, but it’s an interesting solution. It’s very similar to the approach used by Dart, Rust to manage dependencies (using github + commit shortcut/tag)

Its actually a pretty cool thing. As long as a github project offers a gradle based build you now have dependency management available.

Btw, i did not manage to add only some libraries as dependency and not all of them.
But it works.

repositories {

    maven {
        url "https://jitpack.io"

dependencies {
    compile 'com.github.zzuegg:jmonkeyengine:8d0c371796'

Ah. once the build has completed you can add also partial jars. They just dont trigger the build

Wow it’s super cool, but i can’t get it working with branches. Maybe they are still unsupported ?

how to you setup for branch ? do you use the shorcut of commit in a branch ?

Did not yet try with branches. Just used the last commit on my master fork

What do you mean? I tried

mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:get  -DrepoUrl=https://jitpack.io/  -Dartifact=com.github.USER:REPO_NAME:COMMIT_ID

COMMIT_ID can be on any branch. (browse the branch on github, copy the commit_id)

Oh! It works now, i think i was inadvertently doing something wrong :sweat_smile:

We’ll need a repo for the SDK plugins anyway and the builds now contain direct info about what commit is used. Nice stuff though, hope nobodys gonna accuse me of anything just because I say we probably won’t need it.

I slept over this and came to the conclusion that it is a very bad idea to have commit id’s in your dependecy list if you release a plugin.
You might end up pretty fast with 10 versions of the same engine in you list.
So untill there is no official tag/snapshot whatever i am not going to add such dependencies to public code.

For internal development jitpack is pure Gold

Yes, you’re guilty, you want to provide a fluent and standard UX. :stuck_out_tongue_winking_eye:

I agree JitPack it is not the solution for the SDK/NB ecosystem. And maybe not for the released version of maven artifact. But can be a nice alternative to provide snapshot for maven user, without the need to setup CI, artifact host.

You don’t want to say you want people using the SDK to be left out in the rain do you? ^^ And for DEVELOPMENT you should have the source code checked out anyway…?

I agree completely that such versions should not be used for anything but development or testing @zzuegg

I said It’s for maven/gradle user who like to play, experiment, share (not release) code using 3.1.x, without the headhach of “which commit did you use to create your SNAPSHOT?”. And maybe for tagged version it could be an easy way to publish.

It doesn’t replace NB plugins or the service @jayfella is working on. It’s not the goal.

not fully agree. I agree that stable, “release” code should not depends of “commit-id” like it should not depends of “snapshot”. But to share WIP/experimental project it’s a nice way to provide a reproductible way to build. Without the need to manually “ask the commit-id, repo, then git clone, git checkout, build,…” just to play with a project that use 3.1.0-github-snapshot. and will avoid the trouble of the multiple fork, branch published in your local repo with the same groupId, artifactId, version. (like the trouble I got with jfx, yadef,… because my local jar for 3.1.0-github-snapshot was not the same used by author).

EDIT: I forgot my case where I work on several desktop.

Again, all this info is included in every build now. No matter if its self made, from our (future) maven repo or the alpha SDK updates. The problem you mention is basically only existing in maven :slight_smile:

The problem is for every build tool where you declare dependencies as name + version (maven, gradle, sbt, …)

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.