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?
Related
Presently having an annoying time getting a jar added to the external library for the project, then in turn not disappear when syncing and the imports working. Adding I figured out and answered in another question. The issue is to keep persistent and accessible to a jar I create within the project for import.
I am not sure if I am missing a step or forgot to set something. I am using a modified gradle (forgegradle) to create the project. Have not found a solution with the documentation, or any for IntelliJ yet. I am generally new with IntelliJ, choosing to use it instead eclipse which I have previously used.
The goal is a to create an add-on for a mod to another jar. The main jar already in the external library from the start, now attempting to add the mod to it. I could modify the mod, but it is not my code, so rather not simply modify it directly and repackage it.
a jar added to the external library for the project, then in turn not disappear when syncing and the imports working
If you are using an external build tool / system that syncs with IntelliJ it is recommended to use that build tool / system to add dependencies.
IntelliJ will always take a backseat, and treat the build tooling / system as the source of truth for the project model as best it can.
You mention you are using gradle, I would recommend adding the dependency as a managed dependency that is, let gradle download it from a repository, and resolve the dependency/library itself.
If you can not do this, and you can't host a repository yourself, The next best recommendation I have, is creating a 'libs' folder inside the project, that contains jars that can't be found in repositories (They may be mods or plugins that were never published)
You can read up on how to add a library folder to gradle here: How to add local .jar file dependency to build.gradle file?
I am trying to add support for kotlin for one of the IDEA plugins.
So far, I found this page and understood that I need to work with kotlin PSI files, such as KtClass and others.
When I was setting up my project I added idea source files to sdk(by cloning this repo), to make it easier to debug + see documentation.
However it seems that these idea source files doesn't include kotlin source files, such as mentioned KtClass and others, which I use in my project. Currently I see only decompiled version of these files.
Is there any way to add them like with other IDEA source files?
Those source files belongs to the Kotlin plugin, which is not strictly a part of IntelliJ IDEA distribution. You need to add the Kotlin plugin source to the project as well as the IDEA source.
There're two modules needed:
https://github.com/JetBrains/kotlin/tree/master/idea
https://github.com/JetBrains/kotlin/tree/master/compiler/psi/src/org/jetbrains/kotlin
I need to turn Eclipse fragments into plug-ins. Haven't found any wizard to support this.
So I've created a plugin.xml and edited the MANIFEST.MF to look exactly like a plug-in project does. Still, Eclipse somehow detects it's not a plug-in: for example it asks for a Host-plugin.
Also checked .project file, nothing seems to indicate "fragmentness".
Why I need this:
Fragments were used for Unit-testing; but they're rather inconvenient: any modification in them triggers a chain of builds, and they block the exporting of individual plug-ins, unless their project is closed.
Solution
As Greg suggested it was the 'Fragment-Host:' option that did the trick. And as Rüdiger wrote; the project had to be closed/reopened for eclipse to acknowledge the change.
The fragment host is specified in the fragment's MANIFEST.MF:
Fragment-Host: host.plug.in
you will need to remove that.
However many fragments rely on code from their host plugin so it may not be possible to just convert the fragment.
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.
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.