arcaneplugins / treasury Goto Github PK
View Code? Open in Web Editor NEW🏦 A powerful multi-platform library for next-level plugin integrations.
Home Page: https://hangar.papermc.io/ArcanePlugins/Treasury
License: Other
🏦 A powerful multi-platform library for next-level plugin integrations.
Home Page: https://hangar.papermc.io/ArcanePlugins/Treasury
License: Other
I never liked Bukkit's command framework. Especially that since 1.13 we have brigadier and still can't use its features by plainly utilizing the bukkit/spigot api.
That's why I suggest using cloud, and particularly cloud-paper
. It adds up 1 more layer on top of brigadier and bukkit's command system, allowing you to create custom arguments and much more. Don't worry - if you decide to support versions under 1.13, it will fallback to registering commands with bukkit.
Requires #6.
I believe this was discussed in #37.
This issue will be on hold until #37 is completed.
I haven't used modules before, I might need pointers here. I'm also very interested to hear what modules developers think Treasury should have. I'm thinking:
treasury-api
treasury-plugin-bukkit
, treasury-plugin-sponge
, etcAny commands Treasury has which work with its own APIs should be categorised.
For example, /treasury migrate
should instead be /treasury economy migrate
.
I would also like to split the part of /treasury info
which provides information about the economy provider to a separate command, /treasury economy info
. This command would also be able to tell more information since it isn't restricted by all the other information the other command has.
I am unsure whether /treasury info
should become /treasury plugin info
or not. I am currently quite against that but if anyone else thinks it's a good idea then let me know below
Tasks:
/treasury migrate
to /treasury economy migrate
/treasury economy info
/treasury info
plugin.yml
and the Wiki pageI have no experience using CompletableFutures yet. I also don't think the migrate
subcommand has been seen by anyone, or at least commented on. So I think it would kill two birds with one stone if anybody could kindly assist me in updating MigrateSubcommand.java
to use the new CompletableFuture methods (which your IDE should highlight as errors).
Cheers :)
(at 21st Dec 2021)
<distributionManagement>
<repository>
<id>codemc-releases</id>
<url>https://repo.codemc.io/repository/maven-releases/</url>
</repository>
<snapshotRepository>
<id>codemc-snapshots</id>
<url>https://repo.codemc.io/repository/maven-snapshots/</url>
</snapshotRepository>
</distributionManagement>
Follow instructions here.
Follow the instructions here.
Follow the instructions here.
Follow the instructions here.
Aside from it being an magic value, the only location where an API version is defined is in Treasury#apiVersion, which just makes the problem worse especially because it's visibillity would allow the developer to return said value without a problem.
I thus propse to have some way of obtaining the API version for version X of the plugin. This can be done similarly to how Objectweb ASM does it, i. e. define a constant (let's say TREASURY_API_EXPERIMENTAL
and TREASURY_API_1
) in the EconomyProvider interface, though I don't have anything against having it be located in a different location. All things considered the current way of doing it is suboptimal
An Economy Adapter is a separate API from Treasury's main economy API. This API will allow a plugin to use one dependency which will automatically use Treasury or Vault on a server, with very similar methods to Vault's. This will make it extremely easy for a plugin to support Treasury, if it is already too difficult to add direct Treasury support.
Of course, using Vault, the Economy Adapter will be forcefully limited to only being able to offer Vault's Economy API's features since Treasury has them all anyways.
This issue was suggested by Jikoo with this post:
I would probably want a generic utility supporting Treasury, then falling through to Vault/whatever else pre-written for me to consider adopting it, honestly. This might even be your best bet for wider adoption - a really well-written plug-and-play utility would remove a lot of the horribly janky "definitely optional dependency" handling I've seen from people (myself included, shame on past me) adopting Vault.
The Economy Adapter will also do some inherent improvements to Vault, e.g. forcing the use of UUIDs wherever Treasury does.
A crucial change in this API is that non-player accounts (in Vault this is Bank Accounts) must require an owning member as Vault's API requires this.
I'd like to hear what other developers think about this suggestion, and especially if there are any comments on my plan.
thoughts wanted
unassigned target version
status: on hold
The methods in EconomyProvider such as hasTransactionEventSupport
can be replaced with a single method returning an enumset specifying a list of things that the economy provider supports: getSupportedFeatures
This is an issue, because if we were to add new features to Treasury and thus add new 'has..Support' methods, then older api-versions won't have this method overriden, I assume causing a NoSuchMethodException.
Since the enum can expand over time, and plugins can assume any unlisted constants are unsupported, it's all solved!
The Spigot page is outdated at the moment. I want to edit it to make it more accurate and concise.
-snip- see Spigot page. This GitHub issues page is no longer updated with the content of the Spigot page.
Please propose any changes to this page below. Still work-in-progress.
Tagging users who may be interested: @MrNemo64 @MrIvanPlays @Jikoo
Hi all,
I have finished my comparison of Vault, Reserve and Treasury on this Wiki page. Please tell me if you disagree with anything, I am only looking to make an accurate comparison.
I'll close this issue if there is no activity for a certain period.
Tagging users who may be interested:
@Jikoo @MrIvanPlays @Geolykt @MrNemo64 @NoahvdAa
Unlike vault, Treasury provides multi-currency support. Given that this multi-currency support is a thing in the backend, API users may be tempted to expose currencies to the frontend. Implementing /balance
is implemented easily, albeit expensively by iterating over each and every currency and doing other trivial operations. However commands such as /pay
would be a lot more complicated to implement as now you'd have to parse the amount.
It is rather easy if you have a syntax that operates like /pay <reciever> <amount> [currency]
, where as currency has to be a currency name; easy enough to implement given that the currencies name can be looked up easily via Treasury API. However what if the User wants to format the amount to something like 15€
? As far as I see there is no sane API to resolve that currency. The same applies to $ 15
, $15
, 15 USD
or 15 €
. An API user would not like to do this parsing hell manually so I propose an API to allow parsing strings such as the previous examples. This is aided by the fact that Currencies are only provided by the economy provider, so 3rd party currencies would not prove to be much of an issue.
What would the best course of action be here?
It simply doesn't feel right working with Strings when the whole selling point of the API is that it is using persistent UUIDs.
Also changing the world name changes the world name, but keeps the UUID, so linking it to an UUID would be better than linking to a world name.
Oct 10 21:14:21 <Geolykt> is there any disadvantage of storing a world by name instead by it's UUID? And would renaming a world also change it's UUID?
Oct 10 21:15:28 <DiscordBot> <Cryptite> So aside from one first-time world hiccup thing... this seems to work: ((CraftPlayer) p).getHandle().smoothWorldTeleport = true;
Oct 10 21:15:36 <DiscordBot> <Cryptite> https://cdn.discordapp.com/attachments/555462289851940864/896838389922431057/SeamlessTP.mp4
Oct 10 21:17:00 <phoenix616> renaming doesn't change the UUID, that is stored in the level.dat
Oct 10 21:17:27 <DiscordBot> <HexedHero> disadvantage is that owners could change the world name
Oct 10 21:17:58 <Geolykt> So just what I thought.
Oct 10 21:19:11 <DiscordBot> <electroniccat[no-ping]> for persistence you don't want people to touch, I often store both, and prefer uuid and then name (but, honestly, I rarely care to add that fallback)
Oct 10 21:19:11 <phoenix616> technically it's also an advantage, really depends on what your goal is
Oct 10 21:19:32 <DiscordBot> <electroniccat[no-ping]> config files and such often use names because, well, people can actually see them
Oct 10 21:23:03 <Geolykt> Well, in this case It's developer API stuff, UUID makes more sense then
(#paper-dev @ irc.esper.net)
We can use ServiceRegisterEvent
to check when one has registered, then just run some logic.
The .gitifnore file is an important part of a git repository, how ever the .gitignore of this repository doesn't cover all files. Since it only contemplates Intell Idea, contributors using other ides will have trouble. I propouse using a more extense file, there are good generators online that can do the work, for example, this would be a .gitignore template for Intell Idea, Eclipse, Java and Maven
@MrNemo64, what do you think about this idea? I believe there should only be bank members, but of course each bank member can have different permissions.
What's the purpose of bank owners compared to bank members? Should we only have bank owners or bank members? Or should both exist?
See discussion here.
Tend to the points raised in the Spigot thread. As of writing this I don't have time to sort them out yet, need to make sure they don't slip past. :)
See discussion here.
Right now the EconomyAPIVersion class is really simple: Identifyes mayor versions with a number, not more not less. I think this should change. I propose some changes
@since
tag, instead of @since v1.0.0
we could use @since {@link me.lokka30.treasury.api.economy.misc.EconomyAPIVersion#VERSION_1 v1.0.0}
in the documentation shows the same but it provides a link to the enum versionVERSION_1
we could use v1_0_0
Comparable<>
interface with the default logic being indexes. Since this logic doesn't necesarily apply to us it would make sense to specify out comparing logicI can make a class with this features so you see what I mean
Currently the Javadoc format follows a pattern: author - see - since - description - parameters - throws - return
This format creates the problem that JavaDoc genertors think that the description is part of the see tag, we can see this by generating the javadoc.
Another problem with it is using formatting options that don't exists in the JavaDoc like `Marked` This JavaDoc was generated using the java 8 jdk
As recommended in this reply by [Geolykt]((https://github.com/Geolykt), the license needs to change to a simpler, permissive one. I'm thinking MIT. Awaiting feedback on this.
I'd like to implement a Permissions API into Treasury.
I'm very interested in what anyone has to say about this, since this is the perfect opportunity to create a great Permissions API.
I'm unsure when this will be added, and the Economy API is heavily prioritized over this.
As said by @MrIvanPlays here, just by adding the @NotNull
anotation we don't ensure that a parameter won't be null
the plugin is going to be build and deployed to maven repositories via a CI and not by intellij/human, so if you want that code to generate not just if you compile via intellij, you need to find a maven plugin which does it and put it. But that has nothing to do with this PR.
This means that a null parameter could be provided when non null parameters were expected, in this case the EconomySubscriber should failt but the only FailureReason that could be provided is OTHER_FAILURE
, as there is no failure reason for null parameters
This is why I propose to add a NULL_PARAMETER
failure reason
The other option would be to find a maven plugin that allows us to have the @NotNull
anotation actually check the parameter but in my opinion, we should avoid using others plugins when necessary
Address concurrency using CompletableFuture
so that, in the event data is not cached, a plugin won't freeze the server (if it's designed properly) whilst the economy provider fetches the data from its database.
See discussion here.
I've started doing javadocs and stuff, and I got to start documenting the currency conversion system.
The currency conversion design flaws I've seen so far
In my opinion, this API shouldn't exist at all. I mean, if you want to jump through currencies, there should be another way to do that.
As for the currency interface: it shouldn't be an interface after all, but rather an immutable object which holds the data this interface holds, and some sort of a CurrencyFormatter interface and some sort of a CurrencyStartingBalanceGetter or something.
There have been a few ideas going around of improving Treasury through means which are inaccessible to Treasury's current minimum requirements of Java 8 and Minecraft 1.7.
The following is my opinion of course, please comment below if you would like me to amend this in any way.
I'm interested in hearing what you all think.
I'll call these Minecraft versions 'major': 1.7, 1.8, 1.12, 1.16, 1.17 - they are used by lots of people relative to the other versions.
Edit:
After the discussion here, I feel like the hasXSupport
methods are a bad idea and I would actually like to see Treasury drop the idea of not implementing the entirety of its interfaces.
It really doesn't make sense to me to have 50% of the methods be designed to not be implemented. Anyone who does offer Treasury support should be able to offer bank support with minimal extra work due to how similar the accounts are.
If we do truly want a method to check for support that should likely just be rolled into the API version system, not the provider interface(s). The javadocs for each method state the API version it was added in and the provider states the API version it was programmed against.
Original writeup:
I would like to see EconomyProvider
separated into several interfaces.
As a developer, it makes it a lot easier to work with player/bank accounts if I know exactly what is available to me rather than constantly re-checking if banks are supported and whatnot.
As a server owner, the increased granularity makes it possible to invent a solution that more exactly suits my needs by selecting the exact bank and player account implementations I want.
TreasuryApiProvider
CurrencyProvider extends TreasuryApiProvider
ServicePriority.Lowest
AccountProvider extends TreasuryApiProvider
requestCurrenciesInUse
or similar method
CurrencyProvider
to support undefined currencies, making migration easier.PlayerAccountProvider extends AccountProvider
PlayerAccounts
BankAccountProvider extends AccountProvider
BankAccounts
PlayerAccountProvider
MyEconomyImpl implements PlayerAccountProvider, BankAccountProvider
to mimic Vault style interface usageUse MicroLib's async update checker.
One of my recently updated plugins uses a special update checking class, I'll take a look at that.
@MrNemo64 suggested the following method: public Collection<BankTransactionEntry> getTransactionHistory() { ... }
Will expand on this issue later. If anyone has thoughts on this issue please drop them below :)
Make the Currency ID an UUID, it fits better into the Minecraft Plugin world.
Please see #37 which is an in-progress resolution to this issue.
I'd like to add a Protection API to Treasury. This involves adding simple methods to check if a Location
is within any Protection plugin's claims.
Protection plugins prevent a certain location from being modified by players, such as building there, interacting with blocks, entering the location, and many more checks are done by all of the different Protection plugins out there. These plugins are WorldGuard, ClaimChunk, TownyAdvanced, PlotSquared, Lands, and so on.
I am interested in what other developers would like to see in this Protection API.
I'm prioritizing the Economy API to be fully completed before I consider working on the Protection API. I don't know when it will be added after that happens.
This module would feature stuff such as gson serializers for Account
, NonPlayerAccount
, PlayerAccount
, Transaction
and Currency
.
I don't think such stuff shall be part of the general API as not every economy provider will choose to support gson for storage or would like any of these enhancements.
Another names for this module I can think of is api-enhancements
or api-extensions
or api-qol-utils
if you do not agree with the name I suggest.
This is a low prio issue, not really important, I'm opening this for discussion.
I'd like to implement a Chat API into Treasury.
I'm very interested in what anyone has to say about this, since this is the perfect opportunity to create a great Chat API.
I'm unsure when this will be added, and the Economy API is heavily prioritized over this.
Before v1.0
is released to Spigot, it must be tested. The following checklist will be edited as testing proceeds.
Currently this issue is on hold since the plugin is not ready for testing - it is still in development.
settings.yml
file (toggle the update checker, see if that functions)/treasury
commandsmessages.yml
file (change some subcommand messages, see if that functions)The API is highly likely to work, and it is currently too difficult to test, so any bugs found after release will be promptly resolved.
This is currently being worked on by @MrIvanPlays and I.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.