On Tue, Nov 18, 2008 at 10:50 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > > On Tue, Nov 18, 2008 at 10:44 AM, Simon Laws <[EMAIL PROTECTED]>wrote: > >> >> >> On Tue, Nov 18, 2008 at 10:36 AM, ant elder <[EMAIL PROTECTED]> wrote: >> >>> >>> >>> On Tue, Nov 18, 2008 at 10:00 AM, Simon Laws <[EMAIL PROTECTED]>wrote: >>> >>>> >>>> >>>> On Tue, Nov 18, 2008 at 9:39 AM, Simon Laws <[EMAIL PROTECTED]>wrote: >>>> >>>>> From the parent thread we debated whether to start from the equinox >>>>> branch or from trunk. I'm keen to understand the code changes that >>>>> implement >>>>> the features Ramyond has documented [1]. So as a compromise to just >>>>> replacing trunk wholesale with the equinox branch I'm going to look at it >>>>> a >>>>> module at a time. The objective being to note changes and ask questions >>>>> about the code changes here. I'll make a start and see how it goes. If >>>>> it's >>>>> too difficult the fallback is to just go with the branch. Regardless we >>>>> can >>>>> use this exercise to review the changes so that we understand the current >>>>> features in the branch and, more importantly, how they are realized. >>>>> >>>>> Regards >>>>> >>>>> Simon >>>>> >>>>> [1] >>>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/OSGi+Enablement+for+Tuscany+Runtime >>>> >>>> >>>> So first things first. The modules that are missing from the equinox >>>> branch but are still in trunk. Clearly these are not required for the >>>> branches view of OSGi support but they seem to fall into two categories. >>>> Those that are junk which I'll just remove. Those that I'm not sure about >>>> so >>>> I'll move into a /contrib/modules/folder and we can delete them at our >>>> leisure so that we understand if they are obsolete or not. >>>> >>>> modules/ >>>> api >>>> assembly-java-dsj >>>> binding-feed >>>> binding-gdata2 >>>> binding-gdata2-runtime >>>> core-spring >>>> data-engine-helper >>>> host-embedded >>>> implementation-bpel-jbpm >>>> monitor-logging >>>> >>>> modules/ >>>> binding-dwr >>>> binding-jms-policy >>>> binding-notification >>>> binding-sca-jms >>>> contribution-groovy >>>> contribution-impl >>>> contribution-jee >>>> contribution-updater >>>> contribution-updater-impl >>>> databinding-job >>>> databinding-xstream >>>> extensibility-osgi >>>> extensibility-helper >>>> host-ejb >>>> host-openejb >>>> host-osgi >>>> implementation-das >>>> implementation-data-api >>>> implementation-data-xml >>>> implementation-jee >>>> implementation-notification >>>> implementatoin-openjpa >>>> implementation-web >>>> implementation-web-runtime >>>> node-dynamic >>>> node-launcher-osgi >>>> osgi-runtime >>>> policy-reliability >>>> runtime >>>> runtime2 >>>> runtime-standalone >>>> runtime-tomcat >>>> runtime-war >>>> scdl4j >>>> thirdparty-library >>>> >>>> Simon >>>> >>> >>> I thought the plan was to bring up just the minimal modules to run the >>> calculator - the modules identified in [1] plus the test/sample from [2] so >>> we know when it works. So move everything accept those to contrib/. >>> >>> ...ant >>> >>> [1] http://apache.markmail.org/message/ofdwyjikioosc7bn >>> [2] http://apache.markmail.org/message/qocoqvieeux2ct66 >>> >>> >> Yes, agreed. But in the branch some modules have been explicitly removed >> so I wanted to call those out explicitly before going on the next stage of >> moving all but the 36 or so modules that we need to get the calculator >> working. >> >> I should have said also that the first block of modules I think are Junk >> (although I shouldn't have put host-embedded in there just yet) the second >> block are the ones I'm not sure about so should go in /contrib. >> >> Do you have the list of other modules that need moving and how do you want >> to do it? >> >> Simon >> > > Just move all except the minimal modules to contrib/ as thats already been > proposed on the ML and no one has objected. Anything else, labelling certain > ones "junk" or sorting through why things have/haven't been included in the > sca-equinox branch i think would be better with some discussion. > > ...ant > ok, fair point, let me undo the delete and let this thread record the difference for the time being. We can do the move en-mass a little later. Let's move on and look at the diffs. Simon
