Activate DummySourceGeneratingCompiler in test plugin for test purposes


i am writing a custom language plugin and still try to figure out how to implement and activate a compiler for my language.

To get familiar with the intellij api I would like to do some hello world stuff like activating the DummySourceGeneratingCompiler for my empty plugin.

I registered the DummySourceGeneratingCompiler in the plugin.xml and created a module named generated in my project, but nothing happens.

    <extensions defaultExtensionNs="com.intellij">
        <compiler implementation="com.intellij.compiler.impl.javaCompiler.DummySourceGeneratingCompiler"/>

when i point the debugger to CompilerManagerImpl the myCompilers variable holds the DummySourceGeneratingCompiler compiler. I set a breakpoint in every single method, but the executing doesnt stop in the DummyCompiler...

What do I have to do to get the DummySourceGeneratingCompiler or a random custom compiler to work?



All this API is considered deprecated, and it's used only when Settings | Compiler | Use external build is turned off. It's recommended to implement JPS-based compilation API instead. The entry point for the new API is org.jetbrains.jps.incremental.BuilderService.


what does JPS mean?

Is there any official documentation on the topic?
for example:

  • what is going on in the packages and org.jetbrains.jps.incremental?
  • what is the difference between ModuleLevelBuilder and TargetBuilder?
  • ...

> what does JPS mean?

This is our new build system implementation ("external build")

> Is there any official documentation on the topic?

Not so much yet. For now this is "work in progress". We hope this is somehow compensated by availability of sources. You can also use existing implementations of the API as an examples of how builders can be implemented.

> what is the difference between ModuleLevelBuilder and TargetBuilder?

The new build system uses the notion of BuildTarget - an abstraction  describing a discrete piece of work that must be done during build.  BuildTargets may depend on each other and according to these  dependencies the build engine defines the order in which targets are  processed. This dependency graph is also a basis used for parallel  execution of build tasks. There are some predefined types of build  targets that reflect IDEA's module structure. The main target here is  ModuleBuildTarget. Every plugin can register its own build targets and  builders that will process those targets.

There are two possibilities here, depending on what is more convenient  to you
1. Implement ModuleLevelBuilder interface. This is a dedicated builder  that processes exclusively ModuleBuildTarget. Each ModuleBuildTarget  reflects a cycle of modules from IDEA's project model. Dependencies  between ModuleBuildTargets are reflecting dependencies between modules  in IDEA project. There can be several ModuleLevelBuilder instances  registered in the build system. All of them will be called for each  ModuleBuildTarget in the sequence that is defined in the BuilderCategory  enum.
So the BuilderCategory that you choose for your ModuleLevelBuilder will  determine the order it is called for every ModuleBuildtarget. The  sequence in which builders are called within the same category is  undefined. For example, you may choose  BuilderCategory.CLASS_POST_PROCESSOR, and the build system will call  your builder for every target after all java sources are generated,  compiled and compiled classes instrumented.

2. Implement your own BuildTarget and TargetBuilder that will process  your target. This is the most flexible approach, but it is much more  work. However, there are some predefined abstract classes that make life  easier if you your BuildTarget is logically associated with a IDEA  module. Just subclass your target from ModuleBasedTarget and this target  will be automatically associated (grouped) with ModuleBuildTarget. The  method ModuleBasedTarget.isCompiledBeforeModuleLevelBuilders() controls  whether your target must be processed before of after the  ModuleBuildTarget reflecting the module your target is associated with.
If you implement your own BuildTarget, you control the sequence of  processing by specifying build targets your target depends on.

Please do not hesitate to email me directly, I and my colleagues will be glad to assist you in porting your compiler plugin to a new API.

Best regards,


Thanks for the great explanation, Eugene. However I can't see that Confluence page you linked to, it's not visible to external people, I guess. Could you make it accessible?


hi eugene,

even after signing up i cant see the content from the confluence link you mentioned. is it internal only?



Sorry, it was. But now, as Dmitry made it public, you should be able to acecss it. We'll be adding more information there.


Please sign in to leave a comment.