Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic third-party list #30

Open
JojoIce opened this issue Sep 17, 2020 · 3 comments
Open

Dynamic third-party list #30

JojoIce opened this issue Sep 17, 2020 · 3 comments

Comments

@JojoIce
Copy link

JojoIce commented Sep 17, 2020

It would be very nice to be able to specify personal 3rd party libs in some way so that one can add personal dependencies in the list. I have 3 extensions (not ready for general consumption) that I often use in my games. If setup could read in an extension configuration then that remove all need to always have to fiddle with the gradle files afterwards.

@tommyettinger
Copy link
Member

This is kind-of in the works. I don't know all the specifics yet, but @payne911 has been making progress on a setup-app-independent way of storing project config, and that would be able to load the gdx-extension JSON files that @crykn has been working on, like this in-progress extension. The idea with a standard system for extensions is to be able to load more on-demand, including as an option to users. I think the GDX extension thing needs to be accepted by an ecosystem of libraries to be useful, and it isn't even finalized yet. Right now liftoff doesn't read 3rd-party extensions from a file (they're all in code), and maybe being able to read in GDX extension JSON files would be enough to solve this issue.

@payne911
Copy link
Contributor

It's more like I'm working on extracting liftoff's logic so that it doesn't have to be coupled with its View anymore.

That has many benefits such as reusability by other components. There are plans for a WebApp to be online for people to be able to setup their projects without having to interact with a desktop application.

That JSON mentioned above is a great way to decouple a bit more the management of third-party libraries, but a library would still need to be "supported" by being integrated via pointing to its JSON within the code-base.

@JojoIce
Copy link
Author

JojoIce commented Sep 22, 2020

That sounds really good. Makes sense to remove the hardcoding and put it id JSON. Those could be packed into the jar, but with a simple way to let users add their own. Maybe just read a folder "extensions" next to jar and look for additional JSONs or similar. That way one could just replace a liftoff jar with a newer release in the same folder and keep the personal extensions without any additional work. Looking forward to it :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants