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 <si...@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

Reply via email to