[Declined] Switch away from a collective API module

[lokka30]

I am overall quite happy with how Treasury has launched, I was not expecting it to be as smooth as it is. Looking back, I think we made two mistakes in the library's fundamental design.
Unfortunately these changes will annoy the few developers who are currently using Treasury, but I think it is in the library's long-term interest to resolve. They should understand, and the current Treasury implementations we are aware of are very simple. Better to change things now, then when it will become so much difficult to later.

• Check this if resolved (be it confirmed or denied, but not pending).

---

Current votes:

• Yay:
• Nay: @MrIvanPlays @lokkka30 @MrNemo64 @Jikoo
• Undecided:@yannicklamprecht @creatorfromhell

---

Problem: Collective API Module

Edit: I don't think this is a large problem upon reflection. However, I'd still like to hear what you all think.

I believe having all APIs in a single module will cause trouble down the line. We will be limited to how many APIs we can include in Treasury, in fear of making the API archive too large.

I propose that we split each API into its own package.

I have the following module list in mind (removed modules have strike-through formatting, potential future modules have italicized formatting):

• core
• api/economy
• api/service
• api/event
• api/permission
• api/chat
• api/region
• api/vanish
• platform/bukkit/plugin
• platform/bungeecord/plugin
• platform/velocity/plugin
• platform/sponge/plugin
• platform/bukkit/api/economy (will be removed in the next Treasury version)

---

Please post your thoughts below. Be raw, there is no need to put on a kind mask in this debate, but don't be rude. Provide adequate reasoning for your opinion if you'd like to share it.
I post this in hopes to improve the library, I am not suggesting that this change must be done.

Tagging users who may be interested: @MrIvanPlays @Jikoo @MrNemo64 @yannicklamprecht @creatorfromhell

[MrIvanPlays]

There is no "too large" jar.

[MrNemo64]

We basically have only interfaces and documentation, it's not that large. I highly doubt the size will become a problem

[Jikoo]

I agree with MrNemo64 - interfaces and documentation and a small plugin managing providers will not be a lot.

In addition, this negates the issue I was talking about in the versioning thread - if we have multiple modules of Treasury, say we release a new Core version specifically for features required by Permissions, we would not necessarily need to release new versions of all other dependent modules. This means Permissions and Economy would provide different versions of Core, which means it's potentially unusable by plugins depending on both Permissions and Economy because there's no guarantee which version of the class would be loaded first.

Having an uberjar makes everyone's lives easier except for the tiny inconvenience of the server owner who has to download and store a slightly larger file. It largely doesn't even consume more memory at runtime due to how the lazy class loader works - classes aren't loaded out of the jar file until accessed.

[lokka30]

Overwhelming opinion to keep things as-is, enough so I've also jumped on the 'no' wagon here, thank you all very much for the opinions. I'll mark this as resolved since we won't change this.