You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2010/10/30 04:15:50 UTC
How can we make River's Codebase more managable? (Was: Extras (Was:
PGP))
Thanks Mike,
I've had some thoughts about breaking the build into components
something like this:
jini-platform.jar (net.jini.*, org.apache.river.api.*)
jini-policy.jar
jini-resources.jar
river-lib.jar
river-impl.jar (com.sun.*, org.apache.river.impl.*, common
implementation files)
*service-api.jar (one for each service).
eg:
lookup-service-api.jar
transaction-service-api.jar
lease-service-api.jar
Then all the service implementations proxy's eg:
Reggie-impl.jar
Reggie-proxy.jar
Each component (or module represented here by jar files) could belong to
a separate build, that depends on other components.
The qa-platform would itself be another build, and the tests relevant to
each component would be part of that component, for fast test driven
development.
The minimum requirement for a client would be:
Java 1.5
jini-platform.jar
jini-policy.jar
jini-resources.jar
river-impl.jar
and at least one or more *service-api.jar
If a service download requires another service (which the client doesn't
directly depend) the service proxy can include these files in it's
codebase annotations.
Cheers,
Peter.
Mike wrote:
> On 23/10/2010 12:39, Peter Firmstone wrote:
>
>
>> Mike, are you interested in helping?
>>
>
> Yes I am. Unfortunately it won't be very soon - I am off on business for
> the next couple of weeks. Additionally I would be interested to see more
> discussion on how the codebase should be partitioned than my poor stab
> at it.
>
>
>> It isn't going to be easy, but we need to do it, since it enables more
>> people to work on different distinct components and will reduce the test
>> duration. It takes a whole day to run the tests, not much help for tdd.
>>
>
> Hadn't even thought about that! Good catch.
>
>
Re: modularizing river
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/30/2010 01:50 PM, Sim IJskes - QCG wrote:
> 5 modules are popping up for me:
> - buildtools
> - jeri
> - extra
> - services
> - test
Hidden under jeri (protocolstack-wise), is ofcourse the library module.
Gr. Sim
Re: modularizing river
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 10/30/2010 02:36 PM, Mike wrote:
>> On 30/10/2010 13:50, Sim IJskes - QCG wrote:
>>
>>> - find,define,declare uni-directional dependencies
>>
>> This was the main focus of my initial explorations, and I found quite a
>> bit of tangled references that make the task not-so-easy.
>
> The build tools and jeri are easily done (i hope). We dont need to
> separate api and implementation here, if you want to distribute an
> alternative implementation you can build a distribution yourself, right?
> Also, the distribution of jeri needs to be done by the system
> integrator, so no download (remote codebase jars) for jeri.
>
> Does anybody see a documentable use for the classdep tool(s) for a
> system integrator? If so we need to distribute it. If not we shouldnt.
It could be broken out as a separate tool, it's useful for determining
dependencies, when you don't know what they are, however if a project is
planned and managed, then the tool is optional. I wonder what Dennis
Reedy thinks?
>
> And as soon as we start with services we need a registry, right? Or
> shall we start with a services modules were we clump everything together?
The registry can be elsewhere, a client only needs the ServiceRegistrar
interface and associated parameter classes (Service API). I like the
idea of service modules, however the Services API's are a separate
concern and theoretically can have multiple implementations. The
service implementations are injected at runtime.
Cheers,
Peter.
>
> FWIW:
> - system integrator: somebody that takes river and adds its own code
> to build a system with it.
> - distribution: binary distribution.
>
> Gr. Sim
>
>
>
Re: modularizing river
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/30/2010 02:36 PM, Mike wrote:
> On 30/10/2010 13:50, Sim IJskes - QCG wrote:
>
>> - find,define,declare uni-directional dependencies
>
> This was the main focus of my initial explorations, and I found quite a
> bit of tangled references that make the task not-so-easy.
The build tools and jeri are easily done (i hope). We dont need to
separate api and implementation here, if you want to distribute an
alternative implementation you can build a distribution yourself, right?
Also, the distribution of jeri needs to be done by the system
integrator, so no download (remote codebase jars) for jeri.
Does anybody see a documentable use for the classdep tool(s) for a
system integrator? If so we need to distribute it. If not we shouldnt.
And as soon as we start with services we need a registry, right? Or
shall we start with a services modules were we clump everything together?
FWIW:
- system integrator: somebody that takes river and adds its own code to
build a system with it.
- distribution: binary distribution.
Gr. Sim
Re: modularizing river
Posted by Mike <mi...@gmail.com>.
On 30/10/2010 13:50, Sim IJskes - QCG wrote:
> - find,define,declare uni-directional dependencies
This was the main focus of my initial explorations, and I found quite a
bit of tangled references that make the task not-so-easy.
> Any suggestions? One request, during the discussion can we talk about
> generic module names, instead of jar or package names?
Yes, please!
--
mike morris :: mikro2nd (at) gmail (dot) com
http://mikro2nd.net/
http://mikro2nd.net/blog/planb/
http://mikro2nd.net/blog/mike/
This email is [X]bloggable [ ]ask-first [ ]private
modularizing river
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/30/2010 04:15 AM, Peter Firmstone wrote:
> Thanks Mike,
>
> I've had some thoughts about breaking the build into components
> something like this:
In order to make it easy for the people working on the build and ci
scripts, some preferences here:
- make as few modules as possible
- find,define,declare uni-directional dependencies
When the dependencies cannot be described in one direction only, either
refactor or don't split over 2 modules.
5 modules are popping up for me:
- buildtools
- jeri
- extra
- services
- test
Any suggestions? One request, during the discussion can we talk about
generic module names, instead of jar or package names?
Gr. Sim