river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: [Dicuss] Build Structure
Date Wed, 12 Feb 2014 21:16:38 GMT
Greg,

I think how the River project is structured, built and tested becomes a recipe for how developers
that use River can begin to create their own projects. So IMO its something to care about.
As you point out, the current approach is based on decisions made over a decade ago and there
are reasons to change (as have been pointed out). 

If we choose to adopt conventions that produce a single jar per module, and that each module
represent a basic architectural element of a distributed  service, then we can begin to break
out and organize the project. What I had started to do was to break out River as follows:

apache-river/
    river-core/
        jsk-dl/ 
        jsk-lib/
        jsk-platform/
        jsk-resources/
        serviceui/
		
    river-services/ [1]
        reggie/
            reggie-proxy/
            reggie-impl/
        outrigger/	
            outrigger-proxy/
            outrigger-impl/
            outrigger-snaplogstore/
        mahalo/	
            mahalo-proxy/
            mahalo-impl/
        mercury/	
            mercury-proxy/
            mercury-impl/			
			
    river-start/

    river-tools/
        browser/
        classserver/

    river-integration-tests

Under each module (example reggie-proxy), we would have:

src/
  main/
    java/
    groovy/
    (other languages...)
    resources/
  test/
    java/
    groovy/
    (other languages...)
    resources/

I think the most difficult and time consuming effort would be to try and merge in the current
unit tests into each module. AFAIK, mots of the tests are integration tests, so putting them
in their own module makes sense.

We still have one deliverable, all we need to do is "assemble" the project into a distribution.
This is a fairly simple thing to do with Maven (I'm sure it's not that difficult to do with
Gradle either).

Regards

Dennis

1. In most cases an api module is not required for River core services since the API is defined
is jsk-dl


On Feb 12, 2014, at 1034AM, Greg Trasuk <trasukg@stratuscom.com> wrote:

> 
> 
> Hi all:
> 
> I’d just like to sound a quiet note of caution here.  
> 
> Everyone seems to be in agreement that the current build structure is problematic.  After
all, it was fundamentally designed around the ‘make’ tool 15 years ago.
> 
> However… Altering the build structure and switching to a new tool (Maven, Gradle, Ant/Ivy,
etc) will be a _lot_ of work, and we’ll be living with it for a while.  Let’s not jump
to conclusions without a good discussion.
> 
> So let’s start with some reflection…
> 
> It’s worth asking “who cares about the build system?”  Let’s be clear about something:
 the vast majority of developers should be using the jars out of Maven Central, or at most
running the River build once to build from source.  It’s only us, on the River project,
who are using the build system.  That being the case, perhaps we ought to talk about what
we intend to do, before we make any decisions or expend a lot of effort.
> 
> Are we thinking in terms of runtime containers or execution environments?  The core build
doesn’t matter then.  For example, the container work in progress (https://git-wip-us.apache.org/repos/asf/river-container.git)
builds with Maven, but uses the River dependencies published in Maven Central.
> 
> Are we planning separate modules for Reggie, Mahalo and Outrigger?  Those new modules
will need a build/integration test system, and we should discuss that.  Worth mentioning that
so long as the jars go into Maven Central or some other dependency management system, the
modules don’t actually need to have the same build tool (although consistency is probably
good).
> 
> What else are we planning?  Chances are, it should go into a different module.
> 
> Which brings me to another topic - how should we manage multiple deliverables?  Could
I suggest the following “deliverable sets”, which would each have different releases?
> 
> - Jini Core - Basically what’s currently in jsk-platform.jar
> - Registrar Service Module
> - Transaction Service Module
> - JavaSpaces Service Module
> - note - I’m not sure if Mercury, fiddler, etc are used all that much, but if so, they
could have their own modules
> - Jini Application Server (river-container packaged with the infrastructure services)
> - other - Rio?  Anything else?
> 
> The actual set of modules is open to discussion of course, but I’m thinking we need
to support more than one “deliverable”.  Not quite “sub projects”, since the governance
doesn’t need to be separate, but I think separate source repositories and releases.
> 
> In any case, my big suggestion is let’s not take these decisions lightly.  There’s
no hurry.
> 
> Cheers,
> 
> Greg.
> 
> On Feb 12, 2014, at 5:31 AM, Simon IJskes - QCG <simon@qcg.nl> wrote:
> 
>> On 12-02-14 11:28, Simon IJskes - QCG wrote:
>>> Ok,
>>> 
>>> what i have seen is:
>>> 
>>> - maven / gradle / ivy
>>> - convention (submodules structure)
>>> - 1 river or submodules (reedy-trasuk)
>>> 
>>> Do we need to discuss this further, or do we need a vote on the sub-items.
>>> 
>>> Gr. Simon
>>> 
>>> 
>> 
>> in order of pref:
>> - maven
>> - gradle
>> - ivy
>> 
>> conventions:
>> +1
>> 
>> submodules:
>> +0
>> 
>> Gr. Simon
>> 
>> -- 
>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
> 


Mime
View raw message