This fix has side-effects where secondary command aliases do not fully
use the commandcompletion - alternative solutions are being investigated
This reverts commit 6c8bb2620c, reversing
changes made to 01d900efd8.
Users should only need to know information about unusable constructors
if the subclass subcommand doesn't successfully register.
Theory being that the constructor could exist for other purposes
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
chickeneer