On 3/29/07, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote:
If I understand your clarification correctly, this vote is about putting out a single release with a certain number of modules in it, and with each module having the same version number. In particular, this vote does not set a cast-in-stone precedent about how future releases will be put together. Also, it is assumed that consensus will eventually be able to be reached about what the modules in the release will be (without this assumption, this vote seems pointless to me). While it is not clear to me that this is the best approach to follow from an open source project point of view, with the constraints and assump- tions above it seems to me to be reasonably safe to vote +1. So, if the constraints and assumptions above are true, then here's my +1. Thanks On 3/29/07, ant elder <[EMAIL PROTECTED]> wrote: > > 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.xmlto > > 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] > > > > >
Ant, thanks for the clarification. As I've said in previous threads my initial experience of trunk was initial bewilderment (partly down to Tuscany and partly down to maven itself) and slow understanding of the trunk build once I had been given first Raymond's and then Mario's .bat scripts to call required poms in the right order. I think there is promise in the various proposals around an assembly based system where you can specify dependencies based on released/snapshot dependencies, modules, svn:external or even reactor (?) as appropriate and I've been trying to understand the implications of it. It worked well (not sure about svn:externals yet) for experimenting with the TSS demo but I clearly can't say what the practicalities are with full on parallel development in trunk. In the future though we are going to need something like this that will scale. If the motivation now is to get everyone collaborating in trunk then you get my +1 for this proposal. This needs to be sorted though in the near future so that that we have an approach that works well for the eager newcomer as well as the seasoned developer while allowing Tuscany to grow. There is an issue still on the table that is a little orthoganol. i.e. flattening the module structure [1]. This should be a separate thread I guess but I mention it here as it may help in clarrifying the build. Simon [1] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg15905.html
