Refactoring the Javaslang Organization
An organization is organic. It lives!
I plan to refactor the organization a bit as a first step towards our next major release Javaslang-3.0.0. We need small and simple parts that form a whole. What does not fit will be moved or thrown out completely.
The core will remain stable!
We move the existing modules from Javaslang core to their own repository javaslang-gwt. This is a harmless change, these modules aren't published yet.
Algebraic functionality like lift will move to core types like Option, Try etc. This API is released but, as mentioned earlier, in an experimental and unfinished state. It is more or less useless in its current state. Future algebraic additions will be part of the Javaslang core.
This repo does not seem to be maintained any more. It is not reflecting the actual projects that use Javaslang in production, therefore it has no additional benefit. Away with this ballast!
We need an integrated web page that makes all information accessible.
We will move the javaslang-circuitbreaker project outside of the Javaslang organization. The project has never been a real addition to Javaslang. It is really awesome and deserves a project on its own.
javaslang-circuitbreaker is more like a consumer of Javaslang, it simply depends on it. The circuit-breaker works best within reactive/async systems. This type of domain isn't supported natively by Javaslang, we have no abstraction for it. I don't see that we will jump on the reactive train soon. In the current development the circuitbreaker project starts to depend on other reactive streaming libraries.
The circuitbreaker is the baby of Robert Winkler, which is great btw! We see that by looking at the copyright notice. The code is not/never has been property of Javaslang, it is property of Robert Winkler.
The popular Failsafe project has copied Robert's take on the circuitbreaker (without providing the nice API using higher-order functions). I don't see why we should spend time and effort to fragment the market. It would be better to merge the projects.
Q: Why all this? Is this a 'bad' sign? Do we 'loose' something?
A: No. This is the natural way of selection. Continually growing all the things does not work (look at your legacy systems!). Growing is a pendulum — growing-selecting-shrinking, growing-selecting-shrinking, ... If we are doing it the right way, Javaslang will be stronger than before. We preserve a maintainable code base, a stable and fast iteration cycle and being responsive.