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.
