Why is the jme3-lwjgl3.jar file missing on the latest build of the engine?
2 Likes
That’s surprising to hear, I recall testing everything in staging and had no issues. So its strange it would be gone now. It looks like jme-android is also missing from your screenshotted list if I’m not mistaken, which I am certain was there when deploying.
I did run into some other trouble during the building and deployment process, for some reason it produced a duplicate engine build that contained only the android library, which never happened before (granted this was only like the 4th or 5th time I’ve done this process so far) but I just dropped that build and made sure the primary build still contained jme’s android libs (which it did at the time) but now it looks like that is not in the list of libs in your screenshot either even though I’m certain it was when I confirmed everything… so I’m not sure what’s going on here.
I wonder if this has something to do with the fact that the hosting service is being sunsetted in 2 weeks and service is being discontinued for repositories as they are migrated (and we haven’t yet migrated to the new service)
But I did every step in the build process exactly the same with 3.8.1, so I’m not sure why this time it suddenly caused issues.
In the meantime, you can just bypass the problem by using the 3.8.0 version of lwjgl3, it is actually identical to the version that should be available on 3.8.1 (since 3.8.1 only includes one PR different from 3.8.0 anyway, so the lwjgl library was unchanged. Maybe thats why it didn’t deploy? I’m not sure, maybe someone else who’s had more experience setting up the build and deploy process can explain what’s going on.)
I just tested running an app with implementation "org.jmonkeyengine:jme3-lwjgl3:3.8.1-stable" in the build file and it compiles and runs perfectly fine.
Did you try running an app that’s using lwjgl3, or are you just seeing it not listed in that list you took a screenshot of? Also where is that list from? It may just be some type of display issue with whatever list you are viewing.
No you misunderstand me, the downloadable .zip file that suppose to contain all jars does not have the jme3-lwjgl3 in the zip. Screenshot from github. And no I am not using gradle.
1 Like
Oh I didn’t realize that’s what you meant. I thought that list was a list of jme’s maven repo.
So in this case it was likely an issue with a github action.
It is very strange that github somehow lost those files, yet somehow they managed to get properly uploaded to the OSSRH repo to be used in gradle where they are working.
As mentioned in my original post, I did the same build process as always, but something must’ve gone wrong with the github actions/scripts that automates the build and deployment process.
I could try to create a 3.8.2 release, or maybe there’s a way to re-build the 3.8.1 release.
But I don’t have experience with these github actions or the deploy process, I just have been following the doc to run that process since everything was already setup when I started managing releases. And haven’t looked into it much because alot of it is about to change anyways once the jme repo is migrated in a few weeks. @sgold may know what caused this and what the best solution would be, since he has more experience with past releases and especially with the github actions and build/deployment process.
1 Like
Thanks for the feedback. Okay lets wait for him to come back and give some feedback.
Again, thanks.
1 Like
Seems to me we’ve had this discussion before:
The ZIP file that’s uploaded to GitHub is intended for executing tests, not distributing the libraries. If it contained both jme3-lwjgl.jar and jme3-lwjgl3.jar, there would be conflicting classes. This has always been true. It’s not a recent change, and it doesn’t indicate a bug in the release process.
If you want to download the JME libraries by hand (not using Maven or Gradle) you can get them from Maven Central: Central Repository: org/jmonkeyengine
5 Likes
For similar reasons, the ZIP file that’s uploaded to GitHub also doesn’t include jme3-ios or jme3-vr.
3 Likes
Given how often this comes up i wonder if it would be worth renaming the zip?
2 Likes
Admittedly, “TestChooser.zip” would be a better name for the file.
However, renaming would risk breaking someone’s workflow, so I don’t recommend it.
1 Like
Maybe a good solution would be to add a note at the bottom of the release description on github mentioning that the source code zip file does not contain every jar, and include a link to the jme libraries on maven central.