I am currently trying to modify the behavior of an existing open-source plug-in for Eclipse.
I'm trying to understand how the plugin works. To do so, I opened it in "Debug" mode as an Eclipse application and I am testing it out after having inserted many breakpoints.
However, sine Eclipse plugins do not have a Main method, it's still really difficult for me to keep track of everything that is going on. The calls seem to jump arbitrarily (which I quickly realized was happening through all the interfaces and superclasses the plugin is inheriting) and I can't see exactly what's doing what.
What is the proper (read: BEST) way to debug a program with no Main method? How can I test, tweak, and explore and program - in this case a plugin - whose modus operandi I'm uncertain of?
You need to run your plugin in a runtime workbench. This (simplistically) starts a new instance of Eclipse with all existing plugins installed, plus the plugin you want to debug. Make sure that you have the PDE tools installed in your Eclipse instance and then in the debug configurations area, double-click on Eclipse Application to generate a default runtime workbench launch config.
I'd also recommend that you read up on PDE (plugin development environment), and you can get an overview here: http://wiki.eclipse.org/PDE/FAQ. And you can read up on plugins in general here: http://eclipsepluginsite.com/. There are many tutorials and lots of information all over the web. So, google is your friend.
Along with using breakpoints in Debug method you can even try printing stack trace using Thread.currentThread().getStackTrace() method to know the starting point of a Thread.
Related
I apologise for the very amateur question about E4 but I am a bit confused about a couple of things about RCP development using the new Eclipse 4 framework. I read in this tutorial that one can no longer use any default commands the way we could in 3.x especially for common things like Save, Save As... in the File menu. It says that in E4 we have to write our own commands. The reason I am confused is because the thing I liked about Eclipse previously is that a lot of things are already implemented and we can just extend that to our own needs. But it feels like now everything must be written from scratch.
That led me to considering reusing the command code already written for Eclipse Juno. I had the Live Editor open so I could see the list of commands etc but I don't really see any Handlers implemented for any of them. Then I used the Spy on Eclipse Juno and checked out some of the menu items and they all seem to point to Actions. That really confused me as I thought Juno was based on E4.
I could be completely wrong so I am sorry for asking such a silly question. I only just started using E4 and need to decide whether one of fairly young Eclipse 3.x projects should be migrated to 4.x.
AfaIk, in Juno the compatibility layer translates the 3.x based implementation of the IDE into E4 concepts. This is also the reason why the reusable commands are not yet available.
If you have an 3.x based RCP it should also run using the compatibility layer (and you can reuse the commands mentioned in your question) if no incompatible APIs have been used.
Here is more information (also a tutorial from Lars Vogel): http://www.vogella.com/articles/Eclipse4CompatibilityLayer/article.html
We have rather large code base (150+ projects, 400000+ lines of Java code, some Groovy and Gradle code, some Perl code, some XML, a lot of JSPs etc.). I managed to open all those projects in Spring Tools Studio 2.6 to which I also added some plugins for Groovy, Perl, Checkstyle, PMD.
And the problem is that Eclipse is holding my CPU busy all the time. And it's really slow when I update something, it's building slowly, any kind of UI operations happen with a delay.
Also I have rather good machine 64-bit, 8GBs of RAM and I run 64-bit version of STS and I give 2GBs to Eclipse (but it does not get higher that 1GB of heap anyway).
So, my first question is there a way to determine what is making it slow? And do some of you guys have succeded in working with such large code bases in a single workspace?
I have tried looking at the threads (using jconsole) of the JVM that runs Eclipse, but I can't find anything intersting there.
I'll make a few suggestions - these are in order of easiness. If you are hell bent on figuring out what plugin it was and either joining that project to fix it or send hate mail to a support list, then you probably want to skip to "Profile It" below.
Check the console
If you start eclipse from the command line ( ie type eclipse ) then if there are any exceptions being thrown you'll see them in here. Sometimes slowness can be caused by a plugin repeatedly failing and throwing lots of exception. Sometimes it is something you can fix - sometimes you have to remove that plugin.
Boost your RAM
We love GC but it causes a slow death. The beauty of GC is that your program never runs out of memory - because the user thinks it has locked up and kills it before it actually runs out of ram. So, try increasing the PermGen and other Eclipse memory settings: http://wiki.eclipse.org/FAQ_How_do_I_increase_the_heap_size_available_to_Eclipse%3F
Create a new Workspace
I often give up and just delete/recreate the whole workspace. There are so many plugins there is can be a real challenge to debug and often it garbage in the workspace directory that keeps things breaking.
Keep Eclipse Lean
If I want to keep Eclipse really snappy, I'll create an install for a single project and add only the plugins needed. If you can start from the non-EE version you're already far less bloated.
Profile It
The VisualVM that is included in with the Sun JDK (you probably already have it installed.) can be used to see what classes are consuming the most processor time and which objects are taking up memory (and what created them).
Start VisualVM up, and you should see Eclipse listed in the Applications. Right click on the Eclipse entry and "Open" Eclipse inside VisualVM. You can now attach a profiler and see what classes are being used.
Profiling will slow everything down (a lot!) so you might want to start with the smallest possible example you can - or be extremely patient. Especially at the start of profiling it will take a long time as it 'instruments' the classes (injecting bytecode to allow profiling).
One way to know what Eclipse is doing by enabling debugging. There is some information here about debugging eclipse builders, however the process is generic i.e. you need to start eclipse from command line $eclipsec –debug > log.txt and enable debugging for certain plugins using the .options file. I guess you would want to look a bit closely at 'update' and 'build' operations.
Another option would be to use a tool, e.g. MAT (Memory Analyzer), YourKit. I find YourKit to be quite useful, you could for example enable CPU profiling in YourKit and then perform an action in Eclipse which you feel is taking a lot of time. Once the action completes, you can take a snapshot and do some analysis in YourKit. A caveat is that a attaching the YourKit profiler to Eclipse will further slow down Eclipse.
Having said that 150+ projects in one workspace is a bit much. If it is possible you should probably setup one workspace per component with the rest of the plugins in a target platform. All your workspaces can share a single target platform. With 150+ projects a full workspace build alone can take quite a bit of time since a large number of class files have to be generated which means a large amount of disk IO, and eclipse cannot help you there only a SSD can :)
Eclipse 2019-09 proposes a new way:
Automatic detection of UI freezes in the Eclipse SDK
The Eclipse SDK has been configured to show stack traces for UI freezes in the Error Log view by default for new workspaces.
You can use this information to identify and report slow parts of the Eclipse IDE.
You can disable the monitoring or tweak its settings via the options in the General > UI Responsiveness Monitoring preference page as shown below.
When step-debugging in eclipse, is it possible to instruct the debugger to traverse only steps within my project's sources?
I am debugging a rails application and much of the calls are moving through rails' infrastructure (such as activerecord) which I am not interested in following. I would prefer the step-debugger to skip these files, instead hitting the next line within my own source files.
I don't think you can prevent Eclipse to "Step into" a code, even if it isn't directly part of your project.
The only filtering in place is provided with Mylyn, in order to help you to focus on "the current task" at hand, with a "context" you help define!
It is possible in Java. I don't know if Ruby debugger in Eclipse has so mature as the Java one or not. Read this.
I'm trying to use Google Protocol Buffers in my project and I'd like to have some tooling support from Eclipse. In particular, I want Eclipse to call protoc every time I make changes to the .proto files and then rebuild all code that depends on the generated code.
I tried to set up a Custom Builder but it keeps bugging me with errors I don't understand, most often it complains that the .proto file is not on the path given by --proto-path, which it should be by all I can tell. Also, because I use ${build_files}, Eclipse passes all changed files to the compiler (instead of those that I have configured to trigger the build).
NetBeans seems to have a protobuf-Plugin, but I can't find one for Eclipse. Is there one?
Theres a protoclipse plugin on googlecode, which is in the initial stages:
http://code.google.com/p/protoclipse/
Not sure if there is a builder, but I did find a plugin for syntax highlighting for protocol buffers.
You can define an external builder on the plugin that invokes an ant task. It is an ugly kludge, but until there is a better solution this may serve your purposes.
In practice, syntax highlighting turned out to not be that important, I hardly edit these files, and they tend to be very small. Maven and the m2eclipse plugin handle the building side of things great.
I recommend using Google's "Protocol Buffers Development Tools". It is a plugin for Eclipse that features automagic regeneration and error checking, among other things. It's available here: http://code.google.com/p/protobuf-dt/ .
While this question is close to other Eclipse plugin for working with protobuf, answers here are different.
Well, yes, if you use maven/gradle to invoke protoc (Protobuf compiler), than you may need no Eclipse plugin at all.
Colorizing editor helps for long file or with many comments. Know there are 2 editor plugins for Eclipse.
I want to use the "Web Tools Editor" that is part of the Web Tools Plattform in my own RCP-Application. I think i have got some understanding on the RCP plattform by now, but I still have no clue how to access the functionality of the pagedesigner (org.eclipse.jst.pagedesigner) after adding it as a dependency to my project. Has anyone some experience in adding components of the web tools plattform into an RCP-Application and can give me a hint or something?
There's a difficulty with these sorts of requests (I am, myself, trying to include this or that feature that I saw in the Eclipse IDE, every so often).
The trick is to try and identify the component you want to bring in, and then try and pull it into your project, without bringing in too many dependencies.
The first step used to be quite hard, but since 3.4 it is a matter of using the Plug-In Spy - hold down Alt-Shift-F1 on whilst your desired component is in focus should give you a tooltip showing you the class, the bundle, etc etc.
The second step is altogether more tricky and is where I usuaully fail to get any results:
if you are lucky then you can just include the bundle in the launch configuration/.product of your app. Once you hit Add Required Bundles, you are not left with 3000 bundles (i.e. your RCP is now Eclipse).
usually, this is not the case, because the Eclipse team haven't refactored the bit of code you're interested in out into an RCP safe bundle. If so, then you're going to have to do that yourself.
Again, if you are lucky then that will mean moving some classes out of the eclipse bundle into your own, including internal classes, and that will be the end of it - i.e. the dependencies of your desired functionality are all within the bundle.
If you're unlucky, then you need to isolate/reimplement the bit of functionality that is required, and change your version of the copied code.
It is hard laborious, and pretty difficult to upgrade. I realise that none of this is what you want to hear.