Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [capra-dev] Is a file related to a artifact?

Hello Jens,

this sounds like a good idea. Please go ahead and make the changes. Please reference the corresponding bug in your commit message and document your approach there as well: https://bugs.eclipse.org/bugs/show_bug.cgi?id=518833

Best,
Jan-Philipp

> On 28 Jun 2017, at 15:49, Jens Lideström <jens.lidestrom@xxxxxxxxxxx> wrote:
> 
> Hello again,
> 
> I'd like to ask one more question about this.
> 
> To finish my test-result-integration-project I think it is best to implement a light-weight first step version of the solution we discussed yesterday.
> 
> That solution consists of the following:
> 
> * Add a getArtifactIdentifier method to ArtifactMetaModelAdapter
> * Add artifactIdentifier parameter to createArtifact.
> * Change the handlers for Java and C to set the URI and identifier properties correctly.
> * Make the other handlers compile, but set both these properties to the same value as they use for URI today. They will have to be updated at some later time.
> 
> The updates to the Java and C handlers can be made to still support unwrapping artifacts with the internal CDT/JDT identifier string, to be compatible with existing artifact files that have the old format.
> 
> If your agree to this I can make a change with this content.
> 
> 
> Jens Lideström
> Software developer
> rt-labs
> 
> 2017-06-22 17:14 GMT+02:00 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=>CDT/JDT_ELEMENT_ID"
> 
> 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
> 
> 
> _______________________________________________
> 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



Back to the top