Provide external validator for Franca IDL which checks all non-DBus-features

[GoogleCodeExporter]

When transforming a Franca IDL model to a D-Bus introspection model, some 
Franca features can not be implemented by plain D-Bus. These features include:

- primitive data types Int8 and Float
- maps with complex key types
- attributes with noSubscription flag set
- selective broadcasts
- fireAndForget methods
- inheritance for structs
- inheritance for unions
- polymorphic structs
- inheritance for interfaces
- "manages" interfaces
- maybe more?

An external validator should be available which can be used to detect these 
problems. The validator could be used by users who want to use Franca for 
modeling and use plain D-Bus for the actual implementation.

Note: CommonAPI supports most of the above features; however, they will be 
"emulated" by additional D-Bus interaction. Therefore, the resulting D-Bus 
interfaces will be different from plain D-Bus introspection when using 
CommonAPI.

Original issue reported on code.google.com by klaus.birken@gmail.com on 29 Nov 2013 at 9:28

[GoogleCodeExporter]

Additional requirements:
- It has to be configurable if the validator described here is active or not.
- It should be configurable as well if the problems detected by the validator 
should be classified as "Warning" or as "Error".
- For each problem detected, the marker message should contain a description if 
this feature will be ignored completely during the D-Bus transformation or if 
it will be emulated somehow. These descriptions will be specified later.

Example validator implementations can be found in 
examples/org.franca.examples.validators.

Original comment by klaus.birken@gmail.com on 9 Dec 2013 at 1:02

[GoogleCodeExporter]

Basically the described restrictions do exist in case IPC CommonAPI is used 
together with legacy D-Bus communication.
Those restrictions might depend on the interface usage, e.g. if used as stub or 
client.
And there might be a dependency to the features of other D-Bus bindings 
involved, too.

The interesting question is how to use those validators for different 
middleware concurrently. It is not helpful to have many validators (e.g. 
SomeIP, D-Bus, CommonAPI-DBus, INC) producing warnings/errors upon an abstract 
Franca interface, that might never be used with all of those middlewares.

There must be some relation to available deployment models of an abstract 
Franca interface, and all deployment models should have a standardized way to 
identify specific middleware to trigger validators activity.
D-Bus XML could be seen just as another deployment besides others in this 
example.

Original comment by bathe...@gmail.com on 18 Dec 2013 at 11:11

[GoogleCodeExporter]

Delayed to v0.9.1 in order to avoid blocking the upcoming v0.9.0 release.

Original comment by klaus.birken@gmail.com on 19 Feb 2014 at 11:33

• Added labels: Milestone-v0.9.1

[GoogleCodeExporter]

Already implemented for v0.9.0, see commit 42adfb3 on develop.

There are also unit tests testing the additional validation checks. The D-Bus 
validator will be activated automatically when installing the org.franca.dbus 
feature. If you don't wont the validator, call:
   DBusCompatibilityValidator.setActive(false); // default: true

If you want to enforce the checks and get errors instead of warnings, call:
   DBusCompatibilityValidator.setWarningsAsErrors(true); // default: false

In order to use the external validator in a standalone environment (e.g., unit 
test), use something like
    @BeforeClass
    public static void init() {
        ExternalValidatorRegistry.addValidator(new DBusCompatibilityValidator());
    }

Original comment by klaus.birken@gmail.com on 28 Feb 2014 at 10:27

• Changed state: ToBeIntegrated
• Added labels: Milestone-v0.9.0
• Removed labels: Milestone-v0.9.1

[GoogleCodeExporter]

Integrated to master.

Original comment by klaus.birken@gmail.com on 4 Mar 2014 at 12:18

• Changed state: Fixed