This is attempting to prevent the input being fed back in
as a completion value when it shouldn't. An empty collection
should be equivalent to completing to the input.
I see the value in allowing acf users to disable the valid name check.
I think others may want to go a step further and create their own
valid name verification. Those that want to truly accept all names can simply
do `CommandManager#setValidNamePredicate(name -> true)` with the new API.
Another solution I considered was having users override the isValidName method
on their CommandManager, but this functionality seemed more friendly.
ACF deps such as timings lib and expiring map will now properly
be relocated into ACF.
This will avoid version conflicts with ExpiringMap and TimingsLib
Sadly, because locales is an exposed API, we can not relocate locales...
It will still be on plugins to add the locales relocation themselves.
Will update wiki to document this.
also updated maven plugins to newest versions, minus surefire, as
3.0 doesn't work with current setup. Went to latest 2.x there.
Got rid of a lot of duplicated shade configuration stuff across
submodules too.
This adds basic support for meta-annotations for commands and
parameters and allows users to create their own custom annotations
combining certain existing annotations and values. For example, a user
can now define their own `CustomAnnotation` which combines a
condition and a flag:
```java
@Conditions("conditionname:confitionconfig")
@Flags("flagconfig=flagvalue")
public @interface CustomAnnotation {}
```
(Necessary `@Retention` and `@Target` ignore for brevity)
And use it just like they would normally.
This works by recursively going through the annotations, instead of
just looking at the root level. The reason most existing annotations
had to be touched is for them to be allowed on other annotations as
most of them were restricted to method or fields.
Currently there's no limit on nesting because if the user wants to
nest it to obscure levels - so be it. We could decide to limit this at
some point to prevent users from shooting themselves in the foot if
that's necessary.
`@Dependency` and was specifically ignored as I don't think it makes
sense for that to be supported in this use case.
Relates to: #89
Fixes a bug introduced by PR 200. The bug related to the Values annotation which uses this getCompletionValues method also.
This is definitely not the propersolution. The underlying issue is
related to the logic calling `args` which is the original argument
array. And it should not be using arguments which have been resolved in
a previous parameter.
I was not able to find a quick/simple way to accommodate that issue.
This PR adds support for exceptions in CompletableFuture in Commands.
Usage: Just return a CompletableFuture. ACF will catch the exceptionally stuff.
```java
public CompletableFuture<Void> futuredExecution(Player player) {
return CompletableFuture.failedFuture(new InvalidCommandArgument("Failed in future.", false));
}
```
chickeneer