Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mylyn-incubator-dev] Problems writing a custom context bridge
The standard policy that applies to core Mylyn projects for maintaining backwards compatibility requires support for the last two major platform releases and the latest milestone(s), i.e. Eclipse 3.6, 3.7, 3.8M1, 4.2M1: http://wiki.eclipse.org/Mylyn/Integrator_Reference#Deciding_on_a_version

We generally do aim to support Eclipse 3.4 and 3.5 as well but support varies between components depending on the effort required (see bug 350639)

I have filed this bug to discuss the dependencies and requirements of the modeling bridge:

 355068: discuss pre-requisites of modeling bridge

Steffen


On Tue, Aug 16, 2011 at 11:32 PM, Miles Parker <miles.parker@xxxxxxxxxxx> wrote:

On Aug 16, 2011, at 2:19 AM, Jan Mauersberger wrote:

Hi Miles,

Yes, we're looking at moving that over too EclipseLabs git, but let me know if you want to commit to my fork.
Well, I just started to check some of the code. However, I recognized that you do work with eclipse 3.7 (I still use 3.6) - some of the dependencies in the manifests are explicitly referring to 3.7 or related newer packages (GMF, EMF etc.).  Are these dependencies made by intention or simply the result of the "assiduous" manifest editor?

Yes, a lot of it has to do with exactly as you say with perfect polite wording, the "assiduous" (I'd almost say obnoxious) manifest editor. I wouldn't be surprised though to discover that there are some 3.7 dependencies out there, but I'll try to keep it out of the core stuff as much as I can.


We still haven't really decided what to do about two things: 1. EMF tree editor (e.g. the Sample Model editor, etc..) as well as general EMF.Edit generated editors. That might require a specialized editor though it might be possible to do something with the adapter factory, I'll have to look into that. 2. Layouts. There are a lot of issues with how or if it makes sense to approach actually laying out the editors depending on DOI.
Definitely a bigger issue also for me, probably more interesting than the GMF stuff at the moment. During my experiments I at least managed to get my adapter factory based common viewer filtered based on the active task similar to how MyLyn contributes to Java browser etc.

That's awesome! Do you think you could adapt it to the current setup? Obviously feel free to ask me about how things are setup or make suggestions about how things could be better generalized. There is a tree editor bug there already and I could pass that off to you. My thinking is that ecore editor itself would be the best first target.

cheers,

Miles

_______________________________________________
mylyn-incubator-dev mailing list
mylyn-incubator-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/mylyn-incubator-dev




--
Steffen Pingel
Committer, http://eclipse.org/mylyn
Senior Developer, http://tasktop.com

Back to the top