I work on a project that uses a microservice architecture.
We externalized the checkstyle configuration in a separated library, we use IntelliJ and the checkstyle plug in.
The checkstyle plug in refers to a static xml file (example of configuration : IntelliJ IDEA code format from checkstyle configuration ) and the configuration of the plug in is automatically is the same for all projects.
When we change the version of our checkstyle configuration, we do not want to adapt the code of all microservices at once and so, at the same time, some services will use the old checkstyle config and some others will use the new one until we upgrade the version.
So, I want to make the checkstyle IntelliJ plug in to refer in every project to the file {project directory}/target/checkstyle-checker.xml and not an unique checkstyle.xml
Does it exist a way to achieve this ? Or at least to make the configuration of the plug in different for all projects ?
Thank you for reading !
Related
I've been trying to make IntelliJ treat *.yml files the same way it treats application.yml or bootstrap.yml.
What I mean is, that I have auto completion and syntax warnings when I edit for example a application.yml file, but none of these features when I edit a file called microservices-monitor-prod.yml which is located in a config server resource folder.
Is there any way to have the same IntelliJ features when editing such files ?
IntelliJ IDEA 2017.2 (currently available as RC) allows to choose custom naming schemes for Spring Boot configuration files (https://youtrack.jetbrains.com/issue/IDEA-133445)
A little intro:
I work on a project with legacy codebase witch uses internal xml based descriptors with specific file extensions (about may be 10 extensions).
Let it be *.desc, *.check etc.
To have code highlighting for such a files I can configure Idea to consider these types of files as XML.
It's available through:
Preferences / Editor / File types
And then add all custom extensions to 'Recognized file types': 'XML'
Our project uses gradle as build tool
and my question is:
Is it possible to make same configuration via dsl of gadle 'idea' plugin?
The short answer is: No.
One could create a custom Gradle task that will modify IDE file type preferences XML file in the config directory. While it's possible to run such task automatically on the project refresh in IntelliJ IDEA, it will most likely not work since you can't modify IDE configuration when IDE is running (the changes will be reverted). So, you will have to run it from the command line, outside of IntelliJ IDEA when IDE is not running.
It's probably not what you want, but if documented, can be used by the team as the manual step to make this configuration change easier.
Using gradle idea is not recommended anyway.
A better way might be to provide your own IDE plug-in that will associate these file extensions with XML file type and instruct the team to install this plug-in.
I am developing an idea plugin, and it is an intellij idea project.
I want to use gradle to manage the dependency.
How to config?
There is now a Gradle plugin for building IntelliJ Platform Plugins. In order to use it, you will need to add the following snippet to your build.gradle file.
plugins {
id "org.jetbrains.intellij" version "0.0.31"
}
apply plugin: 'org.jetbrains.intellij'
For more information, please see this guide to help you get started.
Ok, there are multiple ways to create an IntelliJ project, "templates" if you like, and unfortunately you can only pick one of them (IntelliJ plugin or gradle).
Thankfully, it's easy to configure a project for gradle in IntelliJ.
First, create a new project from the IntelliJ Platform Plugin template. You don't need to choose any Additional Libraries and Frameworks. This will give you a project structure including META-INF/plugin.xml and the Project SDK should be something like IDEA IU-129.451.
From here, simply create a new file named build.gradle at the top level of your project, including for example this line:
apply plugin: 'java'
Now, close the project. You can now use File -> Import Project..., choose the build.gradle file that you just created, and import the project. Accept the defaults for importing and hit OK.
The project is now opened with both gradle and intellij plugin enabled!
Notice that the source root src has disappeared and you will need to right click on src in the Project pane and select Mark Directory As -> Source Root.
To prepare the plugin for deployment, there is still the menu option in the Build menu for that - if you want to automate that part via gradle, good luck and please let us know how it's done ;)
In our project we are using jaxb2-maven-plugin to generate Java source code from XML Schema, which causes that our Maven module requires additional source code directory (in our case target/generated/main/java). Up to date I've been using Eclipse and maven-eclipse-plugin to import all the projects into Eclipse workspace. The plugin is (somehow) able to add the directory with generated source code automatically to Eclipse' .classpath file.
Recently I try to switch to (play with?) IntelliJ IDEA 9 (so I am a newbie in this environment) and I've noticed that additional source directory is not added during IDEA's importing process...
Is there any way I can configure IDEA/Maven to make importing directory with generated source code automatically?
The convention with Maven is to generate code in target/generated-sources/<tool>, for example target/generated-sources/jaxb2
Follow this convention and IDEA will add the folder as source folder (see IDEA-53198).
Generated code, using jaxb2-maven-plugin, was missing for me in Intellij 2017.1 whereas Eclipse Neon created it.
Fixed it from context menu of module by selecting 'Maven -> Generate Sources and Update Folders'.
Try with maven-jaxb2-plugin. If it does not work then it's IDEA problem.
In Maven you can add new source roots per configuration. Maven plugins can do this programmatically. This is for sure the case with maven-jaxb2-plugin. Then, if IDEA does not recognize it, then it's a problem on that side.
You can use the Maven Build Helper Plugin. It is located at http://www.mojohaus.org/build-helper-maven-plugin/
It allows to configure additional source roots. And the maven integration of IntelliJ will add the new source root. We are using this feature in quite a few builds and it works just fine. Tested with vers. 13 of IntelliJ IDEA.
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?