Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[tigerstripe-dev] Re: Annotating module artifacts; and annotations in modules

Title: Re: Annotating module artifacts; and annotations in modules
Hi Andrey,

Thanks for the detailed explanation. See my comments below.


On 8/26/08 4:53 AM, "Andrey Platov" <andrey@xxxxxxxxx> wrote:

Hi Gentlemen,

We discussed TAF + Tigerstripe modules with Yuri, let me please share some thoughts (since I'm spelling English a little bit faster :)).

First, let's separate two scenarios, which are very different in our understanding:
[ED] this is correct. We need to treat both scenarios separately.

1. Annotate artifacts in modules.

This means we shall have a possibility to annotate files/classes/etc contained in the modules as they were in the workspace (annotations will be stored in local .ann files or anywhere using normal routing approach). This scenario may be implemented without any changes to the framework using existing resource URIs and supported schemes (resource, class, tigerstripe). The only requirement is that artifacts in the module will be accessible to Eclipse using corresponding APIs (Resource, Java model, Tigerstripe) as they were in the workspace. This is definitely doable in many ways, for example to make artifacts in modules available as Eclipse 'IResource's we may employ Eclipse File System (EFS) http://wiki.eclipse.org/index.php/EFS . To make Java classes visible to JDT we may add module on Java classpath, combine both approaches for complex module structure, etc.

So the idea for scenario (1) is to make arifacts in modules transparently visible to Eclipse/Tigerstripe as this artifacts located in workspace normally. To use existing TAF features (and I hope more other benefits for Tigerstripe in general).

Please update us if you already have EFS implemeted? (Yuri reported that Tigerstripe can navigate inside modules but he did not dig deeper to understand at which level this is done).

This is proposed clear solution for scenario 1, please update us if we did not missed something. Taking "annotate resource in module as an example we'll have":

Project
- tsmodule.zip
-- resource.txt (inside zip)

If module content available through EFS as regular eclipse resource, URI for resource.txt will be resource:/Project/tsmodule.zip/resource (or whatever Tigerstripe EFS will provide), so it could be transparently annotated by the framework.
[ED] So, there is the general case (resources within a .zip file) and the Tigerstripe specific case (Model artifacts in a module). A Tigerstripe module is in fact a .zip file. However, in our explorer we’re using a slightly different content provider to only show parts of the content of the module. So in practice, when browsing the content of a Tigerstripe module, users will only ever see the model artifacts and a copy of the model descriptor (tigerstripe.xml). SO, there won’t be anything else to annotate.
I’ve just committed initial changes so that when the user selects a model artifact from a module, a URI of the following form is provided to the TAF:
    tigerstripe_module:/<moduleID>/<artifact-fully-qualified-name>

Note that I tried to use you suggestion below (tigerstripe_module:tigerstripe:/....) but this was rejected as an incorrect URI (too many ‘:’ in the scheme of the URI).

2. R/O Annotations inside the module

Following Eric's comments at https://bugs.eclipse.org/bugs/show_bug.cgi?id=244843 it definitely looks like we need to transform annotation files to change annotation scheme. Proposed solution, which assumes that scenario #1 is implemented (transparent access to module content):

a) To stay conceptualy complete (and keep all the annotations in moudle including resource:, java:, etc) I'd like to extend Eric's proposal with preserving original scheme, so during module export process URIs of form:

scheme:/Project/etc... will be replaced with tigerstripe_module:ModuleID:scheme:/etc or tigerstripe_module:scheme:/ModuleID/etc, which is more hierarchical.
[ED] As noted above, it seems we can only have one “:” in the scheme of the URI. So, I agree we should put something more hierarchical than what I committed, but we can’t use that.

In the example above URI to resource.txt will be tigerstripe_module:tsmodule_ID:resource:/resource.txt (or tigerstripe_module:resource:/tsmodule_ID/resource.txt)
[ED] In the case of TS module, there won’t be “resources” inside the module (at least not visible thru the UI). Only the Model Artifacts, for which I committed some code that should provide a tigerstripe_module:/<moduleID>/<artifact-fully-qualified-name> URI now.
The .ann files are also now packaged into the module (as regular zip entries) but are not presented (as it now) in the UI (the content provider filters them out). So, considering this is a .zip file... The EPF should work, and the TAF should be able to find out about the .ann files? (they’re at the root of the .zip file).

b) If #1 is done, and after module added to a project, TAF will normally register .ann files with the annotation database (they looks like normal Eclipse resources due to #1). Also to resolve Eric's "multiple-identical' entries case https://bugs.eclipse.org/bugs/show_bug.cgi?id=244843#c3 we need to extend this process with refcounting based on module id, which do not looks to be a problem
[ED] Ok. Sounds good.

c) The last thing: understanding tigerstripe_module:XXX annotations

I believe we can easily do this using EMF's URIConverter feature. With TAF ResourceSet we will register URIConverter, which will simple map tigerstripe_module-profixed URIs back to original. To do this propoerly we need to know at least one project where module is located, and fortunately we know it, and maintain a list of such projects at phase (b) - to ensure that added annotations database only once per concrete module.
[ED] This sounds good too. The URIConverter should do the trick. Who is responsible for doing this. It seems this logic should live in the Tigerstripe side not in the TAF side? Also, we need to agree on the final hierarchical form of the URIs.

Proposed above looks like a solution to support annotations for modules in true fashion with minimal TAF changes. Probably we missed something, which can break this picture. So we're anxiously waiting for your thoughts, and would be happy to talk on this at the meeting.
[ED] I’m sure we’ve missed something :-), but I can’t see what just now... Let’s give this a try.

Thank you, and
Kind Regards,
Andrey



 


Back to the top