Separate plugin types #10
Loading…
Reference in a new issue
No description provided.
Delete branch "ecorous/plugin-types"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
very buggy - needs a lot of work
WIP: initial work on separating plugin typesto initial work on separating plugin typesinitial work on separating plugin typesto Separate plugin typesLooks good for the most part.
@ -15,3 +15,3 @@
mixin = "example_mod.mixins.json"
accesswidener = "example_mod.accesswidener"
modprovider = "dev.frogmc.frogloader.example.ExampleModProvider"
Should we allow more than one modprovider per frogmod?
Already possible
@ -0,0 +21,4 @@
* Get the ID of this provider. Mods will be stored separated by their provider ID.
* @return The ID of this provider
*/
String id();
Should/could this be changed to a ResourceLocation?
No, thought about it but ResourceLocation is a Minecraft class and therefore may not be available.
Should we make a similar wrapper class? It seems strange not to enforce the used format
I don't think so, it doesn't really matter. The only important thing is that the content is unique among all mod providers due to the constraints of java's HashMap. And as we aren't really doing anything with these IDs except for supplying each provider with its mods later on I don't think it's worth requiring any specific format.
It's something to consider if we ever want to parse it
@ -0,0 +2,4 @@
import dev.frogmc.frogloader.api.plugin.ModProvider;
public class ExampleModProvider implements ModProvider {
I'm asumming this serves as a code example - in which case it should be moved to the documentation
The entire
minecraft
project is a test project - this tests that the discovery works properlySome of this should be in the documentation as well, but this is fine to stay
@ -0,0 +25,4 @@
List<ModProvider> providers = new ArrayList<>(ServiceLoader.load(ModProvider.class).stream().map(ServiceLoader.Provider::get).toList()); // we need mutability & random access
Map<String, Collection<ModProperties>> properties = new HashMap<>();
AtomicInteger size = new AtomicInteger(providers.size()); // use a separate size variable to not have to iterate over the list over and over again
wouldn't
int[] size = new int[] { providers.size() }
be better as there's no need for thread safety?I believe this works better - but I wouldn't know as I didn't write it
The only difference here would be a insignificantly smaller memory footprint - this isn't an issue
It's not about performance, i think it's bad practice to use AtomicInteger when you don't need it
Resolved in
39ba054fcb