Chopping the codebase into bite-size pieces.

[Mike <mi...@gmail.com>]

As part of shaking the rust from my aging memory, and with my minds-eye 
looking towards a more modular code experience for Jini/River, I drew up 
a small diagram of how things look to me/how I think the codebase could 
be chopped up into smaller sub-projects (with dependencies).

https://drive.google.com/file/d/0B_JitrvGE8NMWnhRSWhFVW9MSWM/view?usp=sharing

It might also be a little help to people confronting the rather daunting 
codebase for the first time, or even just for understanding more about 
the various pieces in there. Please let me know where I've missed things 
or got stuff egregiously wrong.

Random comments:

I would like to chop up the "lib" box into smaller pieces - perhaps 
sub-boxes for Jeri, Security, Activation, ServiceUI and General? "Utils" 
could probably also use more chopping open. In both cases I just haven't 
delved deep enough yet (and might never, depending where my wanderings 
take me.)

I'm not sure that lumping Phoenix and Start in with the reference 
services was a great idea; I just didn't want to multiply entities 
needlessly.

I'd suggest that something along these lines serves as a basis for 
modularising the codebase into smaller mind-sized sub-projects. How much 
interest is there in doing such a thing?

Anyway,... hope it may be of some use to someone.

PS/FWIW: I note that the ServiceUI APIDocs seem to have escaped the 
build/dist process somehow; at any rate they're not available via the 
online apidocs at https://river.apache.org/doc/api/

-- 
Mike Morris
http://mikro2nd.net/
EarthStuff: http://blog.mikro2nd.net/
TechStuff: http://onemikro2nd.blogspot.com/

Re: Chopping the codebase into bite-size pieces.

[Mike <mi...@gmail.com>]

On 13/02/15 15:26, Patricia Shanahan wrote:

> Have you looked at the "River-examples project" thread? The objective is
> to create a better "getting started" experience

LOL - just started trawling through it. I did kick Jini around a decade 
and a half ago, so didn't need to go through the "getting started" pains 
so much as I could remember quite a bit of what I needed to do, up to 
writing a silly little test service (RandomNumberSupplier with - so far 
- 2 different proxy implementations.)

> It should be tested by as many different people in
> different environments as possible.

I fear that I may not have sufficient time to contribute much on that 
front, but will certainly keep it in mind should time permit. I'm in a 
Linux-only world, here, if that's a useful testbed.

-- 
Mike Morris
http://mikro2nd.net/
EarthStuff: http://blog.mikro2nd.net/
TechStuff : http://onemikro2nd.blogspot.com/

Re: Chopping the codebase into bite-size pieces.

[Patricia Shanahan <pa...@acm.org>]

Regardless of whether we actually reorganize the code base, I think 
something like this would be useful high level documentation for giving 
an idea of how things fit together.

Have you looked at the "River-examples project" thread? The objective is 
to create a better "getting started" experience, centered on a simple 
worked example. It should be tested by as many different people in 
different environments as possible.

Thanks,

Patricia

On 2/13/2015 5:13 AM, Mike wrote:
> As part of shaking the rust from my aging memory, and with my minds-eye
> looking towards a more modular code experience for Jini/River, I drew up
> a small diagram of how things look to me/how I think the codebase could
> be chopped up into smaller sub-projects (with dependencies).
>
> https://drive.google.com/file/d/0B_JitrvGE8NMWnhRSWhFVW9MSWM/view?usp=sharing
>
>
> It might also be a little help to people confronting the rather daunting
> codebase for the first time, or even just for understanding more about
> the various pieces in there. Please let me know where I've missed things
> or got stuff egregiously wrong.
>
> Random comments:
>
> I would like to chop up the "lib" box into smaller pieces - perhaps
> sub-boxes for Jeri, Security, Activation, ServiceUI and General? "Utils"
> could probably also use more chopping open. In both cases I just haven't
> delved deep enough yet (and might never, depending where my wanderings
> take me.)
>
> I'm not sure that lumping Phoenix and Start in with the reference
> services was a great idea; I just didn't want to multiply entities
> needlessly.
>
> I'd suggest that something along these lines serves as a basis for
> modularising the codebase into smaller mind-sized sub-projects. How much
> interest is there in doing such a thing?
>
> Anyway,... hope it may be of some use to someone.
>
> PS/FWIW: I note that the ServiceUI APIDocs seem to have escaped the
> build/dist process somehow; at any rate they're not available via the
> online apidocs at https://river.apache.org/doc/api/
>