The bulk rename of com.sun.jini and com.artima to org.apache.river was meant to move the namespace to the org.apache.river realm. I think it is implicit that the namespace org.apache.river defines project specific implementations of the net.jini namespace semantics. Remember, the net.jini namespace is for specification classes, not implementation (refer to the Apache Jini specifications <https://river.apache.org/doc/spec-index.html>). The further re-organizing under the org.apache.river namespace - to me - provides little value given the purpose of the namespace change. I vote to keep the namespace as it is.
If there is the desire to move everything into the org.apache.river namespace (that means net.jini namespace goes away), thats a different discussion, and one that needs to go up for a vote (like the previous namespace change went through), and provide specifics as to what goes where and why. A different (but related) topic is project re-organization, to have River conform to conventions that align themselves to a multi-module project, that reflect the basic architectural elements of a distributed service (documented here <http://www.rio-project.org/conventions.html>). I have been (as well as others) pushing for a modularized project for some time, but the modularized project does not need to remove the net.jini namespace, it would provide structure and organization over the org.apache.river namespace. Regards Dennis > On Sep 1, 2015, at 927AM, Greg Trasuk <tras...@stratuscom.com> wrote: > > > My opinion…. > > - There is “Jini API” - This is the interfaces and implementations that are > meant to be quite long-lasting and define how to build services and clients > that are independent of any particular implementation. e.g. it should be > immaterial whether a service or client runs under Service Starter, River > Container, Rio, StartNow, etc. They should all work together if they are > written to Jini API. We might think of this as the external interfaces to > the infrastructure services (registrar, transaction manager, JavaSpaces, > eventing API, etc), along with whatever other classes are necessary to use > the infrastructure services, like Entry and its subclasses, > ServiceDiscoveryManager, etc. These are associated with the solution > architecture, and are currently under “net.ini.*" > > - There is “implementation”, which provides all the plumbing to create the > individual service instances. This is what’s currently under > ‘com.sun.ini.*”. In the original JTSK, this was intended as “starter kit” > material, likely to be replaced by any particular implementation. To me, > this is a clear mapping: “com.sun.jini.* —> 'org.apache.river.*’ > > - There may be a case going forward for “Implementation API”, intended for > interfaces that should have a little more permanence. For example, I could > see there being an “org.apache.river.collections” and > “org.apache.river.collections.api”. But personally, I think that’s a weak > case. > > - “*.impl” - I tend to reserve for explicit implementation of a service. For > example, in River-examples, there is “org.apache.river.examples.hello.api” > and “org.apache.river.examples.hello.impl”. In that case, the “api” > sub-package is meant to explicitly denominate the client-side api for the > hello service. > > So in terms of recommendations, there are kind of two steps here: > > 1 - Bulk rename ‘com.sun.jini.*’ to ‘org.apache.river.*’, which is what > Dennis did already. > 2 - Discuss renaming, reorganization, modularization, etc. I started talking > about this in regards to “com.sun.ini.tools” a while ago, but we didn’t move > forward because of the size of the job. We can probably carry on discussions. > > Going forward, the question is - let’s say I feel like I need to create a new > library, “neatstuff”, and I’d like to separate neatstuff’s api from > implementation. Do I make: > > Option 1- > org.apache.river.neatstuff.api > org.apache.river.neatstuff.impl > > Option 2- > org.apache.river.neatstuff > org.apache.river.neatstuff.api > > Option 3- > org.apache.river.api.neatstuff > org.apache.river.neatstuff > > Option 4- > org.apache.river.api.neatstuff > org.apache.river.impl.neatstuff > > For me, purely as a matter of aesthetics, I have a strong preference for > (Option 1 or Option 2) over (Option 3 or Option 4), and a mild preference for > Option 1 over Option 2. > > As well, I’ll state my unifying principle again - someone writing a Jini > service or client has no need to deal with River internals, any more than I > need to compile Tomcat in order to write a web servlet. So anything in > “org.apache.river.api.*” or “org.apache.river.**.api” should really still be > considered river internals. > > Cheers, > > Greg Trasuk > >> On Aug 31, 2015, at 9:41 PM, Patricia Shanahan <p...@acm.org> wrote: >> >> On 8/31/2015 4:07 PM, Bryan Thompson wrote: >> ... >>> Why use net.jini.* rather than net.river.*? >> >> Do mean "net.river" rather than "org.apache.river"? >> >> We have domain names jini.net and river.apache.org, and can base package >> names on either of those. If we want to use anything else, we would need to >> acquire the corresponding domain name. >> >> In my opinion, for branding reasons, we should use org.apache.river.* >> wherever possible. >
