Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of dennis.reedy@gmail.com
 designates 209.85.212.47 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=B9XhpBnLbiKKuH+nxYKHjIHFZ/oWxrwQp9/k0hUhrO4mbssqIqJnOT3bR7GwX/YyOk
         V418VbmVE8QNzOrKUcKTw08T0sM5wzPML3kFkP+/QxL26sXMOXULp4tGFwFchnIGG1Hp
         oZETRA1z3yB5kJSQwMPFKnhuDHNwrs7crHcmk=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: Need for jsk-dl.jar
From: Dennis Reedy <dennis.reedy@gmail.com>
In-Reply-To: <AANLkTimri_=7fXJoBQAEdoj5pUE6HryfA4JUd+Dj8fsB@mail.gmail.com>
Date: Wed, 5 Jan 2011 13:35:08 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <EB66AD0C-471B-4D0E-8B90-79098247F8F4@gmail.com>
References: <EF850E0D-0098-4D6D-BD02-BC5C8748ADF4@gmail.com>
 <AANLkTimApKaGHhrKFFNd9MHTBXjjjsWgdFiXzxP8J0FL@mail.gmail.com>
 <D994D0D8-7B5E-4D2F-8450-D7EF45061021@gmail.com>
 <AANLkTin_p+enBRwJditPONJiQ46aFST0gNezwA4CKLu9@mail.gmail.com>
 <7326113C-23DF-4031-A2BA-0DD38C8028F1@gmail.com>
 <4D239BDB.3020205@zeus.net.au>
 <BB499E7F-BBDE-4BBE-8341-06795B6BBF60@gmail.com>
 <AANLkTimri_=7fXJoBQAEdoj5pUE6HryfA4JUd+Dj8fsB@mail.gmail.com>
To: river-dev@incubator.apache.org


On Jan 5, 2011, at 342AM, Dan Creswell wrote:
>>=20
>>=20
>> Key to the modularization was to remove reliance on classdepandjar. I =
see
>> this as a positive, I'm not sure sure others do. IMO, it really =
simplifies
>> the project to not rely on classdepandjar, and have modules that =
produce a
>> single jar. If you all feel very strongly about having classdepandjar =
AND a
>> modularized project, I still doable, it will just take more work to =
put
>> classdepandjar back into the mix.
>>=20
>>=20
> Well, I'm no fan of classdepandjar but removing it is build hassle for =
me.
> Hassle is no big deal so long as I have a clear path forward. What can =
you
> do in terms of putting together an example or doc that shows how the
> "typical" Jini service would be built from now on (not sure Blitz is =
typical
> but there you go)?

The approach I'd give to a developer that is starting a project that =
will result in a River service is a little different from taking an =
existing well established & thought out technology such as Blitz. With =
Blitz, we're looking at a refactoring. So with that in mind I thought =
I'd give myself an hour, and grabbed the Blitz source and took an hour =
to 'modularize' it. After looking at the distribution I decided to break =
out the project into the following modules, with each module producing a =
single jar, with inter-project dependencies

blitz-\
       | - blitz-stats
       | - blitz-proxy
       | - blitz-service
       | - blitz-ui

The relationship between the modules was planned to be as follows:

blitz-proxy depends on blitz-stats
blitz-service depends on blitz-proxy
blitz-ui depends on blitz-proxy

(There are other transitive deps including Jini and Sleepycat across the =
stack but I will only mention those as a ref for now)

I added gradle build scripts and was making progress but ran into issues =
with the blitz-stats module (containing org.dancres.blitz.stats =
classes), because by itself that package has deps on other Blitz =
classes, including SpaceImpl, Lifecycle, LifecycleRegistry, Logging, =
ConfigurationFactory (etc...), and I didnt want to bring all of this =
into blitz-stats, since blitz-proxy depends on it. So, since I gave =
myself an hour and simply didnt know (well kinda knew) if the decisions =
I would make would break everything, so I stopped. If you'd like maybe =
we can talk about this offline, be glad to share what I did if =
interested.

So much for that experiment. However ...

The general approach is to organize a 'service' project as a =
multi-module project, with each module representing  the basic =
architectural element of a distributed service. Breaking this down we =
have the service's API, the service's proxy and the service's =
implementation (referenced doc =
http://www.rio-project.org/conventions.html)

Given a service project with the name of hello, the service project is =
composed of the following modules:

=95 hello-api
The hello-api module contains all the classes (interfaces and other =
classes) that is needed to communicate with the service

=95 hello-proxy
The hello-proxy module (optional), depends on the hello-api module, and =
provides smart proxy support

=95 hello-service
The hello-service module, depends on the hello-api module (or =
hello-proxy module if used) provides the backend service implementation.

=95 hello-rule
The hello-rule module (optional), depends on the hello-api module and =
provides support for rules associated with the service.

=95 hello-ui
The hello-ui module (optional), depends on the hello-api module and =
provides support for a service user interface.

What I have found is I give greater thought as to what needs to go =
where, and what the consequences are to adding classes (and that class's =
dependencies (and transitive dependencies)) to a module. With the =
multi-module structure we can focus on the creation of services as a =
tuple of api, proxy and implementation. I find it more constructive to =
have the components broken out that produce one jar, write test cases =
for each module, and then write integration test cases that incorporate =
all aspects of the service working together.

In addition, the products of the rproject are easier understood from a =
user's point of view. They follow a convention. For example, its easy to =
answer the question of what jar to include if I want to use a service, =
you would use (from above) hello-api-<version>.jar.

Note that the structure (approach) has been used with Maven, but as =
previously pointed out Gradle is also a very (very) good candidate. =
Gradle itself uses Ivy for dependency resolution, but the important =
thing is you can deploy your service artifacts to a Maven repository =
where they can be easily included by other service developers for use.=20=


I would like to think that we can take this approach to modularize =
River. FWIW, I think River is an 'easier' candidate than Blitz, and for =
what thats worth for my own project Rio [1]. River's codebase is already =
organized in such a way that is amenable to this model. The service =
packages are all fairly self contained, they have deps to classes found =
in the platform and into the application developers toolkit (jsk-lib).=20=


Regards

Dennis

[1]  Rio is also built using classdepandjar, and I am going to be doing =
this sort of refactoring for Rio over the next few months.=