Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add initial mylyn support to OSATE #1675

Closed
AaronGreenhouse opened this Issue Jan 17, 2019 · 52 comments

Comments

Projects
None yet
2 participants
@AaronGreenhouse
Copy link
Contributor

AaronGreenhouse commented Jan 17, 2019

Integrate mylyn support into OSATE.
child of #1371

@AaronGreenhouse AaronGreenhouse self-assigned this Jan 17, 2019

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Jan 17, 2019

Step 1: need to add the mylyn features to the OSATE build.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Jan 22, 2019

Added mylyn to the OSATE2 setup.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Jan 22, 2019

Still hunting for good mylyn developer documents.

So far I know that I need to create a Bridge for OSATE. Haven't figured out much beyond that.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Jan 24, 2019

Mylyn plug-ins don't seem to include the source code.

I have resorted to importing the source code from the Eclipse GIT repository. Instructions for this are found here: https://wiki.eclipse.org/Mylyn/Contributor_Reference#Setting_Up It's a bit of a chore, but I did finally get it to work.

  • You should not be connected to the SEI VPN (Duo)
  • For the versions of Mylyn and Gerrit that are current today, installing using Gerrit doesn't work, and you must install using GIT.
  • I had best luck using the ssh link to the repository for mylyn all: ssh://user_id@git.eclipse.org:29418/mylyn/org.eclipse.mylyn.all.git
    • You need to use your Eclipse.org-generated username to authenticate.
@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Jan 24, 2019

The main bridge component for the JDT is JavaStructureBridge. I'm going to try to study this and it's ancestor classes to figure out how mylyn works.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Jan 24, 2019

JavaUiBridge is the UI bridge component for Java.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Jan 24, 2019

Extension points are org.eclipse.mylyn.context.core.bridges and org.eclipse.mylyn.context.ui.bridges.

Cannot find real documentation on how to use these.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Jan 25, 2019

Therre is not a lot of Javadoc on the AbstractStructureBridge, but it seems pretty easy. The main job is to turn model elements from the workspace into unique keys or handles as they call them. Also indicates which ones can be opened by an editor (are documents). Been looking at the JavaStructureBridge and the ResourceStructureBridde.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Jan 30, 2019

Not sure what the minimum required set of features is for mylyn. We initially just added org.eclipse.mylyn.context_feature to the build, but I had to add org.eclipse.mylyn.context_feature to the build target today.

Once I did this my AadlStructureBridge started to activate. Doensn't seem to do anything yet, but at least it is finally activating.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Jan 31, 2019

I should note that I have created a new plugin project org.osate.mylyn.aadl.ui in core.

I created AadlStructureBridge over the last few days. It's pretty simple, but I had to make some changes based on observed behavior. Been using the debugger a lot to try and figure out when and why the different methods are called. Got things so they dont' crash, and I have the bridge a child of the resource bridge (as is the Java bridge). But, I'm still not seeing any AADL elements added to the context.

I was hoping that just the structure bridge would be enough to see this, but I guess not. I am now creating AadlUiBridge. I have a minimal skeleton implementation. I plan on using the debugger again to try and understand what is going on.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 5, 2019

Adding a UI Bridge doesn't build the context either.

It seems that was is required is an extension of AbstractUserInteractionMonitor that is registered wtih the MonitorUI:

		MonitorUi.getSelectionMonitors().add(aadlEditingMonitor);

The interaction monitor converts selected elements into handles. This does seem to cause items to be added to the task context.

But so far the AADL elements are added as :"invisiible" elements. They aren't but in the tree in the task context display. Not sure what is going on . I have verified that parents can be resolved all the way up to the project.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 5, 2019

Going to search the mylyn source code for "invisible" to see if I can find out how a handle is classified as such.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 7, 2019

I figured out how to get the AADL context information to show in the context tree in the task editior. The editor uses an instance of the content viewer from the navigator view framework. So we need to install the aadl-related content extensions into it:

