I have two projects. One of them is projectA a processor for annotations. Second one, projectB use projectA as dependency. Now this processor is add toJson method to exists class before final compile. Everything works normally. When I compile projectB my projectA is run and modify exists source file and add toJson method. Also intellij auto detect this processor and automatically configure my custom processor to the processor path. But editor give error Cannot resolve method 'toJson' in 'CacheData'. How I can solve this problem?
The below image is my intellij configuration. As you see IDEA automatically detect my processor from my pom.xml but editor does not recognize the generated code
I use IntelliJ IDEA 2021.3 (Ultimate Edition), maven-3.8.1, jdk-1.8 for processor(projectA) and jdk-11 for projectB
Finally I solved my problem. It seems that current version of Intellij only supported auto generated class. But if you modify exist file with you annotation processor Intellij editor can not recognize your changes and shows as errors. Thank you very much to #mplushnikov for his lombok-intellij-plugin. I just create my own plugin for IntellIJ and add dependence. After doing this you need to override some entrance classes and add your own annotation and its processor handler and extends it from AbstractClassProcessor
Let me share some example so if anyone who has this problem can use it.
IntellIJ Plugin tutorial for beginner
The below code snippets are from my plugin.xml. First you need add some dependencies to your plugin
<depends>com.intellij.modules.lang</depends>
<depends>com.intellij.modules.platform</depends>
<depends>com.intellij.modules.java</depends>
<depends>Lombook Plugin</depends> <!-- this is the lombok-intellij-plugin-->
Second step is adding required extensions to your plugin as below
<extensions defaultExtensionNs="com.intellij">
<!-- Add your own custom processor. because lombok plugin default search only lombok package and own annotations -->
<lang.psiAugmentProvider implementation="your_package.AugmentProviderImpl"/>
<!-- if you packaged your classes other than lombok -->
<codeInsight.externalLibraryResolver implementation="your_package.ExternalLibraryImpl"/>
<implicitUsageProvider implementation="your_package. ImplicitUsageProviderImpl"/>
<!-- Add your custom annotation processor handler and extend it from AbstractClassProcessor -->
<applicationService serviceImplementation="your_package.CustomAnnotationProcessor"/>
</extensions>
Thats it. Follow these steps, build your plugin and install it. After restart your class's methods which is generated by your own annotation will be recognized by intellij.
Implementing the class is not hard. Just look the lombok-intellij-plugin source code and copy the required file and just modified it.
Related
I have an IntelliJ plugin, which was created from the github-template, that cannot resolve the class com.intellij.psi.PsiJavaFile.
Has anyone else run into this and figured out what needs to be configured?
I'm new to IntelliJ plugin development. I followed the instructions detailed at https://plugins.jetbrains.com/docs/intellij/github-template.html to create a plugin.
I imported the generated plugin into IntelliJ and everything seems OK. No compile warnings, etc..., but when I try to use the class com.intellij.psi.PsiJavaFile, IntelliJ says it cannot resolve the class.
I imagine I'm missing a configuration somewhere that tells IntelliJ which libraries to import, but I'm not finding it in the documentation.
You're probably missing the dependency on the Java intellij plugin, which is not enabled by default as you won't need it for every custom plugin.
Add com.intellij.java to the platformPlugins section of the gradle.properties file:
# Plugin Dependencies -> https://plugins.jetbrains.com/docs/intellij/plugin-dependencies.html
# Example: platformPlugins = com.intellij.java, com.jetbrains.php:203.4449.22
platformPlugins = com.intellij.java
To address that the IDE cannot resolve PsiJavaClass specifically, I don't think it exists. Are you looking for PsiJavaFile or PsiClass?
I have a module in a project that has a need for post-time weaving.
I have configured my compiler to be Ajc and I have added AspectJ Facet to my module, but I am unable to enable the "Post-compile weave mode" as the checkbox is greyed out.
Anyone knows what am I missing there?
Normally I do my AspectJ stuff by setting up Maven projects which just work in Eclipse and IntelliJ IDEA. In order to help you I just tried setting up a simple Java + AspectJ project from scratch in IDEA. This is what I did (I also had to play around a bit):
Switch to Ajc as project compiler, set path to aspectjtools library and activate toggle for delegating to Javac for post-compile weaving and non-AspectJ projects
Add aspectjrt library to project, either as a path to a JAR or using Maven coordinates
Add aspectjrt library as dependency in all AspectJ-related modules and add AspectJ facet
Edit AspectJ facet, activate post-compile weaving
If you have your aspects in a separate module, please also make sure to add that module as a dependency to the Java module and also add it to the aspect path.
Please also note that if optionally you wish to use Javac for compiling the aspect module, all aspects have to be in #AspectJ syntax, not in native syntax, otherwise you cannot delegate to Javac but have to use Ajc for the aspect module too. Either way, both modules need to have an AspectJ facet.
Update after the answer was already accepted:
Some IntelliJ IDEA sources for reference:
https://www.jetbrains.com/help/idea/2020.3/aspectj.html
https://www.jetbrains.com/help/idea/2020.3/using-the-aspectj-ajc-compiler.html
https://www.jetbrains.com/help/idea/2020.3/aspectj-facet.html
https://www.jetbrains.com/help/idea/2020.3/java-compiler.html#ajc
The official Kotlin documentation states:
Add kotlin.code.style=official property to the gradle.properties file at the project root.
I'm trying to understand how kotlin-gradle-plugin handles this property.
Which gradle task uses it?
When running gradle build, I don't see my code being reformatted, even if I format my code badly on purpose.
I went through the Github source code of the plugin but couldn't properly get to understand it.
Thanks for your help.
Kotlin Gradle plugin doesn't use this property, as it's not responsible for reformatting the code. Instead, this property is used by Gradle importer of Kotlin plugin for IntelliJ IDEA.
This facade provides access to Gradle properties defined for the project:
https://github.com/JetBrains/kotlin/blob/v1.4.10/idea/idea-gradle/src/org/jetbrains/kotlin/idea/configuration/GradlePropertiesFileFacade.kt
It checks local.properties first in case user wants to override this value in the local configuration (this file is usually added to .gitignore for VCS to skip it during it's operations), then in usual gradle.properties.
Then the property gets consumed to configure the project here:
https://github.com/JetBrains/kotlin/blob/v1.4.10/idea/idea-gradle/src/org/jetbrains/kotlin/idea/configuration/KotlinGradleSourceSetDataService.kt#L158-L159
Same thing goes for Maven-based projects. These are the only two places the property is used throughout Kotlin repository apart from tests right now.
When I make one plugin extend another it normally inherits the properties from the parent. Sometimes it doesn't work though.
When the plugin is loaded up, the properties from the parent are all null
What might I be doing wrong? I package my project as a maven-plugin and it builds ok.
I've seen this myself and it drove me mad until I debugged the Plexus internals. I'm guessing the properties are not inherited when the parent is in another plugin?
If that is the case, the explanation below will help. If it is not, it might be a typo in the Javadoc annotations. Maven will skip any tags it doesn't recognise without warning.
If it's neither of these, can you post a little more detail? perhaps an example of the failing Mojo?
If the parent is in another project, here's the reason why you're having problems.
Maven plugins use Javadoc annotations to define the dependencies, goal declarations, and other configurations (Maven 2.1 introduced proper Java annotations but hardly any plugins use them yet). Once the plugin has been installed/deployed the Javadoc is lost, so any plugin that extends a plugin in another jar won't have access to the plexus-defined properties in the parent.
There is a workaround though. The plugin metadata is output to META-INF/maven/plugin.xml. There is a third-party plugin that reads the information from the parent Mojo's plugin.xml and merges the local plugin metadata with it. Your plugin should then work as normal.
I currently have an existing plugin, which references a class from a required plugin. I have replaced this code with a reference to a class which is part of my fragment.
I am facing two issues.
If I import my fragment as a jar file, I am not able to see the changes I have made as the plugin running as an eclipse application results in a ClassNotFoundException
To overcome this, I link an additional source (of fragment) to the existing plugin project. However, the link uses an absolute path, and makes it unfit for deployment.
I want to be able to package the plugin with the code modification and be able to "depend" on my fragment code. Is there a way I can add my fragment as a dependency?
For example:
Plugin Project I am changing : org.eclipse.*.editor
it depends on org.eclipse.*.edit
I have a fragment mydomain.*.edit which has org.eclipse.*.edit as host plugin
I want org.eclipse.*.editor to pick up mydomain.*.edit
instead of org.eclipse.*.edit
ps: I have also tried packaging the jar file for the mydomain.*.edit in the plugins directory and try and pick it up from there, it doesnt show up on the list when I click add required plugins on the dependency tab on the plugin.xml file of the org.eclipse.*.editor
Please let me know if I am not clear enough, I will try and rephrase it.
Thanks in advance!
If I understand correctly what you want to do, I don't think that it's possible. You will have to try some other way.
Plugins have dependencies on other plugins. Fragments don't exist as separate runtime entities, but only as extensions of a plugin. So your plugin can only refer to the 'editor' plugin.
Classes provided by a fragment can't (and shouldn't) be accessed directly. They can be returned by the original plugin (A) if they are implementing an executable extension provided by plugin A.
If you refer to the fragment's code from another plugin (B), the classes will be loaded by plugin B's classloader and be different from the ones that are loaded by plugin A.
What is the purpose of your fragment? Do you want to get access to internal code in plugin A? Do you want to extend an eclipse editor?
If you want to extend functionality that the original plugin is not exposing as extensible, I think the only way is to write a plugin, extend the editor class from the original plugin, register it alongside the original one and use it instead.
[Edit] Maybe this link will explain better: Eclipse FAQ
Hope this helps,
Vlad
Thanks Vlad,
Your explanation was very helpful. Unlike the extension based architecture that is truly intended for fragments, I had to modify a certain component in the editor that was not exposed as part of the extension. This modification referred to an external project I created as an fragment but could have been a normal java project packaged a jar file that I could place in the classpath of the editor.
I was able to resolve the dependency issues by placing the jar file in class path, however when I export the plugins and related plugins as jar files and place it in the dropin directory, it does not install correctly. (Nor does placing the jar files in the plugins directory)
The eclipse editor that I am trying to modify uses the EMF project. I have kept the EMF project in the workspace inorder to resolve dependencies of the editor. However when I replace the EMF jar files bundled with eclipse with the one in the workspace, the files that I want to edit are not correctly recognized.
Is there another way of doing this?