I get the feeling that this discussion is losing its usefulness and focus. Maybe I'm reading it wrong, but I think that one of Sim's concerns is that the current build process is pretty badly documented. It's not always immediately obvious what tasks do what, what the relationships between them are, or what the point is of various artifacts and things of that nature. Which is a fair point.
I *think* (and please correct me if I'm wrong) is that he doesn't want us to repeat that mistake when coming up with *any* new build mechanism, be that new ant scripts, poms or anything else. His view is that a design document when discussing any new system could automatically become that explanatory documentation once the new system is done. Is that right? Currently on River-300 there are poms, new directory structures etc. It would be nice to see some documentation regarding what module lives where, what it's purpose is, how it is built and tested and what it's relationship is with other modules. For someone with no River/Jini background that would be very useful. I think that the new page that Peter has started is possibly designed for that kind of thing. Is that right? Let's not let this conversation degenerate any further though. Let's wait on River-300 to be announced complete, all review it and then we can judge what else it needs (if anything) and any other changes before we take a vote on whether to accept or reject it. On Tue, Jan 18, 2011 at 1:05 PM, Dennis Reedy <dennis.re...@gmail.com> wrote: > > On Jan 18, 2011, at 729AM, Sim IJskes - QCG wrote: > >> On 18-01-11 13:08, Dennis Reedy wrote: >>>> But i maintain, i will vote -1 if there is no document describing the >>>> underlying functions. It doesn't have to be a big one, but i still want it. >>> >>> Underlying functions? Explain. >> >> Explain what? What a function is? >> >> http://en.wikipedia.org/wiki/Function_%28engineering%29 > > Really? This is the discourse you would like to have when discussing this > issue? Pointing me to a wikipedia article to describe terminology? You cant > simply provide feedback on what you mean by underlying functions? > > >> >>>> This document can serve as a basis for explaining the build process on the >>>> website. >>> >>> This is the build process for the work contributed to RIVER-300: >>> >>> gradle build; gradle -q dist >> >> Your are making a joke right? I can read a manual just as you do. Something >> that adds to the process please? > > No, no joke. The documentation above is pretty much just as complete as the > instructions for building the distribution as documented on > http://incubator.apache.org/river/building-river.html > > > > >
