I've been setting up the workspace for IntelliJ's plugin development. There is one issue that I'm not able to solve.
I have two plugins: A and B. The B plugin depends on A. The A plugin is provided as an install-ready zip package (I don't have the code and I don't want to add it to my project).
In the manual, I met this page. I added jars from the A plugin (extracted from the zip file) to the SDK that is use when running B plugin. Unfortunately, when the sandbox is being bootstrapped, I get the following error:
Problems found loading plugins:
Plugin "B" was not loaded: required plugin "A" not installed.
Disable B
Open plugin manager
Does it mean that plugins from the SDK are not installed automatically?
I tried to install the A plugin in the sandbox but then I got a casting exception - two different class loaders were used.
Of course, I have appropriate dependency configuration in the B.plugin.xml file:
<depends>A</depends>
My question is how should I provide the A plugin to be able to develop the B plugin? Is it possible to develop the B plugin without A's sources?
In the jars that I added to the SDK's classpath, there is a package that contains the plugin.xml file for the A plugin. This plugin is also not listed on the list of plugins.
I'm sure that both plugins are configured properly because there are no problems when I install both of them in a standalone IntelliJ instance. Additionally, I don't have any compilation errors.
After couple more hours of debugging. The A plugin is marked as not installed because in the PluginManagerCore:loadDescriptorsFromClassPath method there are no appropriate jars URLs provided. It seems that BootstrapClassLoaderUtil doesn't include all of the entries configured in the SDK.
I tried to set -Didea.additional.classpath property, but I got the class cast exception again.
Finally, I have found the solution.
The B plugin consists of other B submodules:
B.submodule-1
B.submodule-2
B.submodule-3
One of these submodules had dependencies to the A's submodule. Something like this:
B:
| B.plugin-submodule
| B.submodule-1
| A.submodule1
| A.submodule2
| B.submodule-2
| B.submodule-3
Based on the gradle setup, IntelliJ resolved all of the dependencies for all submodules. Initially, I removed Gradle dependencies and set the JDK only for the plugin submodule. It was required to do so for the others (submodule-1/2/3).
Related
In order to be able to use my Eclipse plugin "treezCore" also as a Java9 module I created a module-info.java in my src folder.
Furthermore, I moved the Plug-in Dependencies from the Classpath to the Modulepath. I can see a module "org.eclipse.swt.3.106.1.v20170926" in the plugin dependencies:
However, I am not able to reference that module in my module-info.java. I tried
require org.eclipse.swt.3.106.1.v20170926;
require org.eclipse.swt;
require swt;
None of those options worked. The jar file \plugins\org.eclipse.swt_3.106.1.v20170926-0519.jar that is used by Eclipse does not contain a module definition and
jar --file org.eclipse.swt_3.106.1.v20170926-0519.jar -d
says that the module descriptor can not be derived. Also see
Unable to derive module descriptor for auto generated module names in Java 9?
If I download a newer version of swt.jar from
http://download.eclipse.org/eclipse/downloads/drops4/R-4.7.1a-201710090410/download.php?dropFile=swt-4.7.1a-win32-win32-x86_64.zip
I get following output that looks promising:
swt automatic
requires java.base mandated
contains org.eclipse.swt
contains org.eclipse.swt.accessibility
contains org.eclipse.swt.awt
contains org.eclipse.swt.browser
contains org.eclipse.swt.custom
contains org.eclipse.swt.dnd
contains org.eclipse.swt.events
contains org.eclipse.swt.graphics
contains org.eclipse.swt.internal
contains org.eclipse.swt.internal.gdip
contains org.eclipse.swt.internal.image
contains org.eclipse.swt.internal.mozilla
contains org.eclipse.swt.internal.mozilla.init
contains org.eclipse.swt.internal.ole.win32
contains org.eclipse.swt.internal.opengl.win32
contains org.eclipse.swt.internal.webkit
contains org.eclipse.swt.internal.win32
contains org.eclipse.swt.layout
contains org.eclipse.swt.ole.win32
contains org.eclipse.swt.opengl
contains org.eclipse.swt.printing
contains org.eclipse.swt.program
contains org.eclipse.swt.widgets
I also depend on org.eclipse.jface and could not find a seperate download for it.
=> Do I really have to wait for a new release of Eclipse that uses new plugin versions including module definitions?
Or can I somehow reference the old version of swt from the plugins folder, even if it does not include a module definition? I looked for an easy way to define an alias or a fallback dependency e.g.
requires ../plugins/org.eclipse.swt_3.106.1.v20170926-0519.jar as 'org.eclipse.swt'
or
requires org.eclipse.swt fallback ../plugins/org.eclipse.swt_3.106.1.v20170926-0519.jar
but module-info.java does not seem to support such a syntax.
I have about 20 plugin dependencies and do not want to manually download each of them (if it would be possible) and include them as external jar file. Nor do I want to hack the individual Manifest/jar files in the Eclipse plugin folder. There are many jar files I would need to alter and an update of Eclipse would break that hack.
I am using Eclipse for RCP and RAP Developers, Version: Oxygen.1a Release (4.7.1a), Build id: 20171005-1200
Edit
When using Version: Photon Milestone 4 (4.8.0M4) Build id: 20171214-1849, the error in module-info.java vanishes when using
require org.eclipse.swt;
and having the Plug-in Dependencies in the Modulepath.
However, my imports do not work yet, see following image. If I move the Plug-in Dependencies from the Modulepath to the Classpath, the imports work but the error in module-info.java reappears.
I created a min example at
https://github.com/stefaneidelloth/Java9EclipsePluginExample/tree/master/MyPlugin
and I filed a bug report at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=529089
Related questions:
How to use 3rd party library in Java9 module?
Unable to derive module descriptor for auto generated module names in Java 9?
Force Eclipse (Helios) to use a newer version of SWT at application runtime
JFace libraries stand-alone download (not picked from Eclipse plug-ins)
New Keywords in Java 9
What you observe is tracked in bug 525660, which starts with the observation that all existing (OSGi) artifacts of Eclipse don't work as automatic modules, because Java 9 fails to derive a valid module name from jar filenames of the shape org.eclipse.swt_3.106.1.v20170926-0519.jar.
Since this was discovered too late to request improving the algorithm for automatic module name derivation, this can only be fixed by adding Automatic-Module-Name headers to the manifests of future releases.
This header is present starting from Photon M4 as can be seen in org.eclipse.swt_3.107.0.v20171205-0742.jar, containing:
Automatic-Module-Name: org.eclipse.swt
We have a java project with several modules. We use git for versioning and want the developers to be able to chose their own IDE. So we don't push .idea and .iml files with git. This means that developers in IntelliJ needs who clones from git needs to set up the project in IntelliJ as well. However we are having some issues with setting it up. In my own project it works fine and looks like:
Proejct Module (Is this a real module?)
⤷ Module A
⤷ src
⤷ main
⤷ java
⤷ Package 1
⤷ Package 2
⤷ test
⤷ Module B
Before we added packages to the project new developers could just pull from git and open Module P in IntelliJ, then go to project structure and import module from Module A and Module B. However if they try the same thing now IntelliJ tries to make the Modules main and test from Module A.
A workaround we temporarily use for this is to open Module A and B directly as separate IntelliJ projects. If we do this IntelliJ does not try to make modules out of main and test. However this is very inconveniant for us.
How can we fix this?
It's a good approach to make your source control system "agnostic" about the IDE and not check in .idea, *.iml and equivalent things from other IDE's.
However you really need to use a build control system like maven or gradle.
In my workplace we use maven for all our java projects. It's very simple to define a pom.xml at the root level which defines your modules, and many other things.
When you import a maven project into intellij, all the relevant IntelliJ modules are automatically created for you. In essence, you only need to import the pom.xml and you're good to go.
Otherwise it will be a nightmare to import and create modules every time you check out source from git. Maven isn't perfect but I highly recommend using either maven or gradle.
To define multi-modules from the root pom.xml, make a section like this:
<modules>
<module>module-A</module>
<module>module-B</module>
</modules>
And then the pom.xml in both module A and B should define a section referring to the root pom via the <parent> tag.
I am developing a plugin for IntelliJ IDEA. The way I am going about this is by creating a plugin project in IDEA, then packaging this into a jar with appropriate META-INF/plugin.xml, and installing the plugin from the jar.
The problem is that I would like to add a dependency on org.scala-lang:scala-library:2.11.0. I have this specified as a library dependency in the IDEA project, but this information never seems to get passed along to the generated JAR.
How can I include this information in such a way that IntelliJ IDEA will recognize it?
As far as I understand, you want to bundle some library (e.g. scala library) with your plugin.
This is pretty simple.
Go to Project Settings, select module and go to Dependencies tab. Set scope for the library you want to bundle to 'Compile'. In this example it is 'checker-framework' library. 'groovy-2.3.6' library will not be bundled due to its scope set to 'Provided'. Save changes.
Prepare plugin for deployment
Then you got plugin, zipped, ready for deployment (uploading to repo or installing locally) in the root of project. It will contain lib folder with all necessary jars.
The officially supported plugin dependency management solution is to use Gradle with the gradle-intellij-plugin, via Gradle's dependencies or the intellij.plugins entry points. If you want to add a dependency on an artifact (ex. hosted on Maven Central), then configure dependencies just as you normally would in a Gradle based project:
buildscript {
repositories {
mavenCentral()
}
}
dependencies {
compile("org.scala-lang:scala-library:2.11.0")
}
The intellij.plugins entry point will add an artifact in the current project, as well as a <depends> tag to your plugin.xml file. To install an external plugin alongside your own, for example if you are using the Plugin Extensions feature (suppose the plugin is hosted on the JetBrains Plugin Repository), use the following snippet:
plugins {
id "org.jetbrains.intellij" version "0.2.13"
}
intellij {
//...
plugins "org.intellij.scala:2017.2.638"
}
I have a RCP project where I cannot fix a NoClassDefFoundError: One plugin depends on another plugin. The plugin-dependencies are set in the manifest, packages exported, and there is no error at compile time. Both plugins are in the product dependencies and visible in the installation details of the product.
But when I run the application I get a java.lang.NoClassDefFoundError when the one plugin wants to use a class from the other plugin.
Any hints how to find the reason for this are greatly appreciated.
Thanks,
Michael
I found the problem: I created the plugin which could not be loaded from an existing Java project. And somehow I deleted the "." in the entry Bundle-classpath in the plugin manifest (the plugin has some jars which -> so lib/xyz.jar was in the Bundle-classpath entry but not the ".").
For the class-loader of the bundle the "." means to search for classes from the root path of the bundle (or something like that), so it could not find the classes. However, there were no errors in the IDE so it was hard to find.
Is the configuration for running the application correct i.e. all dependencies are also put in the running configuration?
this is an odd request but here is the scenario. I am writing custom maven plugins that basically manipulate build versions then will install or deploy the modified jar. The plugin is called both via command line and a build profile.
The plugins all have similar behavior, so the solution will work for all. Currently I am manipulating the project version in memory, via MavenProject.setVersion(newVersion);. This works and builds a local jar with the new version, but once the MavenInstaller executes the newVersion jar is installed in my local repo with the old version information and location. Is there a way I can prevent or override this behavior? The plugin is not using the Maven Installer or Deployer directly, and is just part of the build phase.
The file is executed as: mvn install -Pincrement and the increment profile is associated with the process-sources phase.
EDIT 1: I am looking into overriding the install/deploy lifecycle with a plugin that will basically handle what I plan on doing, while also still handling the normal behavior of install/deploy.
http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-override-default-lifecycle.html
EDIT 2: Following Edit 1 I was able to override a default lifecycle, in this case install and deploy with a custom solution. I do not like that it requires a custom package, so packaging tag no longer refers to the true packaging type and requires me to set an additional tag so that I can lookup the type.