You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Sim IJskes - QCG <si...@qcg.nl> on 2010/10/30 13:50:02 UTC
modularizing river
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
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