2011/1/14 Dennis Reedy <dennis.re...@gmail.com> > > 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. > > +1
This is IMO the main issue: with the way the project is currently structured (which has grown historically), and the Ant build being closely coupled to the way the project is structured, any attempt to restructure (modularize) is going to give many headaches to make the current Ant build process support that restructuring, or even worse, setup a Maven build that supports it (believe me, I've done some experiments of my own). It seems the only way to overcome this is to completely rethink the structure of the project first, keeping best practices for a specific build tool (like Maven) in mind and tailor a new build process around it ... Any incremental approach has not been successful ... for me at least. On the other hand, there is already some level of "modularity": the examples/hello and the qa "subprojects", each having their own build file, inheriting common settings from the top level parent build. It's not ideal of course, esp. compared to something like Maven, but it may be possible to refine this mechanism? This has been my attempt to at least pull out some obvious things and provide a framework for further "extractions" of modules. Granted, actually accomplishing those further extractions has proven more difficult than originally anticipated. As everybody familiar with the River code base probably has noticed, is that the Ant build process we have now is basically a collection of incremental "hacks" to support the original (decade old) structure of the project and allow people to download and build in some kind of intuitive way (I know, this can be debated ...). Jini was developed when things like Ant didn't even exist yet. I feel we need a major revamp of the project structure, one that makes sense both conceptually (for understanding's sake) as technically (supporting modern build tools like Maven). - Jonathan
