Suggestion: Make Build scripts more abstract

[MRZ07]

To enhance the maintainability and modularity of our build scripts, we should aim to make them more abstract. For instance, we can define the packageId as a variable in the settings.gradle file and reference it in our scripts. Additionally, segregating custom dependencies into separate files would streamline the process of updating projects, as it would allow us to simply replace specific build.gradle files without disrupting the overall project structure.

[Frosty-J]

I'm calling this AI, not just because it has the verbose optimism of ChatGPT but also I don't think your suggestions make sense. Please clarify them if they do make sense.

1. The package ID cannot simply be a variable because of how Java projects are structured. E.g. you can see gdx.liftoff.Main is located in src/main/java/gdx/liftoff/Main.java. It also has package gdx.liftoff; in the file itself, as is typical for Java. Fortunately, IDEs make it pretty easy to refactor, though some manual changes may be needed to keep GWT happy.
2. I do not see how having separate build.gradle files for each dependency streamlines anything. Wouldn't that be a lot of files, making it less streamlined? Bearing in mind we already have separate files for each module. Once a project is set up, you can just change the dependency versions in gradle.properties. We may wish to consider using version catalogs (this link is a bit wordy - generating a non-libGDX Android project to see it in action might be easier) but that's the extent of what I think is reasonable.

[tommyettinger]

Thoughts on this:

• The selected package could be assigned to a property in gradle.properties, but changing it as a variable doesn't make much sense. It could be useful to look up, though, as a property.
• Separating build.gradle files per dependency is a bad idea. The situation now would be worsened by having many Gradle files, each a handful of lines. It would be harder to identify which build files actually matter if there are dozens of them.
• Your writing style sounds AI-ish, but that doesn't mean you're a replicant, droid, Cyberman, Borg, or any such being, just that an AI may have helped translate your Human of Earth Words. Maybe that's just your personal style.

The "package as property" suggestion should be do-able. Various other config done in the app could be made available to the compiler for later in the same way. I'll look into this along with the 8.9 update today.

[Frosty-J]

Now I understand. While I haven't personally found a reason why Gradle scripting needs to know the package name, it does sound like something that might be desirable to someone.

[MRZ07]

I develop multiple apps that require regular updates. From time to time, I encounter breaking changes which require migrating everything to a newly generated project, which can be quite time-consuming. Given that my apps share a common base in terms of services and dependencies, implementing an abstraction layer would be beneficial. This approach would also allow us to keep existing projects up to date by simply overwriting the Gradle files, and the tool could get an update functionality.

[tommyettinger]

You can overwrite Gradle files in the current version. (Last two versions, actually, I think.) If you select a folder with sources already in it, only the changed files will be written, and existing files not present in a new project will be untouched. If existing files do overlap with newly-written files, the old code won't remain, so do be careful and back up or use version control.

Given that a dependency is usually between just 1 and maybe 15 lines (in extreme cases), and in the current format you can copy whole blocks of dependencies at once, having a file per dependency per module would probably be a lot more work than you are hoping. You'd have to make sure you copy the box2d dependency files for each module you have separately (including core), for instance. You might be able to bulk-copy files, but they'd still need some way to be automatically loaded, which adds comparable code to the dependencies in the first place. Also, I don't know of any projects that work this way successfully, so if you have any examples, please show them.