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: build mechanisms
Date Fri, 14 Jan 2011 12:37:55 GMT

On Jan 14, 2011, at 349AM, Sim IJskes - QCG wrote:

> On 13-01-11 12:47, Tom Hobbs wrote:
>> Personally, I feel a sense of "if it's not broken...".  I think it was
>> Dan (but maybe not) who said that the build is the way it is because
>> "it works".
> Exactly. Before we step into a new build system, we should first determine what is actually
wrong with the current build system.
>> But that aside, does using something other than Ant give a tangible
>> benefit?  If "yes", then I have no objection.
> Exactly, if there are big benefits, then i would accept another system. Now we have a
system where many have invested their time in, and are we going to throw this away?

The drivers for this issue are not simply to replace one build system for another. IMO, the
drivers for looking at changing how River is built is to improve the organization and structure
of the source code, allowing it to be more modular, and to improve the speed upon which one
can develop, build and test each of it's constituent components. I also think a side benefit
will be greater understanding of the project source by other developers (external to River).
With a monolithic project structure its hard to know what fits where, and what needs what.

The current project structure does not allow this. Once you start to reorganize the project
to make it more modular (and as a side-effect more understandable because each module reflects
its basic architectural role when done right), you can quickly see that something like Ant
does not provide the support needed. Technologies like Maven and Gradle do. Maven is much
more mature, Gradle looks very promising. The good part is it doesnt matter which one we choose,
the same source code structure is used with both of them.

Its not looking for a better way to build, its choosing the right technology to get the job
done. If the project does not think that there are benefits to the reorganization and modularization
of the source code, then no changes are needed. Stay with what you have. If however River
sees the benefit of the reorganization, then we must be open to introducing other project
tools that may replace the current approach.

As far as where this gets done, for now it's on my computer :) Seriously though, the right
place is a branch, until you release. Then I suggest River votes on taking this as a next
step. Part of this step should also include the namespace rename from com.sun.jini.* to org.apache.river.*.
I suggest that the net.jini namespace remain as is (in the work that I have been doing I have
taken the liberty of making the namespace change).


View raw message