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.
Related
I'm trying to get a better picture of what happens behind the scenes in Android Studio when building an Android application. I've been reading up on Gradle, but one thing I cannot figure out is how to see the respective CLI command and arguments that is being invoked by Gradle. It seems to be abstracted and not logged to the Gradle Console or Event Log.
The closest I've gotten to seeing what's going on inside Gradle is the AOSP code.
2.2.2 Source:
https://android.googlesource.com/platform/tools/base/+/gradle_2.2.2/build-system/gradle-core/src/main/java/com/android/build/gradle/tasks
Goals
I want to be able to see the respective CLI command that is generated by the Gradle tasks inside Android Studio.
Use Case Example
I want to view the Legacy Android Build Process in depth. This includes going through the following:
Source Code / Library Code -> javac -> Java bytecode (.class) -> proguard -> minimized bytecode (.class) -> dex -> DEX bytecode (.dex)
For example I would want to see the respective javac command invoked by AndroidJavaCompile. https://android.googlesource.com/platform/tools/base/+/gradle_2.2.2/build-system/gradle-core/src/main/java/com/android/build/gradle/tasks/factory/AndroidJavaCompile.java
I fear that the only way to do this is to look directly through source code or even build directly from source.
Due Diligence
I've done quite a bit of searching on Google, Android blogs, Google I/O talks, Android books, and much more. I haven't been able to find a straight-forward answer.
That's not possible. Simply, because most of the Gradle tasks do not invoke CLI commands.
Every Gradle build file is a piece of Groovy code that gets executed in a JVM along with the Gradle API (written in Java). Therefor, you can implement any task or configuration functionality directly in any JVM language, from which most plugins make use of instead of executing command line tools. Nevertheless, this is possible by using or extending the Exec task.
The compilation step is handled by a AndroidJavaCompile task, which extends the common JavaCompile Gradle task by some version checks and the Instant Run feature. However, you don't know how Gradle actually compiles the .java files. In the internal source files for the JavaCompile task of the Gradle API, there seem to be various implementations (DaemonJavaCompiler, JdkJavaCompiler and even CommandLineJavaCompiler). Since you can specify CompilerOptions with your task, Gradle seems to choose the real compiler based on these options. Please note, that even if a CommandLineJavaCompiler exists, it is also possible (and highly likely), that Gradle prefers to use the javax.tools package and its JavaCompiler implementation to compile the source files instead of invoking a command line tool.
I also took a look on the ProGuard step in your example build process: ProGuard can be used as command line tool, where you can specify arguments to define how it'll work. But ProGuard also provides a Gradle task (ProGuardTask), that executes without invoking ProGuard from command line. The ProGuard Java code will be executed in the Gradle JVM.
As you can see, even if each Gradle task may be replaced by one (or multiple) CLI command(s), Gradle does not execute these commands. Instead, the functionality is called directly in the Gradle JVM. If you want to get a better insight, you can increase the Gradle log level. Good implementations of Gradle tasks should provide all necessary information in logs.
So I am trying to use omp4j with the eclipse IDE. The problem is, that omp4j needs to replace the javac command to work (see http://www.omp4j.org/download). And I don't know how I can accomplish that in eclipse other than renaming the omp4j.jar to javac.jar and replacing my JDKs javac.jar and that seems like a wrong solution.
omp4j is a preprocessor. If omp4j is called without --no-compile, the preprocessed Java source code will be automatically compiled via javac, so omp4j can be used as a replacement for javac.
Eclipse has its own incremental Java compiler which can not be replaced. This means, in Eclipse omp4j has to be used with the argument --no-compile as preprocessor only. The processor can be executed
in an Ant, Maven, Gradle, etc. build script or
via an Ant build script as project builder on save.
To have the full Java support for the sources before preprocessing, the OMP4J_THREAD_NUM and OMP4J_NUM_THREADS constants can be faked via a static import statement with the * wildcard and a JAR that exists in two different versions, one with these face constants for the sources to edit and one with other constants for the generated sources which are not intended to be edited.
Probably it will be best to start with a Java project for each, before and after preprocessing.
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 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.