I am making plugin in Eclipse that would run selected method with specific parameters (right click on method in package explorer and choose "Check" runs selected method with specific parameters and shows results).
What would be the best way to run selected method without having to compile whole project and use reflection (as project might not be complete and might not even compile yet)? I will also have to use EMMA.
Take a look on JUnit plugin and create similar implementation. I believe that it provides almost what you need except the fact that it works with JUnit tests only.
Related
I run a custom compiler plugin with the -Xplugin:MyPlugin switch, which injects some extra methods into my classes. I set the additional command line parameters under
Settings -> Build, Execution, Deployment -> Compiler -> Java Compiler
Everything builds just fine, but in the IDEA editor every call of the generated methods is highlighted red, and also autocomplete does not work.
What else can I configure to make it recognize the generated methods?
You need to write a plugin for IntelliJ IDEA to make it aware of the methods you generate. On-the-fly code analysis in IntelliJ IDEA uses its own parser and reference resolution implementation; it does not use javac, and cannot be extended by writing javac plugins.
The main entry point for such a plugin is the PsiAugmentProvider class.
I'm using Eclipse and I wanted to create a system that automatically generates java source code every time I save the project. More precisely I want to search for some files in a directory, generate static attributes for each of them and generate some methods every time the project is updated/saved. I thought that a piece of code that could be auto-executed by Eclipse would be fine, but I don't know if it's even possible. How can I achieve this behaviour?
You can specify a program or Ant script to be run when a project needs building in the 'Builders' section of the Properties for a Project.
You can also write an Eclipse plugin 'Incremental Builder' using the 'org.eclipse.core.resources.builders' extension point. More information about this in the Eclipse help.
Eclipse has an extension point for cleanup and save actions that will be executed when you a save a file.
This requires implementing and installing a custom Eclipse plugin, so it's more intrusive than using a builder to run a script, but also more flexible, since you can use the JDT API to inspect the Java model of the given file.
I personally use :https://github.com/mystilleef/eclipse4-smartsave
Just from marketplace eclipse4-smartsave or as on page other solutions.
Plugin sometimes hangs, still it is great.
I've written a plugin that uses the org.eclipse.jdt.core.compilationParticipant extension to gather some compile information to be used elsewhere. I've tested in multiple versions of the Eclipse IDE and it works like a charm. My ultimate goal is to be able to use it in a headless production PDE build. I've added some logging to the bundle so I am aware when it starts up, when it shuts down, and when source compilation occurs. The problem is that these events never get caught in my headless build buy the participant. The headless PDE build is kicked off by starting the equinox launcher from an ant script that runs the antrunner executing the PDE build script. There are so many scopes of execution involved I'm unsure where to start looking. My first question is, is what I'm trying to do even possible? It didn't seem like the CompilationParticipant would only work in the UI, but I want to make sure before I go down the road of debugging this. Has anyone ever done this?
I tried to add a comment, but I'm too wordy so I will try to clarify here a bit. Unfortunately I can't do much to change the build system except to apply hooks like I am attempting. I did spend some time running through the ant scripts that PDE generates and see the it is calling the JDT compiler adapter which made me curious if the JDT compiler adapter could reference the compilation participant since it is running ant from the plugin and should have access to the framework, and it seemed to be the intent of the participant API to allow the hooking of the JDT compiler to do things like the implementation of the APT processor and other DSL implementations. That was my read on the intent of the participants, and assume they would be available in a headless build since the APT processor works, but since I can't find a really good tutorial I'm kind of putting things together piecemeal and I'm guessing I'm missing something, or at least I hope so..
It is true that PDE is generating ant scripts and calling the javac task, but it is also setting the build.compiler property to use the JDT compiler and therefore I would assume have access to the OSGi framework. Here is a snippet from one of the generated build files to show what I am talking about:
<compilerarg line="-log '${temp.folder}/pde.example3.jar.bin${logExtension}'" compiler="org.eclipse.jdt.core.JDTCompilerAdapter"/>
Debugging org.eclipse.jdt.internal.core.JavaModelManager reveals that the JDT compiler is in fact being used but getRegisteredParticipants is not being called for some reason, startup() is however being called, so the question it why does it not try to register participants.
After spending hours in the debugger attaching to the various VMs that spawn during my build process I was able to determine the flow through a PDE build. I don't believe that CompilationParticipants come in to play, in fact I don't even think the JavaBuilder is called. It looks like the execution path is something like the following:
Ant spawns my VM which starts the Equinox Launcher which starts up the OSGi framework and instantiates the AntRunner application, this in turn starts ant from the Elcipse Ant plugin that runs the build.xml file from the PDE plugin, the Build.xml file generates all the ant scripting used to generate the eclipse plugins which includes setting the build.compiler to the JDTCompilerAdapter which wraps the Eclipse Java Compiler ( originally based on Visual Age for Java ). The JDTCompilerAdapter does some setup and instantiates the org.eclipse.jdt.internal.compiler.batch.Main class which does the real compilation, and also instantiates the org.eclipse.jdt.internal.compiler.apt.dispatch.BatchAnnotationProcessorManager class to handle annotation processing. Nowhere in this path of execution are participants notified, and the JDTCompilerAdapter seems to be specifically designed to be able to be used outside the OSGi environment in ant. so it looks like CompilationParticipants will not give me what I need in a headless PDE build using the antrunner..
AFAIK PDE build is "just" a fancy way of generating a lot of Ant-scripts, and I belive it just uses the javac target to compile files. You can check that after the PDE build has run, by going into your source folders, find the Ant-script, and check.
If what you do is important for the build, I would recommend that you check out Buckminster. It is a build tool designed of OSGi applications. It is special in the sense, that it actually builds in an Eclipse workspace, so it uses the same builders and stuff like CompilationParticipants as you do during development, assuming you have installed the plugins in the headless build-application.
Well after tons of debugging, reading docs, and stepping though the PDE sources it seems like this can NOT be done. It seems in a headless build the execution of the JDTCompilerAdapter is designed to work outside of OSGi and does not have access to the framework it is simply called from the javac task and does NOT involve the JavaBuilder and therefore does not call any participants.
I have set up eclipse to work just as I want with my java web app using the following instructions : https://stackoverflow.com/a/6189031/106261.
Is it also possible to get unit tests to be run as part of the auto build, without running a maven install (or test). So I make a change to a class, the tests get run, and if a fail occurs I get a some sort of indicator. Without needing to manually run maven test.
There are several ways to achieve this, all with their own limitations:
You could set up a CI server which builds your project every time you commit a new version. Very reliable but not really "real time"
You can add your own builder to the list of builders (project properties -> Builders), for example an Ant builder which runs "ant test" or something. This builder gets invoked every time you save. Every time. That means Eclipse will become a total slug unless running your unit tests takes less than a few milliseconds.
You can use one of the plugins mentioned here: Is it possible to run incremental/automated JUnit testing in Eclipse?
I'm new to Android and wanted to use AspectJ with it.
I had searched couple articles online and follow the instruction to have it working:
http://blog.punegtug.org/2010/11/adding-aspect-to-android.html
But I wanted to know whether if it's possible to separate the aspects away from the Android project. In the tutorial link above, it has both the Android App and the aspects inside the same project, but in many cases, we wanted to leave the Android Project untouched in its isolating spaces.
Let said I have AndroidProject in my Eclipse workspace, I would like to create a separate projects for my aspects called something like "AndroidAspectProject" which only contains the aspects for it.
I'm not sure whether this would work because it seems we need to let AspectJ compiler inject point cuts and advices to the .class files before creating the .dex files. In this sense, I may not able to do it in a separate project.
Does anyone try with this?
Another related question would be:
Is it possible to have Ant build the AndroidProject with AND without aspects on it? Can this be done outside of Eclipse?
I'm looking for a way to build different flavours as I'm only injecting pointcuts into the AndroidProject on dev/debug build, but will leave it untouched on release build.
Whether or not to do the compile-time aspects is a matter of whether or not you run the aspectj ant tasks. Have separate targets or properties for the AOP- and non-AOP-builds and either build one based on a target name or property, or build them both and change the artifact name.
IIRC Eclipse allows you to specify an Ant target to run on a build.
Inside of Eclipse, this is simple. Just add AndroidAspectProject to the aspect path of AndroidProject.
Inside of ant, there are several ways of doing this. But, the simplest is to define 2 targets. One that uses iajc and the other that uses javac to compile your sources. You then need to use a little ant magic switch between targets depending on whether you are compiling for dev or for production.