Open MRZ07 opened 1 month ago
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.
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.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.Thoughts on this:
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.
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.
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.
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.
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.