I don't think breaking River up into these subprojects will make
things easier, provide value, or further the overall interest in
the project and technology.
This has been a very long thread, and I am concerned that
some may be tuning out due to its length and lack of
specificity and due diligence of actual proposals. In the
interest of the project, I'd like to ask for posters to first read
through the specifications (available at:
<http://java.sun.com/products/jini/index.html>
or
<http://www.jini.org/wiki/Category:Jini_Specifications>
and read through the code and structure. There was a comment
by one poster that he "hasn't even bothered to look at the
implementation", and I think if he and others did, there would
be a more educated dialog on the list.
There is certainly plenty of work that we should do in the short
run, for example:
* finalize the AR2 release
* complete the Apache River project section, including:
Documentation, Javadoc, etc
* fix up the Apache incubator page:
<http://incubator.apache.org/projects/river.html>
* really create a 'todo' list for new and interested developers,
and communicate through the list and the "Get Involved" page
* etc
Proposals with "meat on the bones" ;-) are all most welcome,
but there doesn't seem to be adequate thought and pre-work
put into them before throwing an idea out on the list and creating
long discussions.
The message of making the entrance into the technology easier is
consistent - it would just be good to vet actual proposals that
have been worked out with effort in advance that address this.
I'm trying to change the tone and focus of the mail list dialog
with this email. Please don't respond directly to it on the list - I
don't
think it's healthy for the project and won't engage in a discussion that
won't further advance the project.
-Jim
committer, Apache River incubating project
On Dec 21, 2008, at 2:49 AM, Niclas Hedhman wrote:
On Sun, Dec 21, 2008 at 3:41 PM, Michael McGrady
<mmcgr...@topiatechnology.com> wrote:
My position is that JavaSpaces has value aside from the objectives
of JINI
and should be able to stand alone and to be consistent with JINI
competitors
just like RMI is (without discussing the JERI issues). To do that,
JavaSpaces cannot depend on JINI interfaces, even if present JINI
interfaces
include things that JavaSpaces must depend upon. That is
fundamentally
where I stand.
So, if I claim that we have subprojects;
Apache River Lease
Apache River Transaction
Apache River Entry
Apache River JavaSpaces
Apache River Jini Service Platform
Would you then be happy?
(Because that is what we in reality have.)
Cheers
Niclas
