Get plugin working on CLion

[kingsleyh]

Should just be a matter of a tweak in the plugin.xml and possibly some minor additions to the code

[russel]

Given that there is support for D code in CMake, I am very likely to try and get the latest version of this plugin working in CLion.

[kingsleyh]

Ok cool - go ahead - I'm about to have a baby - I'm going to be out of action for the rest of this year

[russel]

@kingsleyh Good luck to you and you other half on the little one. I am assuming there are people here who can merge pull requests in your absence.

[SingingBush]

@russel I can merge but @kingsleyh needs to put builds in plugin repo. I put the last few PR's in the develop branch so they can get further testing before going into master. So currently develop is the most up to date and any further changes should go there. I've got enough time to do the occasional merge/testing/responding to issues but I've not had the time to finish the work I was looking at for a dub tool window (home life is also manic).

A while ago I did a little investigation into getting the plugin working on CLion but it's not as small a job as I'd hoped for. before moving on we really should get a new release in the plugin repo.

@kingsleyh do you have time for quick call with russel, @pirocks and me so that progress can continue

[kingsleyh]

hey - if you can make the plugin file I need to upload to the jetbrains plugin centre I can do it. But I don't have time for anything else at the moment.

[russel]

@SingingBush @pirocks @kingsleyh I wonder if it is time to create a DLanguage organisation with Kingsley as lead and others with owner permission such that things can always progress no matter who is "missing"? If the organisation is the entity doing the merging and uploading then there is unlikely to be a blockage. I will not be around again today I suspect, but I should be available tomorrow onwards.

[kingsleyh]

I think the blockage is that the plugin upload only lets one person upload a plugin - unless you know of a way multiple people can do it

[SingingBush]

we should be able to set travis up in such a way that any tag gets uploaded to the plugin repo after a successful buld. the username & password just need to be set up in travis as environment variables. That way the only thing we need to do is merge all changes into master, make sure it all works as expected then create a new tag. There's examples of this kind of thing being done and I think some of the other intellij plugins do it.

[kingsleyh]

I can't find any documentation on an automated way to deploy to the jetbrains repo - there is documentation about deployment to your own enterprise repo but not sure if that's what we need.

[SingingBush]

in the build.gradle we have:

    apply plugin: 'org.jetbrains.intellij'
    intellij {
        pluginName 'D Language'
        version ideaVersion
        plugins 'copyright'
        downloadSources Boolean.valueOf(sources)
        sameSinceUntilBuild Boolean.valueOf(isEAP)

        publish {
            username System.getenv('JETBRAINS_USERNAME')
            password System.getenv('JETBRAINS_PASSWORD')
            channel 'on-demand'
        }
    }

so as long as those variables are set in travis account then I think we could just have a build that does something like:

if current build has TRAVIS_TAG set then run ./gradlew publish. we could even use the tag name as the version string that's current defined in gradle.properties. See travis docs on env variables.

[SingingBush]

I checked the Intellij gradle plugin repo and can confirm that the publishPlugin task uploads plugin distribution archive to http://plugins.jetbrains.com

[russel]

So if the latest release D Language plugin is uploaded to this repository, is it available for CLion as well as IntelliJ IDEA? Are we replacing rather than providing another plugin?

[kingsleyh]

I've pushed a change to develop branch with my username and password for the env variables in the .travis.yml - hopefully this will work

[khionu]

Can we get a status update for this issue?

[SingingBush]

I had a quick look at this again before xmas. As mentioned before it's not a small task. The build settings can be changed to get the plugin running against a local install of CLion. Set alternativeIdePath to point to clion and also make sure that <depends>com.intellij.modules.lang</depends> has been uncommented in plugin.xml

[SingingBush]

For anyone that wants to try this out, edit build.gradle and add alternativeIdePath (pointing to a local CLion install) to the intellij plugin section:

    intellij {
        ...
        alternativeIdePath '/opt/clion-2017.3/'
    }

Now edit plugin.xml, find the line where <depends>com.intellij.modules.lang</depends> is commented it out and update to be:

    <depends>com.intellij.modules.lang</depends>
    <depends>com.intellij.modules.platform</depends>
    <depends>com.intellij.modules.vcs</depends>
    <depends>com.intellij.modules.xml</depends>
    <depends>com.intellij.modules.xdebugger</depends>

this is essentially all the common parts that are in every Jetbrains IDE (see docs).

Now you can at least boot up CLion with the plugin using ./gradlew runIde

the IDE boots fine and if you go to setting you can find the D Tools section. However when you try to load a project or create a new D project it's just not possible.

There's a NoClassDefFoundError for com.intellij.projectImport.ProjectOpenProcessorBase, so the first thing to look at is what the differences are for creating/opening projects in CLion

[SingingBush]

the CLion stuff has been rebased and merged into develop