I have created my own custom toolchain plugin for CDT, and it works pretty well. However there is one piece that I cannt figure out.
Goal
Create a Tool which calls a JAVA class, instead of sending a command line argument.
At first I mulled over the 'CustomBuildStep' option for the Tool plugin element, but that is not the solution. How can you do this?
Hello World Request
Here's a simple one - At the completion of the CDT-Managed Build (e.g. the make call completes), I would like to pop a message box that says 'Hooray!'.
Current Workaround
Currently I end up just doing
java -cp "some_obtuse_path_into_plugins_dir" MyClass.doPopup
This is a gnarly console output, and a total hack in my opinion.
Thoughts?
Here is a useful contextual answer (that doesn't answer my question, but may point to 'sorry, can't do that):
Stack Overflow: Eclipse-CDT: Whats the best way to add a custom build step?
Have you considered creating a new Nature for your project: http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2FresAdv_natures.htm ? Then you can define your own builder to call the particular code you want.
I don't know how this would fit in your workflow, but it might a solution.
Related
I am looking to instrument a near-production application to simply print the stack trace when a variable is modified. I don't want to halt-thread or halt-VM.
What is a best and least complex approach?
Do I need to write my own plugin to handle 'DebugElement'?
Do I need to write a custom Debug Adapter?
Are there any examples out there? I know about EclipseCon2005_Tutorial21-v2 (Darin Wright, Bjorn Freeman-Benson) example for an Eclipse debug plugin contains deprecated code (e.g., "IPluginDescriptor").
I'm trying to follow Vogella's tutorial but some things are not clear enough.
Ah, just call a method from the conditional expression. It can do what is needed, and then "return false;" so that the VM is not suspended.
We use gradle as our build tool and use the idea plugin to be able to generate the project/module files. The process for a new developer on the project would look like this:
pull from source control.
run 'gradle idea'.
open idea and be able to develop without any further setup.
This all works nicely, but generally only gets exercised when a new developer joins or someone gets a new machine. I would really like to automate the testing of this more frequently in the same way we automate our unit/integration tests as part of our continuous integration process.
Does anyone know if this is possible and if there is any libraries for doing this kind of thing?
You can also substitue idea for eclipse as we have a similar process for those that prefer using eclipse.
The second step (with or without step one) is easy to smoke test (just execute the task as part of a CI build), the third one less so. However, if you are following best practices and regenerate IDEA files rather than committing them to source control, developers will likely perform both steps more or less regularly (e.g. every time a dependency changes).
As Peter noted, the real challenge is step #3. The first 2 ones are solved by your SCM plugin and gradle task. You could try automating the last task by doing something like this
identify the proper command line option, on your platform, that opens a specified intellij project from the command line
find a simple good enough scenario that could validate that the generated project is working as it should. E.g. make a clean then build. Make sure you can reproduce these steps using keyboard shortcuts only. Validation could be made by validating either produced artifacts or test result reports, etc
use an external library, like Robot, to program the starting of intellij and the running of your keyboards. Here's a simple example with Robot. Use a dynamic language with inbuilt console instead of pure Java for that, it will speed your scripting a lot...
Another idea would be to include a daemon plugin in intellij to pass back the commands from external CLI. Otherwise take contact with the intellij team, they may have something to ease your work here.
Notes:
beware of false negatives: any failure could be caused by external issues, like project instability. Try to make sure you only build from a validated working project...
beware of false positives: any assumption / unchecked result code could hide issues. Make sure you clean properly the workspace, installation, to have a repeatable state and standard scenario matching first use.
Final thoughts: while interesting from a theoretical angle, this automation exercise may not bring all the required results, i.e. the validation of the platform. Still it's an interesting learning experience and could serve as a material for a nice short talk, especially if you find out interesting stuff. Make it a beer challenger with your team when you have a few idle hours to try to see who can implement the fastest a working solution ;) Good luck!
I was hoping to find a way to automatically generate some code based on existing code.
The actual functionality would be very similar to javadoc or in this case IDLdoc or to automatic get/set functions.
I want to create some generic code based on some already listed parameters.
How do I accomplish this within eclipse?
I think an example would be best, so here is what I would like to accomplish:
keyword1: stuffIdontCareAbout, $;comments
keyword2: otherStuffIdontCareAbout, $;more comments
keyword3: lastStuffIdontCareAbout $
What do I need to do in eclipse so that I can have eclipse quickly parse the above block and output the following for another part of the code?
KEYWORD1=inp_keyword1, KEYWORD2=inp_keyword2, KEYWORD3=inp_keyword3
Thanks
My usual knee-jerk response is to suggest that you use JET as that what it's designed for.
For this specific case, however, you might be better off just writing a simple popup action (use the new plugin project with the popup action template) that parses the properties file (looks simple enough to do in Java) and writes out the target code to another file, the console or, if you're clever, back into an existing file in the right place.
Once you have the plugin generated for you with the template, the rest should be simple Java.
I am working on writing an IDE for Scala and need some help. I would like to implement coding assistance so that I could present a list of options when a user presses a period (".") or a space (" "). e.g. if projects is a List, as soon as user types "projects." or "projects ", I would like to show all methods of scala.List that he could use (regular IDE stuff). I know that scala.tools.nsc.interactive package provides this capability, but I am unable to figure out how to do it. Besides, it seems that the interactive package would use REPL and would be slow for this purpose. Is that a fair assumption, and if yes, are there any alternatives?
Also, is there a way I could get a call reference tree for a literal/ method (where all is the method referred to in a code base) ?
Thanks and Best regards
Aishwarya
Well, your best bet is going through the same set of links I provided in answer to this question, even though the questions are different.
Yes, the presentation compiler under scala.tools.nsc.interactive is where the reusable functionality would be.
The presentation compiler is used by Eclipse and ENSIME. May be ENSIME itself which in addition to providing emacs support also provides a server as a backend for an editor would be a good avenue.
The presentation compiler is not slow. It was designed from the ground up to provide good performance for Eclipse and it has largely delivered on this goal.
For some of the presentation compiler capabilities, see scala.tools.nsc.interactive.CompilerControl.
For another project using ENSIME, look at Daniel Spiewak's plugin for jEdit.
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.