gdx and gdx.jnigen.loader causes split module issue over package com.badlogic.gdx.utils about libgdx HOT 6 OPEN

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.

from libgdx.

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.

from libgdx.

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...

from libgdx.

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.

from libgdx.

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.

from libgdx.

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.

from libgdx.