On Thu, Oct 9, 2008 at 10:08 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > > On Thu, Oct 9, 2008 at 7:52 AM, Jean-Sebastien Delfino < > [EMAIL PROTECTED]> wrote: > >> Simon Nash wrote: >> >>> See inline. >>> >>> Simon >>> >>> ant elder wrote: >>> >>>> >>>> >>>> On Mon, Oct 6, 2008 at 9:02 AM, Jean-Sebastien Delfino < >>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: >>>> >>>> ant elder wrote: >>>> >>>> > (cut) >>> >>>> >>>> So this branch is really a fork isn't it? >>>> >>>> ...ant >>>> >>>> >>>> Is that a question or a statement? I don't really understand how you >>>> come up to that conclusion. >>>> >>>> It's not a fork, it's a branch to work through breaking changes (and >>>> pretty complex changes I must say) which should allow our runtime to >>>> correctly work as a set of modular bundles in an Equinox/OSGi >>>> environment. >>>> >>>> I'm hoping that this work can somehow benefit Tuscany, by providing >>>> code, patterns or maybe just a set of techniques that the project >>>> can implement to work in Equinox/OSGi. It'll be up to the Tuscany >>>> community to take a look and decide what can be reused or if it's >>>> just something to study and learn from. >>>> >>>> If the focus is purely on OSGi/Equinox support, this sounds fine to me, >>> with the resulting code/patterns/techniques eventually getting applied >>> to trunk. If it includes other restructuring or changes, I'd prefer to >>> see this kind of thing done in trunk as far as possible so it's easier >>> for the whole community to participate. >>> >>> At the moment that Equinox port is still pretty broken, I've made >>>> changes to start to clean up the dependencies on >>>> assembly.builder.impl and contribution.service.impl for example, but >>>> there are many other similar cross-bundle dependencies on >>>> implementation packages which will take time to clean up. >>>> >>>> When this is working, will it imply a hard dependency from Tuscany on >>> Equinox, or will there still be a way to run Tuscany outside of the >>> OSGI/Equinox environment? >>> >>> Simon >>> >>> -- Jean-Sebastien >>>> >>>> >>>> I guess what i'm still not understanding is why can't the most of this >>>> happen in trunk? For example - "clean up the dependencies on >>>> assembly.builder.impl and contribution.service.impl for example, but there >>>> are many other similar cross-bundle dependencies on implementation >>>> packages" >>>> - all of that is applicable to the trunk code and has no dependencies on >>>> the >>>> OSGi changes so why not just do it from the start in trunk? >>>> >>>> ...ant >>>> >>> >> Here's how I'm approaching this work at the moment (although the approach >> may change as I make progress, resolve issues or run into new issues). >> >> - Correctly running in OSGi requires significant restructuring and >> refactoring of the Tuscany runtime. It's not just about dependencies on OSGi >> APIs or changing how a few classes get loaded, it's also about making sure >> that cross-bundle calls go through defined and exported SPIs. We had well >> defined SPIs for a while but a lot of code has gone around the SPIs, instead >> of evolving the SPIs when needed and that has gone for about 18 months, so >> there's many examples of that. Now when you try to run this stuff in OSGi, >> it just breaks as OSGi is not going to allow you to go around the package >> visibility rules (and putting the whole runtime in a few big bundles that >> import/export everything is not really serious or interesting). >> > > Ok and AFAICT there are no reasons that sort of SPI clean up and module > refactoring work could not happen in the trunk code. > > >> >> - That restructuring would probably break trunk for a few months while we >> work through ways to refactor it. > > > I don't see why that needs to break trunk for months, this type of > refactoring and clean up can be done less disruptively than that, we've done > that type of thing in the earlier days of Tuscany without being broken for > months at a time. > > >> So, I'm trying to contribute enough of the refactoring and the code >> patterns that work well in OSGi in the sca-equinox branch now, to make it >> easier to do it in trunk when trunk is ready for it. I'm hoping that we'll >> then be able to do this work without breaking trunk too much and too long, >> since we'll have something to look at and reflect on in the branch. It's >> always much easier to do things a second time, when somebody has already >> been through the pain of exploring it for you and you can take a look at the >> result. That's what I'm trying to do now to help the project. >> >> > I'm _really_ nervous of this approach. It sounds so much like what happened > with the chianti fork and the disaster that caused. > > I don't believe after months of development you'd be able to easily share > what you'd learnt while doing it or that it would be just used to "look at > and reflect on". Its already becoming so different its almost impossible for > those outside to be able to make any detailed code comparisons so i just > don't see how this approach would be that useful to us for making > corresponding changes in trunk. > > I've been wondering what to do about this fork for a while now, having it > developed by one person in isolation and then forced on us as the new 2.x > code stream would be the final nail in the project IMO. Just having the fork > going on has stalled the trunk - nothing much is going on these days other > than a bit of bug fixing, i've certainly stopped bothering doing much else > as unless it gets picked up by the branch there doesn't seem much point. > > There's only one thing i've been able to think of to do so far - all join > in now while its still in its infancy. We keep saying we need a new 2.x > branch to do some breaking changes, to clean things up, and to 'innovate' > in. The final versions of the OASIS spec are coming out so we could use a > new branch to have clean support for those. Having us all work together on > this refactor and clean up would mean we'd all get a much better > understanding of the changes and would completely avoid all the issues about > how to move it forward. > > What do others think? Are you happy having the branch going on? Nervous > about what the future holds? Do you have other suggestions for changes that > might make it seem more benevolent? Is anyone else up for helping to use > this branch as the new 2.x? > > ...ant > > With only two replies to this I don't think we should go ahead with such a drastic change to trunk. As an alternative could we base the new 2.x branch on the current trunk code and right away start moving over the changes from the branch to trunk and do any further development for OSGi in this new trunk? That way we'd all start learning better whats needed for OSGi, with help we could even probably all help moving some of the branch changes to trunk. We'd still take the 1.4 branch now based on the current trunk so we'd have that stable branch for near term releases. ...ant
