> On Sep 1, 2015, at 9:55 AM, Dennis Reedy <dennis.re...@gmail.com> wrote: > > 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. >
Just to be clear, I agree with Dennis here. > 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. > I for one would be entirely against losing “net.jini”! Greg Trasuk > 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. >> >
