| Re: [vtp-dev] Features |
|
so it seems we are going with original option (b), this will also
require a wrapper .all feature which for the build system. The down the road questions for further splitting these things up will potentially mean more features, but once we are following the multi feature approach that really is no problem at all. In terms of internationalization; for the ui it will be easiest to use babel, which results in language features on the babel update site, so not really for us to manage, we just externalize strings and provide maps, and then try and get people to do the translations. For multi-lingual applications we are probably talking about our own set of extensions, so we could follow a similar route and have say a french feature that would add all of the necessary french pieces to add support for french in voice applications. In both cases we are not restricted by what we decide now. I will put the features in place for this asap, is everyone ok with the original names? org.eclipse.vtp.framework.feature - for all framework plugins org.eclipse.vtp.desktop.feature - for all of the desktop (basically any workbench/ui) plugins org.eclipse.vtp.debug.feature - for all launching related plugins (including ui) Adam Berry OpenMethods, LLC On 4/1/09 11:49 AM, Trip Gilman wrote: I think we need to plan on leveraging the multiple feature structure. There are some package refactorings that need to be undertaken before it can be rational. For right now it makes sense to split the runtime, desktop, and launching/debug components into separate features. Down the road, we need to look at making a bright-line division between the base runtime and ui frameworks and those targeted at VXML based voice applications. The framework is capable of supporting other interaction modes, such as Instant Messaging. There has been some creep of the VXML subsystems into the underlying structures that need to be extracted, but otherwise the separation is there. You can see this intent in the .core and .voice versions of some plugins. Taking this into account I see a feature set that encompasses this capacity. We also need plan ahead for support for internationalization of both the voice projects for multi-lingual applications as well as full internationalization of the IDE interface as well. Do you guys have any ideas how we would want to manage that aspect of the system as well? Trip Gilman On 3/31/09 4:16 PM, "Dr. Dirk Schnelle-Walka" <dirk.schnelle@xxxxxxxxxxxxx> wrote: |