Just my two cents as I do not know much about Android internals but IIRC I had a similar issue, afaik adding these to gradle.properties fixed it.
# AndroidX package structure to make it clearer which packages are bundled with the
# Android operating system, and which are packaged with your app"s APK
# https://developer.android.com/topic/libraries/support-library/androidx-rn
android.useAndroidX=true
# Automatically convert third-party libraries to use AndroidX
android.enableJetifier=true
I unfortunately already had those 2. It seems that lemur uses guava. But guava makes android furious unless the sanely named ‘com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava’ is added. Equally lemur seems to require
It only “requires” that because lemur-proto was also included which adds its own styles to the glass style. The problem with the “solution” is that it will completely ignore the lemur-proto-specific styles.
…at that point you could just leave the glass style out completely and make all android users define their style in code. Then you wouldn’t even need the guava dependency.
The right solution is to probably have some android-specific process in the build collect all of the glass-styles.groovy files together and concatenate them.
Well, in theory it should work because all Lemur does is execute them one at a time in order… but I just looked at the glass style and groovy will probably complain about some variables being re-declared.
I don’t know if it would care about the repeat imports.
Hi Monkeys, long time listener, first time caller.
Does the Initalizer have an API - e.g. can we send a GET to find all available jmonkey versions, physics engines etc, then POST the settings we want to get the generated build files? I believe this is how the Spring Boot plugin for Netbeans works (connecting to the Spring Initializer) when creating a new project…
Being newish to jMonkeyEngine tinkering, and hitting some of the issues newbies hit with the SDK, I started working on improving the new Gradle project Wizard in the SDK in much the same way, but trying to keep things “simple” (i.e. desktop target only, main project with only :assets subproject etc.) for people new to JME.
But it might make sense to have a new “jMonkey Inializer project” option in the SDK, for creating more advanced builds for Android etc?
That was in my mind as well. Yes, yes it does (in fact the web UI exclusively uses the API so you can look at the calls the browser is making to see how to use it.).
It has the following end points currenty
GET - /jme-initializer/libraries
This returns a bunch of json that basically describes the available options, the json mirrors this java class UiLibraryDataDto
GET - /jme-initializer/zip?gameName=????&packageName=????&libraryList=????
The library list is a comma seperated list
This returns a ZIP with the starter project
GET - /jme-initializer/gradle-preview?gameName=????&packageName=????&libraryList=????
This returns a json map of the gradle files to their contents
It would be nice to be able to specify mainClassName and maybe better to include mavenLocal() by default in the repositories section, and probably having a checkbox “Early Access Build” for using the latest beta version of the engine.
Edit:
Also, IMHO the title Game Name may be changed to Project Name as we may use this for non-game projects as well.
I suppose the question I would have to that is when would we ever want to start anyone on anything but the latest and greatest (its the same reason I include lwjgl3 by default and don’t give anyone a choice to use lwjgl2). If they know enough to know they want old lwjgl or a beta (or old) version of JME they know enough to be able to tweek the outputted template themselves and we don’t want to be leading people down a rocky road.
Hey @richtea , this is really helpful, but I haave one suggestion.
Could you add implementation 'org.codehaus.groovy:groovy-all:2.4.15' to the build.gradle as a dependency, when a project uses Lemur? I had to add that line every time i made a new project, though it is easy I thought it could help improve the initializer.
Note that groovy is an optional runtime dependency for Lemur. It is possible to use Lemur without groovy (and probably quite likely if using Lemur on Android)… but it is true that 99% of Lemur users will want the groovy dependency.
I don’t know how that sort of thing should be handled in the initializer and I haven’t looked (yet) at how it presents things. I suppose if it added the dependency automatically then users could always remove it if they didn’t want it. But maybe there is room for some kind of UI improvement. (shrug)
The initialiser asks the new jmonkey store for some json about what libraries are available (specifically https://library.jmonkeyengine.org/ext/initializer/libraries.json). The initialiser uses that information to present a UI option and if selected what dependancies to add. The section for lemur is like:
{
"key": "LEMUR",
"displayName": "Lemur",
"category": "GUI",
"descriptionText": "Lemur is GUI toolkit for making user interfaces in jMonkeyEngine applications. It supports standard 2D UIs as well as fully 3D UIs. The modular design allows an application to use all or some of it as needed or even to build a completely new custom GUI library on top.",
"defaultSelected": false,
"usesJmeVersion": false,
"artifacts": [
{
"groupId": "com.simsilica",
"artifactId": "lemur",
"fallbackVersion": "1.15.0"
},
{
"groupId": "com.simsilica",
"artifactId": "lemur-proto",
"fallbackVersion": "1.12.0"
}
]
}
Because only lemur and lemur-proto are in the list it only includes those dependencies. As an optional dependency it’s kind of difficult, non optional dependencies would obviously just be specified by lemur and gradle would pull them down. If we did want to include groovy it might make sense to include it in the list of artifacts (Usually without a version then the initialiser just chooses the most recent, lemur I think doesn’t need the fallbackVersion anymore now that it’s at maven central).
