Realistic Terrain Generation

Realistic Terrain Generation

3M Downloads

APIs in source code

Andrey96 opened this issue ยท 4 comments

commented

How about moving APIs to src/api/java folder (it is supported without any special configuration needed) instead of keeping them in src/main/java? They will not be included into compiled mod and it is good, because sometimes mod APIs can change and if you keep it in compiled mod, it can be loaded instead of original API and cause crashes.
Also you already have checks if mod loaded before activating it's module, so RTG will not crash if there will be no API in classpath.

commented

Thanks for the suggestion - I'm all in favour of adhering to best practice, so I'll definitely look into this one. The only API I won't be able to move is the Enhanced Biomes API, as I actually wrote that one myself, but I can certainly try moving the others.

commented

It's all about not including other mod's API classes into your mod. We don't need to duplicate this classes - they are already included into supported mod. And if mod is not installed we don't need this classes at all.

From my personal experience:
It was useful for me when I wanted to use open-source mod (dynamic lights), but it has no API. I've just copied all it's source into src/api/java and was happy with it.

And what about crashes - once I've tried to update some mods on my server (before I've started developing mods) and I was really confused with a crash that contained only updated mod's classes in stackTrace. I've spoiled pretty much time before realised, that other mod contained old API and updated mod tried to use it. I had to delete outdated API from other mod's jar manually and it started working (other mod started using updated mod's API).
Let's now imagine that other mod had no API classes. If API would have changed so much, that it lost support with other mod (that happens not so often), I would have seen that stackTrace contains other mod's classes and quickly realise that it is not supported and I have to wait an update.
So, this approach is also more user-friendly.

Sorry for the worst english ever, I hope you understand what I wrote here =)

commented

No apologies necessary - your English is fine :)

Thanks for sharing your experiences with this approach - it's actually made me realise that I can move the de-obfuscated JAR files from the libs folder, which was basically forcing me to test RTG as if I had those actual mods installed. But by including the source code in the src/api/java folder, I can still have access to the classes I need, but I don't have to test with those mods running during development.

Thanks again for bringing this to my attention - very much appreciated.

commented

@Andrey96 - I've moved all of the APIs into the src/api/java folder and it seems to be working fine. Eclipse is happy, and I compiled successfully, so that's great.

I'm just about to start testing all of the supported mods, but was just wondering if there are any 'gotchas' or any other implications of using this approach? From what I've read, it should work just fine, but I just thought I'd ask in case you had any experiences worth mentioning.