Upgrade to IJ2019.2 - unsatisfied dependencies

It may be that you have included some libraries from the previous distribution's lib/plugin directories in you project's plugin SDK classpath (File->Project Structure...->SDKs) and did not re-include them after upgrade.  IntelliJ IDEA does not bring your SDK modifications forward to a new installation; you have to do that manually.

Or, perhaps the issue is due to one of these changes? (Documented here.)

Notable Changes in IntelliJ IDEA

Java functionality extracted as plugin

If your plugin depends on Java, it must be specified now, please see blog post for details.

Unbundled plugins

Several plugins for no longer actively maintained technology have been moved to a separate repository. If your plugin depends on them, users will need to install them from the JetBrains plugin repository.

Thanks, Eric. I have now specified the java plugin in both spots (I didn't know about doing it in plugins.xml, only in build.gradle). It seems I am able to compile against things in the java plugin, but I have trouble at runtime with actually finding the dependencies:

gw.gosu.ij.interoperability.javaAsGosu.JavaForGosuPsiElementFinder has unsatisfied dependency: class com.intellij.psi.PsiElementFinder among unsatisfiable dependencies: [[class com.intellij.psi.impl.PsiElementFinderImpl], [class com.intellij.psi.PsiElementFinder]] where DefaultPicoContainer (parent=DefaultPicoContainer (root)) was the leaf container being asked for dependencies.

Well, when running your tests, the java plugin needs to be in the classpath.  (Add it to your SDK classpath.)

When running in the field, you may have to tell your users to download/install the java plugin, or package it in your own plugin, though I haven't checked the legalities of doing that.  Setting the dependency in the plugin.xml should make IDEA _et al_ prompt the user (and download it automatically) before allowing your plugin to be enabled.

Classpath is an interesting thought.

This is not working from IntelliJ *or* from gradle (command line). (We use the Intellij gradle plugin for development.)

So where would I alter the value of classpath so that, for example, the gradle 'runIde' command would pick up the java plugin?  

Add it to your SDK.  File->Project Structure->SDKs->[your SDK name]->ClassPath(tab).

The correct solution is to add dependency to Java plugin to your build.gradle as described in the linked blog post (https://blog.jetbrains.com/platform/2019/06/java-functionality-extracted-as-a-plugin/):

intellij {
  plugins 'java'
  // ...
}

Then, dependency must be added to plugin.xml as well via

<depends>com.intellij.modules.java</depends>

Please also make sure to use the latest EAP version of IntelliJ IDEA as well as latest version for intellij-gradle plugin

I have confirmed that all build.gradle files specify the 'java' plugin, the correct <depends> is in the plugin.xml files, and the plugin version is gradle-intellij-plugin:0.4.9

Is there an example plugin which depends on java? And is it possible that, because I'm using the EA, things aren't working quite right?  I didn't know how to make the EA work with the automatic download

intellij { version 'what version for 2019.2 EA?' } 

so I am using

intellij { localPath 'path-to-2019.2.EA' }

and I'm wondering whether that's been tested with a plugin that requires 'java' as a dependency.

2019.2 final release is available now, could you try switching to it?

Just tried with IC-192.5728.98 and my tests all still fail with messages like

com.intellij.testFramework.LoggedErrorProcessor$TestLoggerAssertionError

        Caused by: com.intellij.testFramework.LoggedErrorProcessor$TestLoggerAssertionError

            Caused by: com.intellij.openapi.extensions.impl.PicoPluginExtensionInitializationException

                Caused by: org.picocontainer.defaults.UnsatisfiableDependenciesException

Please post a full stacktrace and/or link to your plugin's sources

It seems setup for requiring Java plugin is missing? https://blog.jetbrains.com/platform/2019/06/java-functionality-extracted-as-a-plugin/

No, the setup is there. I just don't think it's working right.

I can send you sources for the plugin, but I don't have a place to host them. My company infosec department suggests emailing you an encrypted zip file. Is there an email address I can use?

Does it work if you put in plugin.xml

<depends>com.intellij.java</depends>

instead of

<depends>com.intellij.modules.java</depends>

No...it still can't find the Psi classes for java:

ERROR: gw.gosu.ij.interoperability.javaAsGosu.JavaForGosuPsiElementFinder has unsatisfied dependency: class com.intellij.psi.impl.PsiElementFinderImpl among unsatisfiable dependencies: [[class com.intellij.psi.PsiElementFinder], [class com.intellij.psi.impl.PsiElementFinderImpl]] where DefaultPicoContainer (parent=DefaultPicoContainer (root)) was the leaf container being asked for dependencies.

Where can I find sources for your plugin? Or could you c/p all CTORs declared in JavaForGosuPsiElementFinder here? Thanks

I don't have the sources in a public repository -- I would have to email them to you.

Here is the beginning of that source file:

package gw.gosu.ij.interoperability.javaAsGosu;

import com.intellij.openapi.project.DumbAware;
import com.intellij.psi.PsiClass;
import com.intellij.psi.PsiDirectory;
import com.intellij.psi.PsiElementFinder;
import com.intellij.psi.impl.PsiElementFinderImpl;
import com.intellij.psi.search.GlobalSearchScope;
import com.intellij.util.Processor;
import gw.gosu.ij.interoperability.gosuAsJava.psi.GosuPackageForJava;
import gw.gosu.ij.interoperability.javaAsGosu.psi.JavaClassForGosu;
import gw.gosu.ij.interoperability.javaAsGosu.psi.JavaPackageForGosu;
import gw.gosu.ij.psi.AbstractGosuPsiElementFinder;
import gw.gosu.ij.psi.GosuPsiClass;
import gw.gosu.ij.psi.GosuPsiPackage;
import org.jetbrains.annotations.NotNull;
import org.jetbrains.annotations.Nullable;

import java.util.Set;

public class JavaForGosuPsiElementFinder extends AbstractGosuPsiElementFinder implements DumbAware {
    private final PsiElementFinder javaElementFinder;

    public JavaForGosuPsiElementFinder(PsiElementFinderImpl javaElementFinder) {
        this.javaElementFinder = javaElementFinder;
    }

    protected JavaForGosuPsiElementFinder(PsiElementFinder javaElementFinder) {
        this.javaElementFinder = javaElementFinder;
    }

Referenced in plugin.xml as

<java.elementFinder implementation="gw.gosu.ij.interoperability.javaAsGosu.JavaForGosuPsiElementFinder"/>

Thanks. Why do you have two CTORs, once for PsiElementFinder and then again its *Impl? please try removing the *Impl CTOR-variant if possible.

I don't know the reason; I didn't create this code.

Removing the extra constructor gets rid of half the problem -- it no longer complains about the Impl class but it still can't find PsiElementFinder.

OK, I seem to have found it. PicoContainer wants the finders to have a public constructor which takes arguments (Project) or (Project, FileManager). I had to change this in a couple of places, and now the plugin is initializing properly.

Thanks for your suggestions -- they steered me in a productive direction.

Thanks, Richard. Indeed such CTOR arguments on extension points are not allowed in 2019.2 anymore, we'll update docs shortly.