[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] ECF 3.5 top-level features...for target platform usage
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Mon, 07 Mar 2011 10:29:07 -0800
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
On 3/7/2011 10:14 AM, Jeff McAffer wrote:
FWIW, the convention for the Target Component features has been to include the source in the feature. The idea being that someone wanting to use say "ECF" would add the ECF Target Components to their target. This would come with the bundles, source and perhaps a set of features. The features in there are used to slice and dice your function in ways that people commonly use to deploy in their applications/systems. So you could have a Remote Services features in there that points just to the binary bundles need for remote services. Then consumers could use that directly in their product definitions etc.
One of the main goals of this structure has been to make it easier for people to get started with a project. From the beginning they do not necessarily know what they want other than wanting ECF. Using this approach they can just add the ECF Target Components to their target and explore. Having a small number (e.g., one per project) of these makes if very easy for people to put together the relevant target.
For everyone's info, we now have a single top-level feature called ECF
Remote Services Target Components and an explanation of the wiki of how
to install into target platform :
As a point of interest, what does the "for Eclipse" part of these names mean? For example, "Source for ECF Target Components *for Eclipse*"?
It means that it includes all of the parts of ECF that are for
Eclipse-based tooling...e.g. the instant messaging, the example IM
clients (which depend upon Eclipse UI), etc. These parts of ECF are
only are usable/valid on Eclipse (unlike Remote Services and Remote
Services Admin, which is usable/valid on all OSGi runtimes).