Common features for CS-Studio product

[gcarcassi]

As a first step to a common CS-Studio product, we should factor out all code and features out of the product directories, so that the products only consist of configuration files and references to features.

Common features are at the granularity at what a user will want to install in a product. They are also limited to UI, so we will not break up UI part from non UI part. Therefore, server and rap will not be the aim, as in those cases users will not connect to a p2 repository to install/update features.

Each feature should define:
plug-ins and fragments: there are the plugins that are going to be built as part of the feature. When features are going to be broken into different repositories, these plug-ins and fragments will follow the feature in the new repository. Each plug-in and fragment must be in one and only one feature.
Included features: this is used to break features and regroup them. The Core cs-studio feature, for example, could group pvmanager/menus/startup features.
Dependencies: this is everything that should be installed together. First add the features (for example, CA support depends on pvmanager support) then use compute to get the dependent plug-ins.

Not clear what exactly to put for licenses.

Current strawman layout for some features.
pvmanager (core libraries, ui configuration, utilities)
ca (datasource + caj) -> pvmanager
pva (datasource + pvdata/pvaccess) -> pvmanager
cs-studio utilties (probe, pvtable) -> pvmanager
ca utilities (pv tree) -> ca, pvmanager
BOY -> pvmanager

[gcarcassi]

I just pushed implementation for:
Data connection layer (pvmanager)
Channel Access support (EPICS v3)
PV Access support (EPICS v4)
Any feedback on those before I do anything else would be appreciated

[berryma4]

The top level project issue is:
#100

[gcarcassi]

More work on this. We now have a CS-STUDIO product. Much of it is rebranded. New splash screen and site neutral message. The list of committers in the splash screen is the top committers taken from Ohloh for the past 12 months. We can change it from time to time.

The following features were introduced:

• libs - this is a stopgap solution to build and include all 3rd party libraries
• eclipse - this is a stopgap solution to include all Eclipse needed libraries. It most likely need to be reviewed
• core - this is the main core feature. I believe it should include all the dependencies with the common functionality, but not ones that would not play well with other products. For example, if you are running Eclipse IDE, and you install a CS-Studio feature, that should in principle work. But if core includes definitions for all the standard menus (File, ...) that would become a problem. So, that part is going to be excluded from Core. I don't know how much effort we should put in this distinction, but at least having a placeholder I think it's useful.
• product - the product feature will include the actual code that take care of setting up the whole environment. Including menus, workspace, etc...

I am concentrating on the IDE build at this point. Later we'll make sure that it works with the commandline build.

[gcarcassi]

The CS-STUDIO product is now fully made of "neutral" features and plugins. It includes BOY, probe and not much else. The plugins should be reviewed and moved to core, in a way that can be used by at least BNL and FRIB. I'll leave Kunal and Eric to work on this.

[dxmaxwell]

As a follow-up to our discussion this morning about how plugins should be added in a feature (ie directly or as a dependency), the Orbit wiki page suggests that third party plugins provided by Orbit should be directly included in the other features. (http://wiki.eclipse.org/Easy_Bake_Builds_with_Orbit_Bundles)

In my testing when I put a third party plugin as a dependency, instead of directly including it in a feature, the build breaks. So, now I'm more confused about how this should be done.

[gcarcassi]

Wow. Can't figure out a decent way to do this then.

Having a common feature for all 3rd party libraries is not reasonable, because every time some feature wants one you need to add it, and it becomes a kitchen sink. I guess then each feature would need it declared in their included plug-ins, but then: what are the dependencies for?

Maybe we open up a few Eclipse/Mylyn/... features, and see how they do it? The feature.xml file should be there... right?

[kasemir]

Having a common feature for all 3rd party libraries is not reasonable, because every time some feature wants one you need to add it, and it becomes a kitchen sink. I guess then each feature would need it declared in their included plug-ins, but then: what are the dependencies for?

Having each feature that needs a 3rd party plugin list that plugin has an advantage when it comes to versioning:
Feature A might need apache mq jms version a, while feature B might need amq version b.
That's fine, both the amq version a and b plugins will be included in the product.

If you instead move 3rd party plugins to a designated 3rd party feature, you'd get the one in there.

Same actually applies to all plugins: versioning is fine if you list what you need in each feature. If all features are compatible with one and only one version of a plugin: perfect, you get that one in the product. But multiple versions of the same plugin are also possible that way.

-Kay

[gcarcassi]

To recap: CS-STUDIO is built only with common features, except for the product feature and the intro feature. I'll move this to release 3.2.11, since we haven't figured those out yet. Eric: if you prefer to close this issue and open another one for those, go ahead.

[gcarcassi]

Move to 3.2.11