Yeah that would be great, I have actually been wondering how to get that quick-link that users can drop into their dependencies list for gradle projects. Do I just make an account on the JCenter website and upload the source code, or the compiled jar file?
I actually made an account on the store page last night, but I noticed most other items on the store page include the quick dependency link thats hosted on places like JCenter, so I wanted to figure that out and then post this to the JMEStore.
Do I just make an account on the JCenter website and upload the source code, or the compiled jar file?
There’s a bit more to it than that, I believe:
Create an open-source account at BinTray.com — I suggest using your GitHub credentials. Don’t sign up for a free trial of the Pro Edition, as I once did!
Create a Maven repository with at least one dot (“.”) in its name.
Create a package in the repository for your shader project.
Create a version of the package.
Upload a POM and whatever JARs you want to provide.
The easiest way I find to generate the required jars and POM is to build to mavenLocal and upload the generated files from your local repository - I usually build to mavenLocal anyway, so it’s not really an inconvenience.
The majority of my projects on GitHub have the required build.gradle settings to do that.
// Put this at the end or it won't pick up the project.version and stuff
if( project.hasProperty('releaseUser') ) {
apply plugin: 'com.jfrog.bintray'
apply from: 'https://raw.githubusercontent.com/Simsilica/gradle-plugins/master/simtools-release.gradle'
}
I control whether it runs or not by settings in a gradle.properties file that has my bintray info, etc…
I managed to manually upload the jars to each version in the package I made,
but I am getting stuck trying to link the package to JCenter, and I suspect I will probably run into some more confusion trying to set the gradle.build file up to do that automatically.
For now I am trying to manually generate the pom file with the task ‘gradle writeNewPom’, but when I upload the pom file I keep getting an error about it not being in the proper directory, and this seems to be preventing me from linking to JCenter.
I tried to restructure my bintray repository to match the package structure of the files im uploading, but even when it is identical, it gives me a warning saying : **Notice:** Uploaded POM does not match its expected location. Target Repository Path is probably incorrect, meaning your files may not be resolved. Suggested Target Repository Path value should be: "yarnmcdonuts/aaaagames/PBRTerrain/3.3"
If I resolve it the way their site suggests after uploading, then the pom ends up in this double nested location ‘yarnmcdonuts/aaaagames/PBRTerrain/3.3/yarnmcdonuts/aaaagames/PBRTerrain/3.3/’ and still does not link to JCenter.
The jar files seem to be fine, but I must be missing something about the pom files and why its so important that they are located in a specific spot.
Yes, the placement of files in the Maven repo is critical. It’s important to get this right before requesting the link from JCenter.
I don’t think about file placement much, simply following the recommendations that the BinTray website makes based on the POM. For example, the POM for v9.2.2 of the Libbulletjme package in the “com.github.stephengold” repo is located at “/com/github/stephengold/Libbulletjme/9.2.2/Libbulletjme-9.2.2.pom” and it looks like so:
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!-- This module was also published with a richer model, Gradle metadata, -->
<!-- which should be used instead. Do not delete the following line which -->
<!-- is to indicate to Gradle or any Gradle module metadata file consumer -->
<!-- that they should prefer consuming it instead. -->
<!-- do_not_remove: published-with-gradle-metadata -->
<modelVersion>4.0.0</modelVersion>
<groupId>com.github.stephengold</groupId>
<artifactId>Libbulletjme</artifactId>
<version>9.2.2</version>
<licenses>
<license>
<name>New BSD (3-clause) License</name>
<url>https://opensource.org/licenses/BSD-3-Clause</url>
<distribution>repo</distribution>
</license>
</licenses>
</project>
I see, I think I was misunderstanding what should go in the groupId tag, and was also incorrect in naming my initial repository on bintray. So it looks like I need to name my bintray repository com.github.yarnmcdonuts so it correlates with my github profile. I was also making the version correspond to the branch on github, since I made a 3.2 and 3.3 branch of my repository on github, but I am not sure if that is correct?
For folks that don’t have their own domains, it’s very common to use com.github.
It’s not a requirement that they match but folks are so used to it that they will often do the reverse lookup to find you. So sometimes it’s nice to make sure that works.
It’s fun to find a project that’s still net.sf or net.sourceforge for the same reason you have projects use com.github now.
I always preferred to have my own domain to tag things with… whether org.progeeks or com.simsilica or the org.fgraph, org.meta-jb, etc… but my open source projects started out as serious efforts… serious enough to build a domain presence.
Edit: and to prove I’m not just making stuff up… you can put com.github into google and while searching on that won’t find anything helpful (at least not for me) the drop down has a bunch of suggestions with some prominent projects. Best example:
They also suggest the groupId=com.github.[githubuser] and artifactId=[reponame] specifically for GitHub projects, which is very common. (And the first time you deploy a plugin to the Maven central repo, you have to also give proof of the domain ownership by putting your Jira request ticket into a DNS info) - Thought it would be interesting for a few people since I see more and more jME projects going the way to central dependency repositories instead of just laying around in some source control repos, which is cool.
There are many correct ways to number builds/versions/releases. The best guidance I’ve found is at https://semver.org/
The issue with aping JME’s release numbers is that you might eventually need to release more than one version of your shaders for, say, JME v3.3.2-stable. So then you’d have to add a suffix to distinguish them, as the SDK does. I prefer to invert the nomenclature, assigning numbers that make sense for my project and adding suffixes when necessary to distinguish which JME versions they target.
I unfortunately did not manage to figure out how to properly upload the pom and get the link on JCenter the other night, and I had to take a break after going insane deleting/remaking the project on Bintray with different names multiple times
It turns out I’m just making a stupid mistake trying to set up my repository using their website, for some reason when I upload the POM and jar, it puts the files in the project’s package rather than in the package for version that I’m trying to upload to - and I must be overlooking how to upload to a specific folder.
I have a bad habit of trying to learn these types of things late at night when I’m tired, and I often end up tripping over small things and end up convincing myself its a lot more difficult than it is… so I’m going to give it a try again soon and hopefully figure it out.
Here’s the link to my most recent attempt at setting up the repository, specifically the 3.3 version. Does the naming/versioning pattern look better, or would you suggest I change it?
I think I finally figured out how to upload to a specific folder and solved the “cannot locate pom” error, but the POM may still be messed up because I have now got an error saying that the POM is invalid when I tried to get the link from JCenter again.
Since I changed the naming and versioning structure of the project a few times trying to solve the first file location issue, It is likely that I have an incorrect value in my POM that I’ve overlooked
Hmmm that’s strange it’s still not working for me then.I cleaned the repository up, deleting some files and removing the 3.2 version for now, so I’m only working with one jar and POM rather than 2 until I figure it out.
I think I will have to remake the repository again, as I converted it to some other non-POM based format when I pressed “link to jcenter” and pressed the wrong check box next to the “POM Project” checkbox.
I googled the issue, and found some people saying that my POM might require a n SCM variable as well, but I could not figure out what I should put in there, and I notice that the POM for some of yours and Pual’s bintray projects do not contain that, so I’m not sure if that will solve it anyways…
Just to make sure I’m still on the right track - it is okay that my github repository does not match the package structure of my maven project? Because I have my github project named PBR-Terrain but the project package in bintray is called PBRTerrain without the dash.
I am also only uploading a single jar, specifically the assets jar because this project is only shaders, and contains no java code. I assume this would not be causing the issue since its still a jar file, but I thought I should mention it just in case.
Unless you’re using the automated importer (“Import from GitHub” in the web interface) it shouldn’t matter how the GitHub repo is organized or named. You don’t need a GitHub repo to use JFrog/BinTray/JCenter.
What issue are you seeing that you think might be due to no Java code?
A few thoughts…
Caching can cause all sorts of confusion if you’re not wary of it. If you’ve tested a v1.0.0 and then deleted or changed it, the old v1.0.0 is probably cached on your development machine. While debugging the repo, you might try bumping the version number after every change.
Also, note that you can test your package in Gradle before linking it to JCenter, by using something like:
repositories {
maven { url 'https://dl.bintray.com/yarnmcdonuts/aaaagames' } // for PBRTerrain
jcenter() // for everything else
}
Finally, while a repo name like “aaaagames” is good enough for BinTray, JCenter will require that the repo name contain a dot ("."), such as “com.aaaagames”.
