River imported packages of code from the original Sun grant under the
name 'com.sun.whatever'.
How important is it to change that?
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands,
if you care to be able to run on a different JVM, than it needs to be fixed.
Generally it's bad to rely on some private packages/APIs
-M
On Tue, Oct 12, 2010 at 6:50 PM, Benson Margulies bimargul...@gmail.com wrote:
River imported packages of code from the original Sun grant under the
name
Hello,
the Etch community voted on and has approved a proposal to release Apache Etch
1.1.
A vote on the etch-dev@ list already resulted in three +1 from Incubator PMC
members:
- Doug Cutting
- Martijn Dashorst
- Gavin McDonald
The proposal for the release was:
From a name and branding perspective, removing the use of com.sun, could help
people focus on River as opposed to Sun's Jini Implementation. I have
several references to com.sun.jini.start. But, I also have my own fork of 2.1
that I'm still using in active deployments. River should be River.
From the mentor standpoint, what's important to me is that there is no
ASF requirement to change those packages. The community can decide to
do it sooner, later, or not at all. The community can decide to make a
slew of compatibility wrappers. The community, most importantly, can
push toward a
I vote against such an incompatible change. There are a lot of classes under
there, for example com.sun.jini.thread.TaskManager, that are utility code
employed by downstream developers. I think all new code should go elsewhere if
possible, but changing the existing com.sun.jini packages would
