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).
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)
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.
Yes, you’re guilty, you want to provide a fluent and standard UX.
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
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.