Or for me add a netbeans module that has an open license with a create Jini service class and I would definitely call that in strong leap towards a better user experience.
John Sarman On Sun, Dec 14, 2008 at 3:12 PM, Keith Campbell <[email protected]> wrote: > On Dec 14, 2008, at 11:56 AM, Wade Chandler wrote: > > ----- Original Message ---- >> >> Someone can open an issue to "pull Entry out of net.jini.core.entry and >>> put it >>> into net.jini.space." But, someone has to figure out how to do this and >>> a vote >>> has to occur to make it happen. If the committers vote no, then that's >>> what >>> happens right? >>> >>> >> Sure. I would argue that makes the system less cohesive at that point >> though because it makes it an uncommon interface at that point and actually >> means no spaces no jini which I really don't think makes sense. I would much >> rather see a set of sub projects in the whole with entry, transaction, >> lease, etc being in a common module usable by the other classes now and any >> future sub-projects which may not want to depend on all the other pieces of >> the whole (what ever that may become). >> > > I use Jini, usually without explicit use of JavaSpaces, so moving the Entry > spec into the space spec would not make sense for me (so I concur with your > concern about making the system less cohesive). > > I think that having implementations of various components like the > transaction manager and discovery manager that can execute within the same > JVM with no fuss might be a more prudent direction. > > I think the issue that needs to be solved is how to make a better "out of > the box" experience (it just works!) for developers (add the dependency to > your maven project, and make a few reads and writes to a java space that you > create). > > Keith >
