Context menu: text editors

[jpasski]

From @jonpasski on June 28, 2016 2:2

In a text editor context menu:

• With a given text selection
• Create a Semiotics → Add as snippet... menu
• Bring up menu that's 3 parts:
  1. ECP projects without assessments
  2. ECP projects with Assessment, without any Application
  3. ECP projects with Assessment, with an Application
• Create the following:
  1. For project-only: an Assessment
  2. For project or Assessment: with Applications and an Application named after current Eclipse
  3. For all:
     • A Resource (creating Resources if needed) named after the file
     • A Snippet linked to the created Resource w/ selection info

Copied from original issue: OpenSemanticsIO/semiotics-main#36

[jpasski]

Successful Travis CI build closes #21

Learned

Popups

https://jaxenter.com/eclipse-migration-tutorial-124527.html:

If the URL location defines a generic view in a popup (popup:org.eclipse.ui.popup.any), it must be translated in a menuContribution in the application model using ‘popup’ as ‘Parent-ID’ and ‘after=additions’ as position.

I was using popup: not popup before. Lol...

3.x Part Service

Figured out how to access the 3.x stuff, yay!

Eclipse FAQ:

Eclipse 3.x Compatibility Layer ... Services

• org.eclipse.ui.IPartService

JUnit Test

Learned how to make run configurations headless, which was helpful when creating resources.

Other Tasks

Target Definition

• Included new Spy version. There isn't a release site afaik.

Features

• Added new features:
  • Extension provider dependencies
  • Test cases and dependencies

Dead Ends

Dynamic Dynamic Menus

I tried to get dynamic menus within a dynamic menu working. No love. Dunno if this is supported or not.

Generics in OSGi DS?

API:

interface Foo<A,B> {
  void bar(A source);
}

Impl:

class FooImpl<A extends SomeA, B extends SomeB> implements Foo<A,B> {
  void bar(A source) {}
}

Results in the following SCR XML:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="FooImpl">
   <service>
      <provide interface="Foo"/>
   </service>
   <implementation class="FooImpl"/>
</scr:component>

This SO post seems to confirm what I thought:

In short, there is no such thing as Foo at runtime due to the type Type Erasure. The type information is lost. Instead, you can expose Bar as raw Foo with service property typeArg=java.lang.String and use filter when injecting it to the consumer.

So the idea is to specify a custom service property (e.g. typeArg or whatever) in the service descriptor for the component. Then a consumer could filter on that. Yay?

I could have a general service API with a producer that declares a property and a consumer that filters on such a property. Then each consumer, which will be an extension (Burp, Eclipse, ZAP, etc.), could be more specific on the provider interfaces. That does create a strong coupling between the API, producer, and consumer.