RE: [mylar-dev] implementing model bridges in Mylar

["Mik Kersten" <beatmik@xxxxxxx>]

Apologies for the gap in developer builds, there's one available now.  The
machine I build from had a hardware failure and I didn't prioritize this.
At some point we should reconsider setting up automated builds (bug 108291),
but building with PDE has been quite convenient to date.

Comments inline below.

> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Eugene Kuleshov
> 
>   Right now Mylar can be extended in two ways:
> 
> -- Additional connectors for the issue tracking systems
> http://wiki.eclipse.org/index.php/Mylar_Integrator_Reference#Creating_Conn
> ectors
> 
> -- Additional bridges to integrate context model (filtering, tracking
> interest etc).
> http://wiki.eclipse.org/index.php/Mylar_Integrator_Reference#Creating_Brid
> ges
> 
>   While connector integration is quite straight forward, bridges wasn't
> advertised much and still are kind of black box for most of the Mylar
> users and contributors.
>   Essentially bridges should allows tighter integration between Mylar
> and custom editors and non-Java oriented tools, such as CDT, RTD and
> number of others.

Yes, we need to make the Context Framework easier to use, encourage
adoption, and grow the documentation on that wiki page.  We also need to
improve the API, and the plan is to do that along with the next round of
model changes.  

>   I made some attempts to implement Mylar bridge for some custom editors
> but faced few issues. The most difficult one is to link selection
> provider with the logical model used by the custom editor. Thet means
> you have to use editor's internal classes to do that. Obviously this
> will require to either have dependency from Mylar to the editor, or from
> the editor to Mylar.
> 
>   I don't think 1st case is an option, because Mylar can't know about
> all custom models and development and support of all that stuff will be
> real nightmare.
> 
>   2nd option look little better in theory, but it is unclear how many
> plugin owners would want to have dependency on Mylar (even optional
> one). Though it would help if Mylar would provide minimally required set
> of dependencies for that.
>
>   On the other hand there is another option that may work better and
> could allow to actually take almost the same path as for case 1. This
> could be possible if Mylar would allow to use dynamic scripting
> languages (javascript, beanshell, groovy, jruby) to wire logical model.
> In that case there will be no dependency at the build time and adding
> new models could be even done dynamically (e.g. using some sort of
> configuration UI that would allow to paste some script fragments).
> 
>   Eclipse already has some sort of support for stuff like this and it
> might be interesting to investigate it further.
> 
> http://www.eclipse.org/dash/
> http://docs.codehaus.org/display/GROOVY/Groovy+Monkey

No matter how we structure the dependencies (either via plug-ins or via
dynamic scripting), the bridge that makes the mapping from the logical
domain model to the context model needs to know about both the logical model
and context.core.  Yes, this dependency could be achieved with a dynamic
language that provides the mapping.  But I wonder if this really would be a
win over doing this with a plug-in?  The plug-in is most likely necessary
because that's the way that extensibility works in Eclipse (e.g. the
plugin.xml needs to declare an ApplyMylar action for the relevant views).  

Regardless of the mechanism, I think that we need to address your point of
making bridges easier to extend, and where possible not requiring them to be
extended.  Regarding the UI actions, while we can improve on the current
architecture, the UI monitoring facilities are already generic in
org.eclipse.mylar.monitor, and hooking them up to editors and views relies
on Eclipse's generic mechanisms such as structured selections, filters, and
decorators.  So as you point out the crux is the structure bridge.  

Structure bridges have the ability to be composed.  For example, both Java
and the Ant bridges have the Resource bridge as their parent.  Similarly, we
could make a generic XML bridge that could optionally be extended by an XML
dialect specific bridge.  Or we could rely on a modeling facility like EMF
to provide the mapping between elements and bridges, and include a generic
EMF bridge.  

For 1.0 we will be focusing on improving the 'reference bridges' for the
Eclipse SDK to ship with 1.0.  Time permitting we may be able to extract a
generic XML bridge from Ant and PDE in order to facilitate integration with
WTP-based tools.  But in order to avoid premature generalization it would be
best the input of someone building a concrete bridge to provide input on
extensibility needs.  Are you considering creating one?

Mik