On Fri, Nov 14, 2008 at 3:31 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
> > > On Fri, Nov 14, 2008 at 11:24 AM, Mike Edwards < > [EMAIL PROTECTED]> wrote: > >> Simon Laws wrote: >> >>> >>> >>> On Wed, Nov 12, 2008 at 11:08 AM, ant elder <[EMAIL PROTECTED]<mailto: >>> [EMAIL PROTECTED]>> wrote: >>> >>> >>> >>> On Wed, Nov 12, 2008 at 6:34 AM, Ramkumar R <[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>> wrote: >>> >>> Hi Simon, >>> My preference would be to "Start with the smallest set of >>> modules possible and iterate toward OASIS compliance adding in >>> more function/extensions as people address different >>> features/specifications", >>> as I believe this option would give us a more clear direction on >>> where we are heading towards. >>> >>> >>> On Tue, Nov 11, 2008 at 3:02 PM, Simon Laws >>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> >>> >>> wrote: >>> >>> Several alternatives have been suggested [1] which I >>> summarize here. >>> >>> A) Start from what we already have in trunk, develop the >>> OASIS function, introduce new improvements or improvements >>> from the Equinox branch as appropriate >>> B) Start from a completely clean trunk and build up from >>> there based on the resources we have in the the 1.x code >>> stream, in the Equinox branch or from new developments >>> C) Start from what is in the Equinox branch >>> >>> Is this correct? Are there other combinations people want to >>> consider? There is a related question of how we develop >>> trunk toward OASIS compliance. I see two extremes; >>> >>> i) Start with a full set of modules and update to OASIS >>> compliance while keeping all the function we have running >>> ii) Start with the smallest set of modules possible and >>> iterate toward OASIS compliance adding in more >>> function/extensions as people address different >>> features/specifications. >>> >>> Again, are there other approaches? >>> >>> The object of this discussion is to agree the starting point >>> for future trunk development. If you don't have other >>> options to add it would be useful for you to express a >>> preference so we can see what people think. If we can't come >>> to a conclusion in the next couple of days though this >>> discussion we will have to identify a small number of >>> options to vote on. >>> >>> Thanks >>> >>> Simon >>> >>> [1] >>> >>> http://www.mail-archive.com/dev%40tuscany.apache.org/msg03215.html >>> >>> >>> >>> I liked what was said over on the other thread [1]: >>> >>> "...starting afresh in trunk based on the assets that we already >>> have, primarily that it gives us all the opportunity to feel >>> involved in how Tuscany v2.0 will look" >>> >>> So i guess thats closest to (B ii). Its not that clear yet how this >>> would actually work but it sounds like a good thing to aim for. >>> >>> ..ant >>> >>> [1] http://apache.markmail.org/message/apawwigihmpgx7sk >>> >>> >>> >>> Yes, my choice would be B ii also. How would this work? >>> >>> Firstly I'd like to see us define a relatively short (max two weeks?) >>> timescale for getting the minimal function working in the new trunk. This >>> will focus the mind and help us not get sidetracked with other fluff. >>> >>> I would propose that we set ourselves the objective of getting a simple >>> scenario (e.g. calculator) working to demonstrate the trunk structure and >>> operation. >>> >>> We need to identify those issues that must be addressed in this bring up >>> stage and define a strategy for address them. I believe this will come out >>> of the themes thread. >>> >>> Then work out who wants to tackle each topic and drive the thrashing out >>> of the details on the ML/in the code . We may have to accept that there may >>> be things we can't do in parallel so this has to be a collaborative exercise >>> with those currently active keeping the ML up to date giving the opportunity >>> for others to jump in. >>> >>> Ultimately one person is going to have to commit some initial modules to >>> trunk and we will soon hit the "where do they come from issues". To help me >>> with this question I'd like use to understand >>> >>> 1. What modules from trunk today would be the minimum set needed. I can >>> go an pull the dependency list from the calculator sample. >>> 2. With this minimum set what is the difference between these and what is >>> in the Equinox branch. Can someone familiar with the branch explain please? >>> >>> Once we get to the minimum function stage we can test it and introduce >>> other features and changes in a controlled manner while adopting the best >>> practice that has been established. >>> >>> Simon >>> >> Folks, >> >> One question worth asking is whether the idea is to move to OASIS >> compliance and to OSGi/Equinox at the same time? >> >> It might be a good idea to do these together, especially if we're starting >> with something small and building it up piece by piece. >> >> >> Yours, Mike. >> > > Agreed. At the macro level that is the object in my opinion. At the > detailed level we need to get the minimum set of modules up using the OSOA > function in the first instance. I would like to see us support both OSOA and > OASIS on the improved (OSGi) runtime in order to capture the widest possible > interest and help us move off 1.x eventually. > > Simon > I'm just posting here to record that we've made a start on the 2.x development in trunk. We sort of took the B)ii) approach but Luciano took a pragmatic approach ang merged whichever way was the easiest between trunk and the equinox branch. We're bringing up the minimum set of modules as we speak so this discussion is done with. Simon
