I'd like to think the future lies with River, it's mainly directed at solving
existing River issues with security, modularity, jdk9 and IPv6 support among
others.
The commit history is available on github. If River migrates to Git, the
change history can be preserved.
Hopefully review and
Some notes on backward compatibility:
River 2.2.3 and 3.0.0 break compatibility (with River 2.2.2 and Jini 2.1), the
former after removal of Activation and JRMP exporter, the latter with the
com.sun.jini -> org.apache.river namespace change.
I've chosen deprecation over removal, module
I do not have a huge problem with detached development. The work could
always be brought into a branch for review and commentary.
In general, I think the broader question is status quo vs active
development.
I think that there is some consensus around the need for river to evolve,
especially in
How do you envisage the future of this work?
Personally, given the volume of changes outside svn, without any review
or commit messages, I am not sure I would vote for an Apache release
based on this code. Do you have a quorum of PMC members who do feel
comfortable with this process?
On
Forked from River trunk just before 3.0 release.
* Security focused:
o Supports updated modern cyphers, support for vulnerable
cypers removed.
o Reimplementation of serialization, includes input validation
and defensive programming.
o
