UndoFX might be more flexible in some cases (e.g. non-linear history and such), but for our and most other purposes this solution should be more than enough.
I don't think the scope has anything to do with the version: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
There is a possibility to…
I would prefer having gaps of 10, or maybe 100, but with exponential gaps, the rule is unnecessarily complex and we can easily surpass Integer.MAX_VALUE / 2, which is the default order for JUnit…
A project using this library should be able to use any JavaFX version >= 11. A fixed version would be defined like this: [11]. <scope>provided</scope> assumes that the dependency is present in…
You mean the string literal? So for every property that is declared we would declare another constant?
I think the wrapper can be concrete, but should be open for extension in case we want a wrapper for a change manager with additional methods.
We discussed this in #2. I think @DieGurke resolved the suggestion as we didn't reach a conclusion after stating our opinions.
The core module doesn't have any dependencies, so this shouldn't make a difference.