<extension
     point="org.eclipse.ui.navigator.viewer">
	<viewerContentBinding 
        viewerId="org.eclipse.mylyn.context.ui.navigator.context">
		<includes>
			<contentExtension pattern="org.osate.ui.navigator.contributedAadl" />
		    <contentExtension pattern="org.osate.ui.navigator.aadlProjectDependencies" />
			<contentExtension pattern="org.osate.ui.navigator.aadlFileContent" />
		</includes>
	</viewerContentBinding>
	<viewerContentBinding 
		viewerId="org.eclipse.mylyn.context.ui.navigator.context.quick">
		<includes>
			<contentExtension pattern="org.osate.ui.navigator.contributedAadl" />
		    <contentExtension pattern="org.osate.ui.navigator.aadlProjectDependencies" />
			<contentExtension pattern="org.osate.ui.navigator.aadlFileContent" />
		</includes>
	</viewerContentBinding>
@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 7, 2019

Next steps:

  • Finish the interaction monitor to work with text selections
  • Go back to the UI bridge to get the editor linkages
@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 12, 2019

Added org.eclipse.mylyn_feature and org.eclipse.mylyn.context_feature to the OSATE2 modular target in the osate2_2018-12.setup file.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 14, 2019

See org.osate.ui.utils.SelectionHelper for use of EObjectAtOffsetHelper to get object from text location.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 14, 2019

Added handling of TextSelection to the AadlEditingMonitor. Appears to have had the desired effect, as elements are added to the context. Unfortunately, the navitator extensions previosuly added for AADL do not handle features, subcompnents, etc.

Unclear yet if I should create an additional navitor extension or make the existing ones more general.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 18, 2019

Need to figure out how to get the mylyn icon in the AADL Navigator toolbar that appears in the Java Navigator toolbar.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 18, 2019

Here is a screen shot of AADL elements in a Mylyn task context.

aadl context

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 18, 2019

The toolbar action is installed by this, I think:

   <extension point="org.eclipse.ui.viewActions"> 
		<viewContribution 
		id="org.eclipse.mylyn.java.explorer.contribution" 
   		targetID="org.eclipse.jdt.ui.PackageExplorer">
    	<action
           class="org.eclipse.mylyn.internal.java.ui.actions.FocusPackageExplorerAction"
           disabledIcon="icons/elcl16/focus-disabled.gif"
           enablesFor="*"
           icon="icons/elcl16/focus.gif"
           id="org.eclipse.mylyn.java.actions.focus.packageExplorer"
           label="%FocusPackageExplorerAction.label"
           menubarPath="mylyn"
           style="toggle"
           toolbarPath="mylyn"
           tooltip="%FocusPackageExplorerAction.tooltip">
        <enablement>
           <systemProperty
                 name="org.eclipse.mylyn.context.core.context.active"
                 value="true">
           </systemProperty>
        </enablement>
  		</action> 
      </viewContribution>
 	  <viewContribution
       id="org.eclipse.mylyn.ui.views.active.search.contribution"
       targetID="org.eclipse.mylyn.ui.views.active.search">
 		</viewContribution> 	
	</extension>

@lwrage lwrage added this to the 2.4.1 milestone Feb 19, 2019

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 19, 2019

I had to extend the AadlElementContentProvider so that it shows the features/subcomponents/modes of classifiers

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 19, 2019

Okay still need to

  1. Flesh out the UI Bridge (use the debugger to see what it does)
  2. Add a focus button to the toolbar, see the plugin.xml snip-it above
@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 20, 2019

Elements in Plug-in Contributions are not showing up in the context tree, only as "invisibile" elements. I have to check on this. I though I added the proper navigator extensions.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 20, 2019

Problem is that I need to link the contributed files to the Plug-in Contribution node. This needs to be done in AadlStructureBridge.getParentHandle() I think. I can differentiate between handle sthat start with platform:/resource and platform:/plugin.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 20, 2019

Okay, I think the solution is to create a new navigator content provider that lists the contributed content at top level.

This was easy to do

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 25, 2019

Upon discussion with Lutz we have decided that it is okay for "contributed" items to be invisible. They are not editable. It's too much of a hassle to update the structure builder to deal with them.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 26, 2019

