libgdx/libgdx

gdx and gdx.jnigen.loader causes split module issue over package com.badlogic.gdx.utils

GustavBW opened this issue · 6 comments

GustavBW commented

TLDR

This issue can be resolved by changing the name of the utils package in gdx-jnigen-loader.
The rest of this issue is me trying to find workarounds. None have worked so far (even manually loading different specific jars into the modulepath and jnigen into the class path to avoid the ModuleResolution conflict).
My attempts are on full display at https://github.com/GustavBW/MELANGE on the main branch.

Issue details

I've been trying to establish a personal project for 2 days now, but been unable to resolve a split package issue between the inferred modules "com.badlogic.gdx.utils", "gdx.jnigen.loader" and "gdx":

The source code for my exact setup can be found here:
https://github.com/GustavBW/MELANGE

According to Gradle, they support JPMS now, and it has successfully inferred all the gdx libraries as modules, but I'm new to gradle and still don't exactly get it. In other words: I can't determine if this is a gradle issue or a libGDX one.
I could shade gdx.jnigen.loader, but that seems like an extreme measure for something that has probably happened for others and been solved before.
I've also tried employing the JLINK plugin, which I've read can solve these kind of issues, but to no avail
A last ditch effort could be porting to Maven instead which has better (as far as I'm aware) JPMS support, but your guide for libGDX on Maven is old and states that it isn't exactly supported (https://libgdx.com/wiki/articles/maven-integration), so I'd love to hear how feasible that'd be.

Reproduction steps/code

Use the gdx-setup tool, select support for all but IOS.
Refactor projects to JPMS modules, since gradle 7..xx this has been supported by default, but still requires the following statements to establish default module setup (as per IntelliJ standards that is).

sourceSets {
    main {
        java {
            srcDirs = ['src/main/java']
        }
        resources {
            srcDirs = ['src/main/resources']
        }
    }
}

Add a module-info.java to each module's main/java folder:

module core {
    requires java.desktop;
    requires gdx;

    exports gbw.melange to desktop;
}
module desktop {
    requires gdx.backend.lwjgl3;
    requires gdx;
    requires java.desktop;

    requires core;
}

run "gradle build", "gradle jlink", click the green array in [desktop]... .DesktopLauncher in IntelliJ, anything really that involves a build process.

Version of libGDX and/or relevant dependencies

I'm using the latest version of libGDX: 1.12.1
I've tried updating AGP to 8.3 (as my JDK language level is set to 17, which it isn't happy about) but the build fails because Android studio doesn't like that. So, its at 8.0.1 so far.

Steps taken to solve the issue

I've tried to mend the gdx dependency for the core module (core/build.gradle) to exclude jnigen:

dependencies {
    api("com.badlogicgames.gdx:gdx:$gdxVersion") {
        exclude module: "gdx.jnigen.loader"
    }
}

As well as adding a patch module statement to the compiler arguments during the "compileJava" task of the core module to explicitly remove it (which might cause other issues later):

'--patch-module', 'gdx=C:/Users/gusta/.m2/repository/com/badlogicgames/gdx/gdx-jnigen-loader/2.3.1/gdx-jnigen-loader-2.3.1.jar'

Stacktrace

> Task :core:compileJava FAILED
error: the unnamed module reads package com.badlogic.gdx.utils from both gdx and gdx.jnigen.loader
error: module gdx.jnigen.loader reads package com.badlogic.gdx.utils from both gdx and gdx.jnigen.loader
error: module gdx reads package com.badlogic.gdx.utils from both gdx.jnigen.loader and gdx
the unnamed module reads package com.badlogic.gdx.utils from both gdx and gdx.jnigen.loader

Please select the affected platforms

  • Android
  • iOS
  • HTML/GWT
  • Windows
  • Linux
  • macOS
  • undetermined structural issue
tommyettinger commented

Why do you need modules here? I've only seen the existence of a module-info.java file cause problems... I don't know what you're trying to solve.

GustavBW commented

Why do you need modules here? I've only seen the existence of a module-info.java file cause problems... I don't know what you're trying to solve.

They're another layer of abstraction that makes it easier to manage separate chunks of a program/library/framework. Admittedly, JPMS is one of the wonkiest module implementations I've used, but they can be pretty neat when they work.
What I'm trying to solve, or figure out, is why they don't work for libGDX specifically - at least not per my current setup.

tommyettinger commented

There are very few people familiar with modules in the libGDX community, and the ones who are familiar probably use it for work projects. I'm not sure where to turn for advice on this, because I absolutely avoid modules.

They're another layer of abstraction that makes it easier to manage separate chunks of a program/library/framework.

This sounds like you don't actually need modules. It also sounds like none of this is going to be easy to manage. Pretty much everyone here just ignores that JPMS ever released...

GustavBW commented

There are very few people familiar with modules in the libGDX community, and the ones who are familiar probably use it for work projects. I'm not sure where to turn for advice on this, because I absolutely avoid modules.

Do you know about GDX 1.12.1 and Maven then / know about someone who got updated information on the current integration? My problem is I'm currently debugging 2 variables: Gradle and LibGDX, I'm far more familiar with Maven, and would happily sacrifice everything but desktop (android, HTML, ...) to get it working.

This sounds like you don't actually need modules. It also sounds like none of this is going to be easy to manage. Pretty much everyone here just ignores that JPMS ever released...

The only reason I know about JPMS is because we were forced to learn about it at university. Every other module system I've used since, C#, GoLang, and maybe even Node, has been easier to set up and get working. The great thing about modules is that you actually get to reuse code for once, not just talk about "reusability" because dependencies and settings are abstracted to a per module basis. Also avoiding conflicting dependencies at the same time.

tommyettinger commented

I'm familiar with Maven and use it occasionally. This project of mine uses libGDX 1.12.1 and the LWJGL3 backend with Maven. It does not use JPMS, though.

GustavBW commented

I'm familiar with Maven and use it occasionally. This project of mine uses libGDX 1.12.1 and the LWJGL3 backend with Maven. It does not use JPMS, though.

Thanks for the reference. I managed to set it all up with Maven, but it ran straight into the same error. As far as I can see, nothing requires com.badlogic.gdx.utils in gdx-jnigen-loader to be named utils. Changing the package name to "loader" would resolve the error and make gdx compatible with JPMS for the foreseeable future.