Petals Studio

Petals Studio 1.3.x introduced a new model management.
Formerly, it was based on XML schemas that were parsed and transformed in a custom structure. It is now based on EMF extensions.

However, this mechanism added another kind of complexity, although it is much more clean than formerly. In addition, this modeling resulted in some user issues.

Eventually, we must think to another way to configure Petals components. Service units with all the parameters in the jbi.xml is not the best solution. Having everything in XML files is not a good idea, in particular when new parameters are added. The best approach would be:

• Have a component project.
• Have a tooling project for this component.
• Have a project for the configuration of this component.

Such a project would cover the following topics:

• Definition of the configuration for all the versions.
• Parsing and validation of a configuration.
• Exposing API so that any project willing to use a component configuration will have no effort to do. Tooling and runtime projects are among them.

In the scope of this intent, Petals tools should be upgraded as follows:

• Creation wizards would allow to select the target component, its version and to set all the mandatory parameters.
  • Wizards must remain as simple as possible.
  • Optional elements would be configured in the editor, after the creation.
• A project with configuration files would be generated.
• Editors would just allow to edit parameters.
  • Configuration files should be auto-descriptive and not require a tool or a web page to be understood or edited.

The idea here would be to put parameters of service units in properties files.
Properties files would all have a version attribute, that describes the version of the model configuration.
Parameters would be keys and parameter values would be values. What a parameter means would be described in comments. The type and the possible constraints would be specified as well, in a documented format. A service unit would thus come with a jbi.xml, a su.properties file (component parameters) and a cdk.properties file (CDK parameters).

Although Petals developers have always claimed they wanted to be able to support composed and complex parameter types, the fact is they are all simple. And even with properties, some complex types can be covered. Libraries like http://code.google.com/p/bracket-properties/ could be used.

The idea of this bug entry is summered up below:

• Keep the EMF model for the JBI specification.
• Remove model extensions.
• Define for every CDK and component versions a properties file that defines the parameters and so on.
• Create a parser for these properties files.
• Update the UI helpers to create widgets from these models.
• Map this properties model to the current (XML) one.

The tooling is going a step further, but this will result in an easier maintenance in the studio. It will also prepare a (possible but hopeful) future change in Petals.