Imports from External Components

[miguelrluaces]

Motivation

The current import mechanism in UVL enables the composition of feature models through an import statement. However, imported models are expected to reside in subfolders relative to the importing model, limiting flexibility in reuse scenarios. Furthermore, to support advanced use cases such as reuse of external feature models, it would be useful to extend the import mechanism with an additional from clause. This would allow specifying the location of the imported model from different sources, such as the local filesystem, URLs, Git repositories, or package repositories (e.g. npm.js).

Example syntax

imports 
    /*It could be a relative local route using the file: protocol*/
    module1 from file:../ mycontainer 

    /*It could be a git repository using the git: protocol */
    modfolder.module2 from git:https:gitlab.com/lbdudc/module.git

    /*It could be a specific branch from a git repository */
    modfolder.module3 from git:https:github.com/lbdudc/module.git#my-new-branch 

    /*It could be a specific version of a npm.js package using the npm: protocol */
    module4 from npm:my-module:1.3.2 as mod4

    /*It could also be the latest version of given major revision of a npm.js package */
    module5 from npm:my -module-in-npm :^1.4.0 

Implementation

• The grammar must be changed
• Parsers must be recreated

[SundermannC]

We had a short discussion recently and everyone agreed the proposal could be a very valuable extension for UVL.
Here, one main challenge may be widespread support for more complex imports (e.g., from git or npm).

Maybe it would be nice to implement a mechanism with standard import types (e.g, absolute paths) and some way to extend it with custom functionalities to resolve complex imports (e.g., npm). If these imports always follow certain structural patterns (as in your proposal), parsing should be flexible enough to cope with unknown import types.

[miguelrluaces]

David Benavides and I discussed recently about this subject. He thinks that including in the UVL file details regarding the location of modules is not elegant. He was thinking of having that information in a separate file (just like java does with the pom.xml or javascript and npm with the package.json). I think that doing that is a bit ugly becuase suddenly you need two files for the specification of a product line (feature model and module locations). With did that in our first version it looked ugly.

In the end, we kind of agreed that a UVL language level oriented to "domain engineering/solution space (DE/SS)" could be a good idea. Hence, if you only care about the feature model, you can work with the current UVL specification. If you care about linking the feature model to product artifacts, you use the DE/SS UVL language level.

I haven't look into the details of defining a language leve. I do not know whether it is possible to have optional notation in the import clause only if a language level is active. I guess it is possible because cardinalities in features are basically the same thing. I will try to find time to have a look at this.

[SundermannC]

I also think we need a mechanism anyhow to specify the imports (and potentially aliases) in the UVL file. The imports are also useful information directly in the model. So, I would generally agree with you that storing this information in an extra file is rather tedious.

I think having a dedicated UVL language level make sense. Currently, language levels target different mechanisms that influence the configuration space. However, the mechanism should also work without too much hassle for this use case. Adopting the current notion of every level requiring a conversion to a simpler level, we would also be able to automatically remove those constructs if they are not supported by a tool.

Maybe it would be even nice to group language levels that rather provide additional information (e.g., import paths or pointers to solution-space artifacts) in a dedicated utility major level.

[miguelrluaces]

Adopting the current notion of every level requiring a conversion to a simpler level, we would also be able to automatically remove those constructs if they are not supported by a tool.

Can you give more details about this? Is in the paper?

Maybe it would be even nice to group language levels that rather provide additional information (e.g., import paths or pointers to solution-space artifacts) in a dedicated utility major level.

Can you think of any other "additional information" that would be nive to have in that level?

[SundermannC]

Can you give more details about this? Is in the paper?

Yes, the idea is presented in Section 5.3 in the paper and the concrete conversions are exemplified in Table 2. This conversion is however currently only enforced in the Java tooling.

Can you think of any other "additional information" that would be nice to have in that level?
I think there quite some suggestions in that direction. I am not sure if each one is worth to include but it probably makes sense to compile a list. Here are some suggestions that I remember off the top of my head.

• Global attributes (properties of the entire feature model)
• Constraint attributes
• Pre-defined configurations
• Configuration order (i.e., which features to configure first during a configuration process)