Re: [capra-dev] Is a file related to a artifact?

[Jens Lideström <jens.lidestrom@xxxxxxxxxxx>]

Hello again!

I seem to have left in the middle of a conversation last time as I see that these is questions in the mail above which I didn't answer. I'm sorry about that. Urgent matters arose, my Capra week past and I lost track of this.

But I now have time to finish the test result reader for the ReqTool editor.

Jan-Phillipe asked this:
> Would the solution via ArtifactMetaModelAdapter#getArtifactUri address your issue?

Yes, that is what I plan to use and that will work. I think I have everything I need.

I plan to change the relevant handers (mainly CDT and JDT) to set artifact URI strings that contain the information I need.

I plan to use URI:s with the following structure:

"platform://plugin/<PLUGIN_NAME>/<PATH_TO_FILE>?element=<FUNCTION_NAME>&data="">

The platform URI scheme [1] is handy for addressing all sorts of things in a flexible way.

By using this structure it is possible to easily locate the relevant file by looking at the URI path, and interested parties can get extra information from the query parameters.

Question: Is there any problem with changing the CDT and JDT handler in this way? Existing, saved, artifacts will probably no longer work.

[1]: http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fplatform-scheme-uri.html

Jens Lideström

Software developer
rt-labs

PS: The code for encoding such a URI in the CDT handler looks like this:

    public EObject createWrapper(ICElement element, EObject artifactModel) {
        try {
            String uri = new URIBuilder("platform://plugin" + element.getPath())
                .addParameter("element", element.getElementName())
                .addParameter("data", element.getHandleIdentifier())
                .toString();

            ArtifactMetaModelAdapter adapter = ExtensionPointHelper.getArtifactWrapperMetaModelAdapter().get();
            EObject wrapper = adapter.createArtifact(artifactModel, this.getClass().getName(),
                    uri, element.getElementName());

            return wrapper;
        } catch (URISyntaxException exc) {
            throw new RuntimeException("URI syntax error when parsing artifact URI", exc);
        }
    }

2017-05-11 16:09 GMT+02:00 <ec@xxxxxxxxxxxxxxxx>:

Hey Jens,

> This seems to be an important a Capra design question, so I think it is good to discuss it with the rest of the group.

It is!

> In my code I get from Mylyn an ITestResult object from which I can get the file names of the test case files. I need a way to determine whether a given artifact (connected as the child of a Requirement) is for a given test file.

I am not sure if I quite understand this. The link that exists is between a requirement and a test case, right? The test case is defined in a test file then, correct? Do you use the CDT handler to link between the requirement and a function?

> There are a few solutions to this problem:
> * Have ArtifactMetaModelAdapter#getArtifactUri return a real URI that can be used to locate a file. (Right now that method doesn't return URI:s, it returns some artifact handler specific ID string.)

Yes, that is an issue that is independent of the concrete problem that you describe. The contract of that method is broken. For the OfficeHandler, e.g., we needed to introduce an addressing scheme, that would include the worksheet and row in an Excel file. That’s why it does no longer return a URI. Maybe we should change the behaviour here to return the URI of the _enclosing_ resource and have another method that gives the unique identifier (as defined by the handler).

> * Add some new method to test this, possible on TraceMetaModelAdapter. It's not clear to me exactly how that method should look, but it should be possible to work out something.

It’s not clear to me, either. Would the solution via ArtifactMetaModelAdapter#getArtifactUri address your issue?

Best,
Jan-Philipp
_______________________________________________
capra-dev mailing list
capra-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/capra-dev