osate / osate2

Open Source AADL2 Tool Environment
http://osate.org
Eclipse Public License 2.0
36 stars 8 forks source link

Contributed models do not show up in AADL navigator #948

Closed Etienne13 closed 6 years ago

Etienne13 commented 6 years ago

We use the aadlcontribution extension point of osate to contribute AADL models of our plugins. The models are loaded, and we can reference them but the do not appear in the AADL navigator.

They are contained in a directory "aadl_resources/package/" aadl_resources appears in the Navigator but it looks empty.

An example of contributed file in our plugin.xml file is:

  <aadlcontribution
        file="aadl_resources/package/POSIX_runtime.aadl"
        id="fr.tpt.aadl.packages.posix_runtime.aadlcontribution"
        name="POSIX-Runtime">
  </aadlcontribution>

It seems to be a bug in the display of the AADL Navigator.

Best regards, Etienne.

lwrage commented 6 years ago

We cannot reproduce this. Do you have a *.genmodel in your plugin? Contributed models don't work in plugins that also contain a genmodel file. See #527 for details.

Etienne13 commented 6 years ago

Hello,

I don’t think my issue is related to the one you referenced.

To reproduce the issue, here is a simple procedure:

1) create a new plugin project in the Eclipse you use for development. 2) add a folder f1 3) add a folder f2 inside f1 4) add an AADL model m1.aadl in f1 5) add an AADL model m2.aadl in f2 6) add a plugin.xml file 7) add plugin.xml and f1 in the binary build of the project 8) launch osate with this new plugin

Here is a project with artefacts created in steps 1 to 7 above: test-issue.zip

In my current configuration, f1/m1.aadl does appears but not f1/f2/m2.aadl

Best regards, Etienne.

lwrage commented 6 years ago

It's a bug in the logic that processes contributed directories. Currently it does not work for more than one level.

AaronGreenhouse commented 6 years ago

I see this. Working on it now.

AaronGreenhouse commented 6 years ago

Problem is in AadlNavigatorContentProvider.getChildren() in the lines where it tries to filter the complete list of contributed files into the ones that are children of the given element:

            Stream<URI> inDirectory = PluginSupportUtil.getContributedAadl().stream().filter(uri -> {
                OptionalInt firstSignificantIndex = PluginSupportUtil.getFirstSignificantIndex(uri);
                if (firstSignificantIndex.isPresent() && firstSignificantIndex.getAsInt() < uri.segmentCount() - 1) {
                    List<String> uriDirectory = uri.segmentsList().subList(firstSignificantIndex.getAsInt(), uri.segmentCount() - 1);
                    return directoryPath.equals(uriDirectory);
                } else {
                    return false;
                }
            });
AaronGreenhouse commented 6 years ago

The filter fails if the current directoryPath is a prefix of the elements uriDirectory.

AaronGreenhouse commented 6 years ago

The right thing to have done here would be to build a tree of the contributed items during startup instead of trying to recreate the tree on the fly based on the paths through the tree. But that's not going to change now. The trick here is going to be to avoid creating multiple copies of the same child directory, such as when we are opening the folder f1, and we have contributed files f1\f2\x.aadl and f1\f2\y.aadl.

In this case, the above broken filter needs to let both f1\f2\x.aadl and f1\f2\y.aadl through (it currently lets neither of them through), but then we need to determine that the child we need to return is the directory f2, and we should return exactly one copy of f2.

AaronGreenhouse commented 6 years ago

Fixed this. Replaced the equality test with a prefix test.

The Java streams and aggregators are taking care of the duplicate problem.