Property sets and packages cannot be contributed in standalone mode #1388
Based on current work on #1387 I copied the revised
I'm using the test model
When I load it the verifier is unable to resolve the name of the property
This is the problem that we need to fix: Having the contributed property sets installed and loaded.
I'm not entirely sure how the contributed aadl is loaded and "linked" in OSATE. But I think what I want to do here is provide a mechanism for getting the list of contributed aadl from the
As with #1387, supporting registration of contributions from the manifest files and through direct registration via method calls.
This is not working in any kind of straightforward way. I have modified the
References are not being resolved between the property sets or the example that uses them:
Futhermore, all kinds of weird messages are output regarding the property sets:
It is highly possible that the URI map we are creating is wrong. But it's unclear what it should be.
If you load the property sets from the local directory as a regular .aadl file, things do work correctly.
Working on an example that reads the contributed resources from the plugin.xml extensions.
To run this kind of example you need to put the jars that contain the contributed resources on the classpath (this should be obvious), but you also need the jar for
Summary of the important points here:
For the cross-references to work between the models, we must pretend that the file are organized as a project. For example, here we create a project "foo" that is in the directory
The upshot of this is that when we load the files we refer to them as being in
(In the future, there should probably be some library methods to make this process more transparent to the user of the program, but right now we don't have enough experience with how this is going to work in practice.)
As with annexes, there are two ways to proceed with finding the contributed resources.
To get the list of contributed resources from the plug-ins on the classpath, use
This is the same
When executing the program you need to make sure the plug-in jar files containing the contributed resources you need are on the classpath. You also need to have the the jar for
Searching all the plug-ins on the classpath can be slow, so it may be better to simply name the needed contributed resources directly. To do this you just create your own
Note that you need to know the location of the contributed resource within the jar file.
Again, at runtime you need to make sure that the plugin jar file containing the contributed resources is on the classpath.
When directly loading the contributed resource, you must also set up the URI mappings to map the plug-in to the jar file. This is necessary so that names in instance models can be resolved correctly. (The URI map is set up by the
(Again, should any one ever write a real program that uses this stuff we should probably create some library methods to help out with this process.)