Tom, Thanks for the reply. I was hoping for a reasonable discussion, I think we had one going before the request for a vote.
In any event, one of my goals with this effort was to provide a complete enough example that demonstrates the approach and structure before spending more time and providing a completely new project structure. The hope was that those that are interested in this issue would use Jira to provide comments, feedback and we could decide whether this approach has merit, and whether to move forward with it. Thus far only Peter has provided comments on the issue (and I owe Peter some responses to his questions). I am not even sure if those that have commented on this thread have indeed taken a look at the contributions to RIVER-300. I am not in favor of providing a complete body of work that may or may not be accepted. I think providing a POC, that is complete enough to address the core issues should be used as a basis to determine whether the approach has merit. If the approach provided with the contributions to RIVER-300 is not understood, I suggest that we use Jira to ask questions and we can move the issue forward. On Jan 18, 2011, at 817AM, Tom Hobbs wrote: > 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 >> >> >> >> >>
