I wasn't clear enough when starting this vote, let me try to fix that:
I intended this vote to *be* the short term reality, I.e. about getting a release out from trunk with everyone contributing. It may well be right that a single module version doesn't scale, in the longer term maybe we need to adopt one the many proposals that has been made on this subject. We can revisit all this once we've managed to get the next release out. The specifics of what extensions are included in this release is left out of this vote and can be decided in the release plan discussion. All this vote is saying is that all the modules that are to be included in this next release will have the same version and that a top level pom.xml will exist to enable building all those modules at once. We don't have so many extensions planed for the next release so i think this will scale ok for now. Does that help at all? Would anyone more vote for this now? If there isn't a reasonably large majority one way or the other I'm fine with forgetting this vote and going back to the drawing board for a different approach. I'd really prefer not to have to do that though as we need to start finding some ways to make progress, so lets keep this going till tomorrow to see how the votes look then. ...ant On 3/28/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Bert. I think I'm with you on the proposal. The rule of the game should be very simple as follows: Let's agree on a set of modules that are supposed to work together for the next target (a release or a demo), then define an assembly and pom.xml to enforce the cohesions. Thanks, Raymond ----- Original Message ----- From: "Bert Lamb" <[EMAIL PROTECTED]> To: <tuscany-dev@ws.apache.org> Sent: Wednesday, March 28, 2007 1:28 PM Subject: Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together > Would something like what I outlined in this email[1] be more amenable > to people voting against this proposal? > > -Bert > > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html > > On 3/28/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: >> I have expressed my views on all modules sharing the same version and a >> top >> down build in quite a bit of detail in my previous emails on the same >> subject. Unfortunately, I will have to vote -1 on this. >> >> Meeraj >> >> >> >From: Jim Marino <[EMAIL PROTECTED]> >> >Reply-To: tuscany-dev@ws.apache.org >> >To: tuscany-dev@ws.apache.org >> >Subject: Re: [VOTE] Use single version for all Java/SCA modules and >> >enable >> >building all modules together >> >Date: Wed, 28 Mar 2007 12:19:53 -0700 >> > >> > >> >On Mar 28, 2007, at 12:51 AM, ant elder wrote: >> > >> >>Here's the vote on this I said [1] I'd start to get closure on this >> >>issue. >> >> >> >>The proposal is to have top-level pom for the Java SCA project that >> >>enables >> >>building all the modules together - kernel, services, runtimes, >> >>extensions >> >>etc, and for that to work all those modules need to use the same >> >>version >> >>name. >> >> >> >>Here's my +1. >> >> >> >> ...ant >> >> >> >>[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/ >> >>msg16024.html >> > >> > >> > >> >There has been no proposal for how to resolve the issue about building >> >extensions using multiple versions of kernel and how modules on >> >different >> >release schedules requiring different levels of kernel or plugins will >> >be >> >handled. >> > >> >Until we can come up with a solution for these issues, I feel I have to >> >vote against the proposal. >> > >> >-1 >> > >> >Jim >> > >> >--------------------------------------------------------------------- >> >To unsubscribe, e-mail: [EMAIL PROTECTED] >> >For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> _________________________________________________________________ >> Match.com - Click Here To Find Singles In Your Area Today! >> http://msnuk.match.com/ >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
