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). Regards Dennis
