river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Thompson <br...@systap.com>
Subject Re: River Musings
Date Tue, 01 Sep 2015 14:28:28 GMT
I am good with that.  Keeping net.jini makes perfect sense in terms of the
standardization process that went into river.

What are the steps to a release then?

Are there any reasons not to bring the branch in which Dennis did the
renaming to the trunk?

We do need to get the custard-apply code committed as code (rather than a
source jar).

Any other necessary steps leading up to a release?

Thanks,
Bryan

----
Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
bryan@systap.com
http://blazegraph.com
http://blog.bigdata.com <http://bigdata.com>
http://mapgraph.io

Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  Blazegraph is now available with GPU acceleration using our disruptive
technology to accelerate data-parallel graph analytics and graph query.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

On Tue, Sep 1, 2015 at 10:09 AM, Greg Trasuk <trasukg@stratuscom.com> wrote:

>
> > On Sep 1, 2015, at 9:55 AM, Dennis Reedy <dennis.reedy@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 <trasukg@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 <pats@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.
> >>
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message