Community
Participate
Working Groups
Using Eclipse 3.3.0.v20060920-1200-FAsok3gY1B-emWS, Mylar 0.8.0, CDT 3.1.1.200609270800, RDT 0.8.1.609062100PRD Some of Mylar's functions don't work in CDT. In particular the editor doesn't fold and unfold, the outline view always shows everything, quick outline doesn't follow Mylar rules, and the C/C++ Projects window doesn't respect the Mylar context. There may be some other things missing that I didn't notice. I noticed that Ruby (3rd party RDT plug-ins) doesn't honor Mylar either. I didn't try PHP or Phython or Web Tools but I suspect the same thing will happen there. For Mylar to be truly useful it needs to support all languages that Eclipse supports with little or no extra work that has to be repeated for each language. I develop with multiple languages and not having this is a barrier to using Mylar at all because I have to mentally shift in and out of task-focused mode depending on the language. If additional calls/bridges are absolutely required for the different languages, then they should be doable without those plugins having a dependency on Mylar (this may imply pushing some basic enabling API into the Platform and have Mylar extend it or provide a default implementation of it). This has many advantages including not having Mylar rely on Platform internals and letting researchers swap out Mylar with something else (for example the IBM Jazz folks might have an interest in this).
He he. And also Mylar should cook, clean and throw away all the garbage for you. :-) Seriously, Ed, each of those plugins mentioned by you has its own proprietary data model to represent specific content. I hardly believe it could be generalized to be useful, especially with not everybody willing to use all the platform API (team is a great example). Not to say that Mylar should non intrusively work with existing tools and it is actually doing quite well down to resource level if your plugins are using standard views (unfortunately RDT is not with basically no reason). At some point I've been suggesting to add scripting support into Mylar and use runtime scripting with groovy, jruby or bsh to do the bindings between mylar Model and these proprietary models... BTW, as far as I know Jazz does not do anything about interest models. So, they may as well just use Mylar to provide these features.
To follow up on Eugene's points, Mylar tries to make as much of the Task Context model and Task Focused UI support generic. However, it is limited by the amount of generic support in the platform, which is why we are continually pushing the platform to provide more genericity. The good news is that we do have one generic structure model in the Platform: resources. As such, task context works for any file. The bad news is that we have no generic structure model finer-grained than resources, so currently a bridge must be implemented for each domain-specific model. These bridges are not hard to create, but until Eclipse's LTK or some other generic model (e.g. EMF) is incorporated into the Platform and used by 3rd party tools we require these bridges. What we may be able to do to facilitate creating bridges is provide an IAdaptable-style mechanism for mapping domain objects to Mylar's context graph nodes, but it's not clear yet whether this will provide much value over the current approach, documented here: http://wiki.eclipse.org/index.php/Mylar_Integrator_Reference#Creating_Bridges On the UI end, things are better because we have generic abstractions for views and editors from the Platform. So adding the "Focus on Active Task" button to any structured view in Eclipse only takes a minimal extension to declare the action on that view. I'm updating this bug to be a request for a C/C++ bridge, and the CDT would be a great driver for helping us figure out if an IAdaptable approach or any patches to the LTK could make this task easier. Marking "helpwanted" since we would be very happy to support such an effort, but currently do not have the resources to implement bridges for tools beyond the Eclipse SDK.
As a C/C++ user, CDT committer (not as active as I used to be) and also a new Mylar user ... I want/need the integration to CDT so I'll take a kick at this if people are interested in having the help.
It would be great to see progress on this Thomas, glad to hear that you're interested. To get started check out the HEAD project set and see the other setup instructions: http://wiki.eclipse.org/index.php/Mylar_Contributor_Reference#Checkout And then take a look at the Integrator Reference, but note that the Java implementation will probably serve as a better guide. We can use this bug for discussion specific to your needs and update that documentation as we go. http://wiki.eclipse.org/index.php/Mylar_Integrator_Reference#Context_API
That sounds great. My first (hopefully straighforward) goal is to get the C/C++ Project view to be mylar'ized as well as the Make Target's view since both of those are central to the general development process.
That's the best place to start. Look at FocusPackageExplorerAction as an example (see context attached). As long as the elements in the views adapt to IResource you should get the focusing without needing to make a custom structure bridge.
Created attachment 63562 [details] mylar/context/zip
Thomas, I'm in the same boat as you, so would be glad to help if the need arises (and where time allows!)
I recently heard another inquiry about this from Michael Scharf. Is there interest in doing this on the CDT side? While we cannot expand our set of bridge reference implementations of bridges for the Eclipse SDK (files, Java, PDE, Ant), Mylyn would be very happy to support this effort. On today's Mylyn release review call Michael asked for a rough estimate of what would be involved in creating this. Based on my experience observing how a complete outsider (Spring IDE) created a Mylyn bridge, I think that the initial implementation of getting structure to show within files would take 2-4 weeks for an experienced Eclipse developer, and then under a day per week to evolve and maintain.
Thomas is actually on paternity leave for the first three months of the year. I have doubts we'll get this for Ganymede.
Mik, can you please give some more details about the estimate? Your numbers are about 2-4 times bigger then my experience with implementing simple Mylyn issue tracker connectors, which subjectively is more advanced task, considering the UI and all. Besides, bridge API org.eclipse.mylyn.context.ui.AbstractContextUiBridge, org.eclipse.mylyn.context.core.AbstractContextStructureBridge and corresponding extension points org.eclipse.mylyn.context.core.bridges and org.eclipse.mylyn.context.ui.bridges look simple enough. Maybe Andrey Platov can share his experience with implementing Mylyn bridge for DLTK.
Eugene, thanks for inviting and I would agree: 2-4 weeks looks like pessimistic estimation. However overall time-to-mylarize could cost something like that: CDT folks shall tweak build system to produce new component with dependency to Mylyn, etc. Also I would agree with original report from Ed - dependency to Mylar result in some discomfort with delivery process, starting from project building and up to Ganymede Update site: after installing both Mylyn and language IDE end-user shall figure out that he need to install specific "mylarization feature" to make both work together. This is neither intuitive nor it's well-understandable where such features shall live within Ganymede categories tree. If pushing some Mylyn API/contracts down to platform layer is not possible at this time we can try to find other ways to improve delivery. For example a kind of auto-installed features, which installation will be triggered by Update Manager on some condition. In this case when end-user have both Mylyn and CDT installed UM will propose him to install CDT mylarizing feature. Or CDT may check for Mylyn installed and assist user with required feature installation... General question is: will Platform support us on this topic or we'll support ourselves :) As for forcing Ganymede citizens to support Mylyn, probably we can force some special Ganymede-related page where each project can post own requirements (recommendations) to other applicable projects like: Mylyn: It would be great if each Ganymede language IDE will provide Mylyn bridge DSDP TM: It would be great if each Ganymede citizen will not crash when working with RSE Remote project ... Hope every Ganymede citizen will consider such "integration" recommendations.
Eugene: my estimate was very rough and only intended as a benchmark and vary with the experience of the developer and the breadth of features desired (e.g. focus additional views, auto folding for editor). Andrey: the distribution/coupling is an important consideration. I would recommend the following, since it has worked well for projects like Spring IDE: 1) Create a feature called "Mylyn Bridge: C++ Development" or "..: CDT" 2) Make the feature have a dependency have a dependency on ..mylyn.context.ui, ..mylyn.resources.ui and ..mylyn.ide.ui (this will bring in a few more core plug-ins. 3) For Ganymede via update site, the user will be informed that they need to install the corresponding Mylyn feature. 4) If CDT wanted this feature available with its EPP distributions, EPP would need to be informed and could add it to the CDT packaging. On a related note, step (4) could make sense independently, because the CDT bundling could redistribute just the Mylyn Task List (rich Bugzilla client, etc) without the Focused UI.
From what I know about the CDT, if CDT bridges will be implemented then focusing of the "Project Explorer" view should work. That would be the enough to start with. Then focusing for "C/C++ Projects" view and "Outline" view can be added later. Sorry if I am stating the obvious, but implementing AbstractContextUiBridge and AbstractContextStructureBridge would be easier to someone who understands CDT core models.
Is there any chance to get something before Ganymede, ie for Eclipse 3.3 with lates Mylyn release? From the comments it is not clear whether someone is planning to work on this or already doing so. I would love to test this feature! Cheers, Jörg
This would be really nice to have. I'll post to the cdt-dev list and see if anyone else is available to implement this. I haven't heard from Thomas in a while so I'm not sure he's still thinking of it. But I agree, someone familiar with the CModel would be the best choice.
Mylyn can support anyone interested in taking on this effort.
(In reply to comment #17) > Mylyn can support anyone interested in taking on this effort. > I would be interested in looking at this and have just started working on a prototype to see how far I could get. I am approaching this by trying to convert the JavaStructureBridge over to a CDT equivalent. The first issue to tackle was the whole handle-to-element, and element-to-handle interfaces. These are part and parcel of IJavaElements, but not ICElements. I decided to use a string formed of the CProject name, the path to TranslationUnit, and the element name if the element is within the TranslationUnit. I am using a '|' separator for the time-being to keep the segments distinct. I can use the CProject name to get the CProject via: CoreModel.getDefault().getCModel().getCProject(projectName). With the resource path, I can then get the TranslationUnit via: CoreModel.getDefault().createTranslationUnitFrom(cproject, path). And finally, I can get an element within the TranslationUnit via its getElement(name) method. Hopefully, this holds together logic-wise, but somebody more familiar with the CModel might be able to tell me if have missed something. I would see these interfaces eventually being moved into the C model code. For now, I am just declaring them static methods while I experiment. So, regarding your help. Can you explain what the relation providers are for and how/why Mylyn uses/needs them? There are a number of them constructed in JavaStructureBridge: these are JavaReferencesProvider, JavaImplementorsProvider, JavaReadAccessProvider, JavaWriteAccessProvider, and JUnitReferencesProvider.
Thank you Jeff. Feel free to propose any changes to the CModel that would make this easier. CDT 5 is a good opportunity for that and it may (should...) get harder in the future.
Jeff: Structure bridges rely on having a robust String-based representation of any element in a program. In JDT this conversion from object to String and back comes from the JavaCore class. If CDT does not have a similar class (e.g. PDE does not) it could be good to first prototype this in the bridge and then consider moving into the C model code as you and Doug allude. I can provide some pointers on what works well in such a facility if needed, but in general I think that the JavaCore approach works very well and the corresponding methods are reasonably straightforward to follow (see attached context or JavaCore.create(String) and IJavaElement.getHandleIdentifier()). Fyi, this handle identifier idiom and the IJavaElement virtual proxy pattern are used all over the place in Mylyn. Regarding the relation providers, you can ignore them since they are part of a fancier Mylyn facility for inferring the interest of structurally related element. That facility (ActiveSearch and related classes) was moved back into the Mylyn Sandbox for the time being and is optional.
Created attachment 87836 [details] mylyn/context/zip
(In reply to comment #20) > > Regarding the relation providers, you can ignore them since they are part of a > fancier Mylyn facility for inferring the interest of structurally related > element. That facility (ActiveSearch and related classes) was moved back into > the Mylyn Sandbox for the time being and is optional. > Ok, I've been basing the code on the Java version, translating various Java calls to appropriate CDT ones. I have a question about one piece of code that uses relation provider ids. In JavaEditingMonitor.handleWorkbenchPartSelection there is an else clause that starts with: } else { if (selection instanceof TextSelection && part instanceof JavaEditor) { currentEditor = (JavaEditor) part; TextSelection textSelection = (TextSelection) selection; selectedElement = SelectionConverter.resolveEnclosingElement(currentEditor, textSelection); if (selectedElement instanceof IPackageDeclaration) return; // HACK: ignoring these selections IJavaElement[] resolved = SelectionConverter.codeResolve(currentEditor); if (resolved != null && resolved.length == 1 && !resolved[0].equals(selectedElement)) { lastResolvedElement = resolved[0]; } I do not understand what the code following the initial section is doing. It tests for IMethod and does some checks of lastSelectedElement and lastResolvedElement. It then calls super.handleNavigation() passing relation provider ids for the "kind" argument. What is the code doing and can I exclude the parts that are using the relation provider ids? Alternately, can I substitute an arbitrary string in for the "kind" argument to handleNavigation() or must that match up with some existing relations provider?
Just a reminder that API freeze is M6 which is scheduled for the last week of March. We'd need to get this API change in soon.
(In reply to comment #23) > Just a reminder that API freeze is M6 which is scheduled for the last week of > March. We'd need to get this API change in soon. > Is this the element handle API change or are you referring to the CDT bridge itself? I have a reasonably working prototype up now which uses my static element handle code I wrote. I can't seem to get Functions to appear in the Context view and when the Mylyn filtering occurs, they are removed from the C/C++ Project view and Outline views. There are a few menus that aren't responding to NLS strings put in plugin.xml and they are printing out the message label strings instead. I can always make these English for now. Are there any preferences to where this plugin is located? I currently have it under mylyn (org.eclipse.mylyn.cdt.ui), but I imagine you would be looking to place it in the CDT. Correct? I can post my current patch if some Mylyn folks would be willing to help me to get the Functions to appear in a C file. I have not done extensive testing as I only recently got back to working on it. I also didn't implement the completion stuff as I don't know if that is necessary in the first pass.
(In reply to comment #24) > Is this the element handle API change or are you referring to the CDT bridge > itself? The element handle API change needs to be done by March. The bridge itself can wait until later. The feature freeze is end of April. But the sooner we can check it in, the sooner we can get it through IP checks and testing. > I have a reasonably working prototype up now which uses my static > element handle code I wrote. I can't seem to get Functions to appear in the > Context view and when the Mylyn filtering occurs, they are removed from the > C/C++ Project view and Outline views. There are a few menus that aren't > responding to NLS strings put in plugin.xml and they are printing out the > message label strings instead. I can always make these English for now. I think you still have time to fix some of these things first. > Are there any preferences to where this plugin is located? I currently have it > under mylyn (org.eclipse.mylyn.cdt.ui), but I imagine you would be looking to > place it in the CDT. Correct? Good question. Mik, what are your thoughts on this?
(In reply to comment #25) > > Are there any preferences to where this plugin is located? I currently have it > > under mylyn (org.eclipse.mylyn.cdt.ui), but I imagine you would be looking to > > place it in the CDT. Correct? > > Good question. Mik, what are your thoughts on this? Our recommendation for naming bridges is by the project that they're a part of, not Mylyn, since we consider the Mylyn UI parts to be higher in the stack (between the Workbench UI and the extension). So assuming that the contribution is to CDT, I recommend "org.eclipse.cdt.mylyn.ui". If the contribution were externally-hosted it would be something like "org.myproject.cdt.mylyn.ui". Would this work for you guys? Fyi, we have some of this documented for connectors: http://wiki.eclipse.org/index.php/Mylyn_Integrator_Reference#Creating_connector_projects (In reply to comment #22) > I do not understand what the code following the initial section is doing. It > tests for IMethod and does some checks of lastSelectedElement and > lastResolvedElement. It then calls super.handleNavigation() passing relation > provider ids for the "kind" argument. Jeff: sorry for the very slow reply, we have been pinned with Mylyn 2.3 and the Europa Winter Update. That code does a pretty fancy resolution to determine whether the user has navigated between two structurally related elements. For example, if I navigate from a method to a method that overrides it, the task context model will have a relationship added to it in addition to having the elements added. This facility is not used in the standard Mylyn UI, only in some experimental visualization UIs in our incubator. For now you should ignore this additional facility and only care about the following case: if (selectedElement != null) { if (!selectionResolved && selectedElement.equals(lastSelectedElement)) { super.handleElementEdit(part, selectedElement, contributeToContext); } else if (!selectedElement.equals(lastSelectedElement)) { super.handleElementSelection(part, selectedElement, contributeToContext); } }
Created attachment 91683 [details] mylyn/context/zip
Thanks for the info Mik. Now, some more questions. I have basic functionality working, but I run into a problem. I cannot get Mylyn to create a landmark on a C function. In fact, until I forced it via canFilter to leave IFunction types alone, Mylyn was scrubbing functions in the Context view and it was removing them from the C/C++ Project View when I activated the current task. When I try to increase a function's interest I get an error message: "Not a valid landmark, select an element within this resource instead" I set the parentContentType field of the Structure Bridge to resource as was done for the java bridge. This refers to the ResourceStructureBridge but other than that, I have no idea what it actually does. I have a general Eclipse question as well. I forgot to check plugin.properties in my initial Binary build. I did this later and then rebuilt, but I still get %xxxx labels all over the place in menus, even though they are specified in plugin.properties and when I edit the plugin.xml, they show up as resolved strings. Is there some sort of caching I can clear to fix this (I am running an Eclipse application with my plugins activated and I have specified the -clean option)? Finally, I have the Outline view Focus Active task working, but it is disabled until an object is clicked in the Outline view (e.g. clicking on one of the functions activates the Mylyn Focus Active Task icon). Any ideas on why this is? I am going to post my current code now. I will eventually refactor it into the CDT as you have suggested when I get a number of these problems cleared up.
Created attachment 91692 [details] Zipped org.eclipse.mylyn.cdt.ui plugin
(In reply to comment #28) > Thanks for the info Mik. Now, some more questions. > > I have basic functionality working, but I run into a problem. I cannot get > Mylyn to create a landmark on a C function. In fact, until I forced it via > canFilter to leave IFunction types alone, Mylyn was scrubbing functions in the > Context view and it was removing them from the C/C++ Project View when I > activated the current task. > Some further investigation. My CDTEditorMonitor is never invoked. When I select a Function, the JDTEditingMonitor, the PDEEditing Monitor, the AntEditingMonitor, and the Resource Monitor all get called, but not the CDT one. So, I never get to the code snippet you mentioned in handleWorkbenchPartSelection()
(In reply to comment #30) > (In reply to comment #28) > > Thanks for the info Mik. Now, some more questions. > > > > I have basic functionality working, but I run into a problem. I cannot get > > Mylyn to create a landmark on a C function. In fact, until I forced it via > > canFilter to leave IFunction types alone, Mylyn was scrubbing functions in the > > Context view and it was removing them from the C/C++ Project View when I > > activated the current task. > > > > Some further investigation. My CDTEditorMonitor is never invoked. When I > select a Function, the JDTEditingMonitor, the PDEEditing Monitor, the > AntEditingMonitor, and the Resource Monitor all get called, but not the CDT > one. So, I never get to the code snippet you mentioned in > handleWorkbenchPartSelection() > Solved the problem. My plugin didn't have the activator class set (stupid) . I am able to set lankmarks on functions now and they show up in bold now.
Note that if you have a structure bridge that shows elements below the file level, for Java we discourage allowing the landmark itself to become a file (bug 111165). You could experiment with CDT to figure out what the desired behavior is, but note that if you let both the class and the file be a landmark you can end up with too much boldness in the view :)
Created attachment 92233 [details] Zipped org.eclipse.cdt.mylyn.ui plugin
(In reply to comment #32) > Note that if you have a structure bridge that shows elements below the file > level, for Java we discourage allowing the landmark itself to become a file > (bug 111165). You could experiment with CDT to figure out what the desired > behavior is, but note that if you let both the class and the file be a landmark > you can end up with too much boldness in the view :) > I am only currently allowing landmarks for functions and methods. I have just attached a refactored version of the bridge (org.eclipse.cdt.mylyn.ui) per a previous suggestion of where the plugin could go. There are multiple fixes from the old version. It would be nice if I could get some feedback on it. I only did manual testing with Eclipse 3.4M5 and CDT 4.0.3 as I don't have a set of JUnit tests yet. I am looking at converting applicable Java UI Bridge tests over, but I am not familiar enough with CDT test set up so I'll have to look at how the CDT tests do it. If anybody wants to help out, that would be great.
(In reply to comment #34) > I have just attached a refactored version of the bridge > (org.eclipse.cdt.mylyn.ui) per a previous suggestion of where the plugin could > go. There are multiple fixes from the old version. It would be nice if I > could get some feedback on it. I only did manual testing with Eclipse 3.4M5 > and CDT 4.0.3 as I don't have a set of JUnit tests yet. I am looking at > converting applicable Java UI Bridge tests over, but I am not familiar enough > with CDT test set up so I'll have to look at how the CDT tests do it. If > anybody wants to help out, that would be great. > I tried the plug-in with CDT from HEAD (5.0) and encountered several exceptions: java.lang.ArrayIndexOutOfBoundsException: 0 at org.eclipse.cdt.mylyn.internal.ui.CDTEditorMonitor.handleWorkbenchPartSelection(CDTEditorMonitor.java:77) at org.eclipse.mylyn.monitor.ui.AbstractUserInteractionMonitor.selectionChanged(AbstractUserInteractionMonitor.java:66) java.lang.NullPointerException at org.eclipse.cdt.mylyn.internal.ui.CDTStructureBridge.getHandleForElement(CDTStructureBridge.java:172) at org.eclipse.cdt.mylyn.internal.ui.CDTStructureBridge.getHandleIdentifier(CDTStructureBridge.java:203) at org.eclipse.mylyn.internal.context.ui.InterestDecoratorLightweight.decorate(InterestDecoratorLightweight.java:59) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:259) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:72) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) java.lang.NoSuchFieldException: fTreeViewer at java.lang.Class.getDeclaredField(Class.java:1882) at org.eclipse.cdt.mylyn.internal.ui.CDTUiBridge.<init>(CDTUiBridge.java:48) The first exception happens with almost every selection in the editor. The second exception should be fixed when you use the new handle identifier API (bug 219993). The last exception is due to a refactoring of the CContentOutlinePage in 5.0. Should be easy to fix.
Created attachment 92367 [details] Zipped org.eclipse.cdt.mylyn.ui plugin that works on CDT head
(In reply to comment #35) > (In reply to comment #34) > > I have just attached a refactored version of the bridge > > (org.eclipse.cdt.mylyn.ui) per a previous suggestion of where the plugin could > > go. There are multiple fixes from the old version. It would be nice if I > > could get some feedback on it. I only did manual testing with Eclipse 3.4M5 > > and CDT 4.0.3 as I don't have a set of JUnit tests yet. I am looking at > > converting applicable Java UI Bridge tests over, but I am not familiar enough > > with CDT test set up so I'll have to look at how the CDT tests do it. If > > anybody wants to help out, that would be great. > > > > I tried the plug-in with CDT from HEAD (5.0) and encountered several > exceptions: > > java.lang.ArrayIndexOutOfBoundsException: 0 > at > org.eclipse.cdt.mylyn.internal.ui.CDTEditorMonitor.handleWorkbenchPartSelection(CDTEditorMonitor.java:77) > at > org.eclipse.mylyn.monitor.ui.AbstractUserInteractionMonitor.selectionChanged(AbstractUserInteractionMonitor.java:66) > > > java.lang.NullPointerException > at > org.eclipse.cdt.mylyn.internal.ui.CDTStructureBridge.getHandleForElement(CDTStructureBridge.java:172) > at > org.eclipse.cdt.mylyn.internal.ui.CDTStructureBridge.getHandleIdentifier(CDTStructureBridge.java:203) > at > org.eclipse.mylyn.internal.context.ui.InterestDecoratorLightweight.decorate(InterestDecoratorLightweight.java:59) > at > org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:259) > at > org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:72) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > > > java.lang.NoSuchFieldException: fTreeViewer > at java.lang.Class.getDeclaredField(Class.java:1882) > at > org.eclipse.cdt.mylyn.internal.ui.CDTUiBridge.<init>(CDTUiBridge.java:48) > > > The first exception happens with almost every selection in the editor. > The second exception should be fixed when you use the new handle identifier API > (bug 219993). > The last exception is due to a refactoring of the CContentOutlinePage in 5.0. > Should be easy to fix. > Thanks Anton. I had originally built against 4.0.3. With CDT HEAD check-out, I fixed the 1st and 3rd bugs, but was unable to reproduce the 2nd NullPointer exception with the old API in place. Can you elaborate what you were trying at the time? The latest zip has not switched over to the new API yet, but I will post shortly after some initial testing.
(In reply to comment #37) > Thanks Anton. I had originally built against 4.0.3. With CDT HEAD check-out, > I fixed the 1st and 3rd bugs, but was unable to reproduce the 2nd NullPointer > exception with the old API in place. Can you elaborate what you were trying at > the time? The latest zip has not switched over to the new API yet, but I will > post shortly after some initial testing. > The NPE happens with external header files, e.g. when you navigate to a standard include, like "stdio.h".
(In reply to comment #38) > (In reply to comment #37) > > Thanks Anton. I had originally built against 4.0.3. With CDT HEAD check-out, > > I fixed the 1st and 3rd bugs, but was unable to reproduce the 2nd NullPointer > > exception with the old API in place. Can you elaborate what you were trying at > > the time? The latest zip has not switched over to the new API yet, but I will > > post shortly after some initial testing. > > > > The NPE happens with external header files, e.g. when you navigate to a > standard include, like "stdio.h". > Ok, I hadn't tried that. I have made the switch over to the new API, but almost everything is failing to get an object from the handle. I am running on Fedora 8 with Eclipse 3.4 M5 downloaded with CDT Head checked out + my CDT+Mylyn code, running an Eclipse application using all plug-ins in the workspace. I made changes to the two following methods in CDTStructureBridge: public static String getHandleForElement(ICElement element) { System.out.println("element is " + element.getClass().getName()); System.out.println("handle is " + element.getHandleIdentifier()); return element.getHandleIdentifier(); } public static ICElement getElementForHandle(String handle) { System.out.println("[handle is " + handle); ICElement s = CoreModel.create(handle); if (s == null) System.out.println("[null handle is " + handle); else System.out.println("[element is " + s.getElementName()); return s; } There is no issue with getting the handles, but the only object I am able to get an element back again is the project itself. Everything else returns null. A snippet of the console output is: element is org.eclipse.cdt.internal.core.model.CContainer handle is =cppproject<Debug [handle is =cppproject<Debug [null handle is =cppproject<Debug element is org.eclipse.cdt.internal.core.model.TranslationUnit handle is =cppproject/src{cppproject.cpp [handle is =cppproject/src{cppproject.cpp [null handle is =cppproject/src{cppproject.cpp element is org.eclipse.cdt.internal.core.model.TranslationUnit handle is =cppproject/src{cppproject.h [handle is =cppproject/src{cppproject.h [null handle is =cppproject/src{cppproject.h element is org.eclipse.cdt.internal.core.model.Include handle is =cppproject/src{cppproject.cpp[iostream#75 [handle is =cppproject/src{cppproject.cpp[iostream#75 [null handle is =cppproject/src{cppproject.cpp[iostream#75 element is org.eclipse.cdt.internal.core.model.Include handle is =cppproject/src{cppproject.cpp[cppproject.h#75 [handle is =cppproject/src{cppproject.cpp[cppproject.h#75 [null handle is =cppproject/src{cppproject.cpp[cppproject.h#75 element is org.eclipse.cdt.internal.core.model.Using handle is =cppproject/src{cppproject.cpp[std#62 [handle is =cppproject/src{cppproject.cpp[std#62 [null handle is =cppproject/src{cppproject.cpp[std#62 element is org.eclipse.cdt.internal.core.model.Function handle is =cppproject/src{cppproject.cpp[cppproject::member1#74(int [handle is =cppproject/src{cppproject.cpp[cppproject::member1#74(int [null handle is =cppproject/src{cppproject.cpp[cppproject::member1#74(int element is org.eclipse.cdt.internal.core.model.Function handle is =cppproject/src{cppproject.cpp[cppproject::member2#74(int [handle is =cppproject/src{cppproject.cpp[cppproject::member2#74(int [null handle is =cppproject/src{cppproject.cpp[cppproject::member2#74(int element is org.eclipse.cdt.internal.core.model.Function handle is =cppproject/src{cppproject.cpp[main#74 [handle is =cppproject/src{cppproject.cpp[main#74 [null handle is =cppproject/src{cppproject.cpp[main#74 element is org.eclipse.cdt.internal.core.model.BinaryContainer handle is =cppproject [handle is =cppproject [element is cppproject Could you try making the changes above and see what happens for you? I will attach the project: cpprproject mentioned above. It was based off of a simple HelloWorld C++ project created by the CDT wizard.
Created attachment 92508 [details] Sample C++ project used in Mylyn test
(In reply to comment #39) > > Could you try making the changes above and see what happens for you? I will > attach the project: cpprproject mentioned above. It was based off of a simple > HelloWorld C++ project created by the CDT wizard. > Thanks, there was a bug with restoring source roots. My JUnit test creates a project where the project itself is the source root, so I didn't find that bug earlier.
(In reply to comment #41) > (In reply to comment #39) > > > > Could you try making the changes above and see what happens for you? I will > > attach the project: cpprproject mentioned above. It was based off of a simple > > HelloWorld C++ project created by the CDT wizard. > > > > Thanks, there was a bug with restoring source roots. My JUnit test creates a > project where the project itself is the source root, so I didn't find that bug > earlier. > That's much better. I think that for the elements that aren't supported, null should be returned as a handle instead of the project's handle. In testing, I am finding that the context is getting confused. For example, the Binaries container shows up in the context view which should never occur.
Will there be some beta version of this bridge for Mylyn 2.3? I am really eager to give this bridge a try. Cheers, Jörg
(In reply to comment #42) > That's much better. I think that for the elements that aren't supported, null > should be returned as a handle instead of the project's handle. In testing, I > am finding that the context is getting confused. For example, the Binaries > container shows up in the context view which should never occur. Makes sense, I'll change that. I was trying to follow JDT's API which does not allow null as a return value.
(In reply to comment #44) > (In reply to comment #42) > > That's much better. I think that for the elements that aren't supported, null > > should be returned as a handle instead of the project's handle. In testing, I > > am finding that the context is getting confused. For example, the Binaries > > container shows up in the context view which should never occur. > > Makes sense, I'll change that. I was trying to follow JDT's API which does not > allow null as a return value. > Thanks, that works. I also made the fix regarding CEditor element selection and that has helped the selection behavior with regards to C++ methods.
Created attachment 92752 [details] Latest version of org.eclipse.cdt.mylyn.ui plugin working with CDT head
Definitely a lot of interest in this in the CDT community. Let's work on getting it into CDT 5.0. We'll create a separate feature and add it to our optional features list. I'm going to leave it on the cdt-core-inbox since it'll be a bit of a group effort. Mind you we probably need a new component for things like this. We do need to get the new plugin passed through Eclipse IP checks and I'll take care of getting that done. Once we get that done, we should be able to apply patches without further review. Much thanks, Jeff. This is a great addition to the CDT.
Great to see so much action on this, it would be fantastic to have CDT 5.0 users get Mylyn! Please don't hesitate to post questions or other suggestion for Mylyn committers to help out. Please note that Mylyn will be breaking API between 2.3 and 3.0, so I suggest that those extending the API add a watch to the following wiki page: http://wiki.eclipse.org/Mylyn_Porting_Guide We will ensure that the port is straightforward. For the time being it will be easiest to build this against e_3_4_m_2_x and not HEAD: http://wiki.eclipse.org/Mylyn_Contributor_Reference#Checkout Doug: While this effort is underway, I wonder if in parallel we should start considering the packaging of this? Mylyn 3.0 is a good opportunity for us to make sure that our features can be combined in a way where CDT gets all the task and focus integration.
(In reply to comment #48) > Doug: While this effort is underway, I wonder if in parallel we should start > considering the packaging of this? Mylyn 3.0 is a good opportunity for us to > make sure that our features can be combined in a way where CDT gets all the > task and focus integration. Are you thinking about EPP packages / Ganymede stuff here, Mik?
Created attachment 95302 [details] Patch for IPZilla I've updated the plugin with small fixes to the copyrights. Ready for IPzilla.
Created attachment 95303 [details] Patch for IPZilla OK, it's a patch that's really a zip.
IP review has been approved. I have checked in this plug-in and am currently working on getting it into the build. It should appear in tonight's CDT nightly (http://download.eclipse.org/tools/cdt/builds). Thank you Jeff! And thank you Mik for your guidance. This is an exciting new feature for the CDT.
Fantastic. Let us know if you want any assistance with selecting features for EPP packaging.
Yeah, actually. Should I just copy over the same settings from the other EPP projects or do you have a set list you like to include.
Doug: yup, you can use the same settings as we use for the other packages, excluding the org.eclipse.mylyn.java-feature. Steffen: please point Doug at the listing.
Yes, it makes sense to use the same dependencies as the EPP Java package excluding the org.eclipse.mylyn.java_feature. The package specification file eclipse_java_340.xml is in org.eclipse.epp/releng/org.eclipse.epp.config in the technology cvs.
Yup, I know where those are. Thanks guys!
Doug: let us know when the support has made it into the EPP builds and we'll be happy to test. Jeff: I assume that the support is coded against Mylyn 2.3.x?
I tested CDT 5.0.0.200805050803 with the latest Ganymede Java package which contains Mylyn 3.0.0.I20080327-1500 and it worked. Great stuff Jeff! The only nit I noticed is that the project explorer has two focus buttons and Alt+click didn't always work (e.g. when clicking constructors).
(In reply to comment #59) > The only nit I noticed is that the project explorer has two focus buttons That's my fault. I did not recognize that Mylyn already adds that action to the Project Explorer. I'll remove the duplicate.
Created attachment 102054 [details] Patch 1 for Mylyn 3.0 change to status message handling
Created attachment 102056 [details] Patch 2 for CDT Mylyn Manifest to depend on Mylyn 3.0 plugins
Created attachment 102057 [details] Patch 3 for CDT to use new Mylyn 3.0 AbstractContextListener class
Created attachment 102058 [details] Patch 4 for CDT removal of unused preference wizards that no longer build
Created attachment 102060 [details] Patch 5 of 5 that removes invalid fully qualified name support test
I have added 5 new patches to support the new Mylyn 3.0 API changes. Patch 1 is code that needs to change because the StatusHandler messaging class has changed. Patch 2 is the Manifest file which needs to change the dependencies to new Mylyn 3.0 plugins and to also specify the versions that are now required. It also removes any exported packages that no longer exist. Patch 3 are changes whereby classes need to inherit from AbstractContextListener instead of implementing IInteractionContextListener interfaces that no longer exist. These files also will change any StatusHandler references. As well, any reference to ContextUiPrefContstants has been replaced as the class no longer exists. Patch 4 deals with the removal of the RecommendedPreferencesWizards that were not being used except to provide a special constant. The constant has been moved to CDTUIBridgePlugin. The constant for the auto folding preference id has been moved here as well and is used to replace references to ContextUiPrefContstants.ACTIVE_FOLDING_ENABLED which no longer exists. Patch 5 is a special case whereby the CDTContextLabelProvider had a check for a fully qualified name option. The class to test for the option no longer exists so the check has been commented out. It is not necessary for usage.
Reopening to get the Mylin 3.0 API support. This is for Ganymede isn't it?
Patch applied. Thanks Jeff! My testing worked well. I created a Local task and Mylyn kept track of the C++ files I changed. Funny thing, though is that it also highlighted a bug we have that the .cproject file changes all the time :)
The plug-in no longer registers functions and methods as context elements. I had a quick look and the lazyStart() method in CDTUIBridgePlugin is no longer called, thus the plug-in is not properly initialized. I'll work on a fix.
Created attachment 102339 [details] Patch to fix missing initialization This patch adds an extension to "org.eclipse.mylyn.context.ui.startup" providing a lazy startup class implementing IContextUiStartup (cloned from the java bridge plug-in). I'll do some more testing and apply it to HEAD.
Committed to HEAD.
(In reply to comment #68) > Patch applied. Thanks Jeff! Excellent. We'll test the EPP distros. > Funny thing, though is that it also highlighted a bug we have > that the .cproject file changes all the time :) Just curious, did you notice this in your Synchronize view or in the Package Explorer? Mylyn is supposed to not making any files interesting that start with "." for this very reason. But we have been experimenting with changes to the the way interest is tracked for resource deltas and may have invalidated part of this rule. Fyi, it's specified with the following extension point which CDT or others could use in order to suppress making configuration files interesting. But ".cproject" should not be necessary since (In reply to comment #69) > The plug-in no longer registers functions and methods as context elements. > I had a quick look and the lazyStart() method in CDTUIBridgePlugin is no longer > called, thus the plug-in is not properly initialized. > I'll work on a fix. Anton: good to hear. Steffen: once the next EPP build is available let's make sure to test that the lazy loading ensures that the bridge plug-ins are not loaded if a CDT user has not activated the task. I've added a note on this to our manual testing page: http://wiki.eclipse.org/Mylyn/Testing#EPP
(In reply to comment #72) > Just curious, did you notice this in your Synchronize view or in the Package > Explorer? Mylyn is supposed to not making any files interesting that start > with "." for this very reason. But we have been experimenting with changes to > the the way interest is tracked for resource deltas and may have invalidated > part of this rule. Fyi, it's specified with the following extension point > which CDT or others could use in order to suppress making configuration files > interesting. But ".cproject" should not be necessary since It was in the Project Explorer. We use the common navigator for our projects. I may have the . file filter turned off to test something.
