search

gurkenlabs / litiengine

LITIENGINE đź•ą The pure 2D java game engine.
https://litiengine.com/
MIT License
731 stars 94 forks source link

Fix implementation project name #422

Closed Gamebuster19901 closed 2 years ago

Gamebuster19901 commented 2 years ago

Dependents should now be able to use implementation 'de.gurkenlabs:litiengine:VERSION' once again, instead of implementation 'de.gurkenlabs:core:VERSION.

I don't have a project to test these changes on, please test before merging.

weisJ commented 2 years ago

Two comments:

  1. Why not change the name of the core project in the core/build.gradle.kts file?
  2. This fix won’t work. Gradle won’t be able to differentiate between the root project and core failing during dependency resolution when including the project using includeBuild …. You’ll also have to rename the root project.
Gamebuster19901 commented 2 years ago

Two comments:

  1. Why not change the name of the core project in the core/build.gradle.kts file?
  2. This fix won’t work. Gradle won’t be able to differentiate between the root project and core failing during dependency resolution when including the project using includeBuild …. You’ll also have to rename the root project.

For 1, I kept getting the error Val cannot be reassigned.

As for number 2, the user in discord isn't able to include the project using de.gurkenlabs:litiengine, shouldn't it automatically import subprojects if litiengine is included? It seems like changing the name of core should be unnecessary, as it should already come with litiengine.

weisJ commented 2 years ago

For 1, I kept getting the error Val cannot be reassigned.

I forgot, the name needs to be changed in core/settings.gradle.kts

As for number 2, the user in discord isn't able to include the project using de.gurkenlabs:litiengine, shouldn't it automatically import subprojects if litiengine is included? It seems like changing the name of core should be unnecessary, as it should already come with litiengine.

It’s a tricky situation really. Indeed gradle sees the core project but it won’t consider it when resolving dependencies. When declaring de.gurkenlabs:litiengine as an implementation dependency you request gradle to look for a module with group de.gurkenlabs and name litiengine which provides a java runtime configuration i.e a compatible jar file. Gradle will indeed find a project with the matching group and name namely the litiengine root project. But the root project doesn’t specify a java runtime configuration. In fact it doesn’t specify any configuration at all. Gradle then won’t go on to check any sub-projects because for one their names don’t match the dependency request and for another depending on a project doesn’t imply depending on the sub-project. The project hierarchy is merely for configuration purposes and isn’t mirrored on the configuration/dependency side of things. I hope this clears up the situation :)