Last week I implemented AadlUiBridge.openEditor. That was straightforward to do. I have breakpoints in all the other ui bridge methods, and they never get called. This seems fishy and there must be something else I need to be doing.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 26, 2019

I need to add a listener to the Aadl Xtext model that updates the mylyn model I think.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 27, 2019

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 27, 2019

not sure I need to add a listener to the AADL model. I though this was necessary to deal with edits to the files and to update the context. But just playing with the files in Eclipse, this doesn't seem necessary. Mylyn does the right thing.

Still have no idea what needs to be done to make the AadlUiBridge methods relevant.

Going to stop worrying about that for now and turn to the "task focused" navigator problem.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Feb 28, 2019

Just realized the "Outline" view does have a "Focus on Active Task" action button by default. Clicking on this causes the acceptsEditor method of the UI bridge to be called.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 1, 2019

Implementing acceptsEditor to test for XtextEditors whose editor input is a file ending in .aadl makes pogress. Next step is a call to getContentOutlineViewers.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 1, 2019

Implemented `AadlUiBridge.getContentOutlineViewers()':

	public List<TreeViewer> getContentOutlineViewers(final IEditorPart editorPart) {
		final List<TreeViewer> viewers = new ArrayList<>();
		final Object out = editorPart.getAdapter(IContentOutlinePage.class);
		if (out instanceof Aadl2OutlinePage) {
			final Aadl2OutlinePage aadl2Out = (Aadl2OutlinePage) out;
			viewers.add(aadl2Out.getTreeViewer());
		}
		return viewers;
	}

This is fine. But now the problem is that the Aadl2OutlinePage deals in EObjectNode not AObject.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 4, 2019

Dealing with EObjectNode objects is easy because they have a getEObjectURI method. It was easy to update AadlStructureBridge to accept then and return the URI as the handle.

Doing this made the task-focusing work on the AADL outline view.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 5, 2019

For the AADL Navigator I think I need to subclass FocusCommonNavigatorAction action. Following the example of FocusProjectExplorerAction.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 5, 2019

Added FocusAadlNavigatorAction to the aadl navigator. This class is just a copy of FocusProjectExplorerAction. It works.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 5, 2019

Still have mystery methods in the UI Bridge that I don't know what they should do, and I'm not sure when they are called.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 6, 2019

I've been trying to figure out when close, getElement, and getObjectForTextSelection are called on the ui bridge.

I have the Mylyn source code (or most of it anyway) loaded in a separate workspace. Doing a call hierarchy on getElement shows that it is never called. The JavaUiBridge and ResourceUiBridge have non-trivial implementations of this method. But other bridges, such as Ant and PDE, just return null. I think it is safe to just leave our implementation returning null.

The methods close and getObjectForTextSelection are called from single locations each. It took a while to figure out how to get anything to happen with them. Eventually I figured out that it depends on Mylyn preferences settings in the workspace. As far as I can tell, they won't ever be called if Remove file from context when editor is closed is unchecked (the default situation). I have been able to observe them being called when this setting is selected. I need to study the situation more.

Of note, however, is that while getObjectForTextSelection has a TextSelection parameter, that paramter is only ever passed null.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 6, 2019

Again, as of March 2019, getObjectForTextSelection is only ever called with the selection parameter passed the value null. It is also true that it is safe to return null here, as that is what the Ant and PDE bridges do. I think this method is supposed to take the current text selection and turn it into an object whose structural handle can be retrieved by the caller. When the selection is null it is supposed to return the object represented by the top-level of the editor.

However, returning null causes the caller to get the structural handle of the IResource being edited by the given editor. Again, considering that this method is only ever called with null, there doesn't seem to be any reason to return anything but null. It won't make a big difference if the object used the caller is the resource or the package/property set contained in the resource.

Punchline: Leaving getObjectForTextSelection returning null.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 6, 2019

The close method is supposed be called when an element is removed from the context or otherwise becomes "uninteresting". That is, the editor containing the uninteresting element is closed. Makes sense. But I don't know how to remove an element otherwise than from the editor. This method doesn't seem to be called unless the Remove file from context when editor is closed workspace preference is selected. And even then, so far I have only been able to make it get called by closing an editor, and then it comes back and tells me to close that same editor. That seems pretty silly. My implementation right now does nothing. The editor is closed regardless because of the original closing of the editor.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 7, 2019

The Java elements and Resource elements in the Task Context view have a "remove from context" action in the context menu. This is missing for AADL elements. THere must be an action in the Navigator Viewer setup that I am missing for the AADL navigator.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 7, 2019

It's just a regular popup menu action keyed to the objects:

   <extension point = "org.eclipse.ui.popupMenus">
     <objectContribution
           adaptable="true"
           id="org.eclipse.mylyn.ui.interest"
           objectClass="org.eclipse.core.resources.IResource">
        <action
              class="org.eclipse.mylyn.internal.context.ui.actions.InterestDecrementAction"
              definitionId="org.eclipse.mylyn.context.ui.commands.interest.decrement"
              enablesFor="*"
              icon="icons/elcl16/interest-decrease.gif"
              id="org.eclipse.mylyn.resources.ui.ui.interest.remove.element"
              label="%InterestDecrementAction.label"
              menubarPath="group.reorganize"
              tooltip="%InterestDecrementAction.tooltip">
           <enablement>
              <systemProperty
                    name="org.eclipse.mylyn.context.core.context.active"
                    value="true">
              </systemProperty>
           </enablement>
        </action>
     </objectContribution>

So I just need to add this to the plugin.xml but attach it to org.osate.aadl2.Element objects.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 8, 2019

Added this to the org.osate.mylyn.aadl.ui plugin.xml file:

   <extension point = "org.eclipse.ui.popupMenus">
     <objectContribution
           adaptable="true"
           id="org.osate.mylyn.aadl.ui.RemoveFromContext"
           objectClass="org.osate.aadl2.Element">
        <action
              class="org.eclipse.mylyn.internal.context.ui.actions.InterestDecrementAction"
              definitionId="org.eclipse.mylyn.context.ui.commands.interest.decrement"
              enablesFor="*"
              icon="icons/interest-decrease.gif"
              id="org.osate.mylyn.aadl.ui.remove.element"
              label="Remove from Context"
              menubarPath="group.reorganize"
              tooltip="Mark selected element as uninteresting">
           <enablement>
              <systemProperty
                    name="org.eclipse.mylyn.context.core.context.active"
                    value="true">
              </systemProperty>
           </enablement>
        </action>
     </objectContribution>
   </extension>

The remove from context command appears in the context menu and works as expected.

Even better, removing all the context elements in a file will cause the mysterious close method to be called in the UI bridge.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 11, 2019

Implemented the close method. This only is ever useful when a package or property set object is removed from a context.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 11, 2019

Getting two "remove from context commands on IFile objects in the workspace. One comes from the mylyn resource plug-in. The other comes from the AADL plug-in. I think it's because we are processing IFile objects as adaptable to Element objects. Need to make sure only one command (preferably the one from resources) shows up.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 11, 2019

Put the AADL mylyn documentation in it's own section, not in the getting started document. The docs should be part of the org.osate.mylyn.aadl.ui plug-in.

See the org.osate.analysis.architecture plug-in for how to have the markdown converted to html during the build process.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 12, 2019

Getting two "remove from context commands on IFile objects in the workspace. One comes from the mylyn resource plug-in. The other comes from the AADL plug-in. I think it's because we are processing IFile objects as adaptable to Element objects. Need to make sure only one command (preferably the one from resources) shows up.

Easily fixed by setting the adaptable attribute of objectContribution to false.

@AaronGreenhouse

This comment has been minimized.

Copy link
Contributor Author

AaronGreenhouse commented Mar 15, 2019

Added help section. Should have the HTML auto-generated from the markdown during the build.

@lwrage lwrage added review and removed in progress labels Mar 17, 2019

@lwrage lwrage closed this in #1749 Mar 21, 2019

@wafflebot wafflebot bot removed the review label Mar 21, 2019

@lwrage lwrage changed the title Add mylyn support to OSATE Add initial mylyn support to OSATE Mar 21, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.