intellij-platform-gradle-plugin
intellij-platform-gradle-plugin copied to clipboard
JetBrains
Using PyCharm, WebStorm, etc.
It looks like the differences in the IDEs are larger than I thought (see https://github.com/Turbo87/intellij-emberjs/issues/4), so it would be great if we could also choose PyCharm, WebStorm, etc. instead of just IntelliJ to run/test the plugins.
We have no any plans about publishing small IDEs in maven.
As an option I can try to provide an option to use local IDE instance instead of downloading it from maven, in this case you can download IDE manually and use it via gradle plugin.
Hi, is there any estimation on when this feature is going to be implemented? I am working on a plugin for Android Studio and would love to let this great plugin manage dependencies to the studio jars for me and to be able to test my implementation directly into a sandboxed Android studio.
is there any estimation on when this feature is going to be implemented?
@danail-branekov as I said we have no any plans about publishing small IDEs in maven. Moreover this doesn't cover Android Studio. As for locally installed IDE, you may use intellij.alternativeIdePath property, see README for details.
Oh, this is really cool. Initially I though that alternativeIdePath would determine the IDE used when runIdea task is performed. But then I realised that I also have the version property set. Removing it made gradle build my code against Android Studio.
Thanks!
@danail-branekov it does determine the IDE used when runIdea task is performed. Plugin still requires IDEA dependency for building
Hm... how about using the alternative IDE when resolving the dependencies as well? This would help a lot into building against the product you are actually developing for instead of building against a pure IDEA distribution.
Here is a sample scenario - I am developing a plugin for the Android studio (1.5.x) which is based on IDEA 14.1. I would like to plug into new module creation wizard and therefore need to access the class com.android.tools.idea.npw.NewModuleDynamicPath. This class is not available in IDEA 14.1 but is available in IDEA EAP.
- Building against EAP requires me to use Java8 otherwise I get a UnsupportedClassVersionError
- Android studio requires me to build with Java6
=> Both point above contradict with each other and I get stuck
It would by simply great if the IntelliJ build plugin just picks up the jars from the specified local alternative IDE and put them into my project dependencies.
Hm... how about using the alternative IDE when resolving the dependencies as well?
And in the third time we still have no any plans about publishing small IDEs in maven.
This would help a lot into building against the product you are actually developing for instead of building against a pure IDEA distribution.
I don't really understand how it could help.
Building against small IDEs won't help you with this scenario. You still have to have different sets of sources for different IDE version (I mean 14.1 and 2016.1).
And in the third time we still have no any plans about publishing small IDEs in maven.
I got your point the first time you mentioned that. I cannot agree more with that and I am not arguing.
What I am proposing is that in case alternativeIdePath (or whatever other property) is set then org.jetbrains.intellij.IntelliJPlugin#ideaDirectory to take the property value into consideration (i.e. returning new File(the_IDE_path_property)) so that whenever org.jetbrains.intellij.IntelliJPlugin#configurePluginDependencies executes it would configure the ivy repository to reference the LOCALLY pre-installed IDE, e.g. Android Studio, instead of the one currently fetched by the build plugin
I know that this would make the build environment-specific but you can safely leave this issue to the CI engineers to handle. They could use multiple approaches here such as:
- environment variables
- JVM arguments
- some kind of setup conventions
- etc
This would give the build plugin users control on what to build against instead of hacking the build.gradle file themselves in order to manage the dependencies not available in the standard maven-hosted IDEA distributions.
I am also not underrating the approach of having maven-hosted IDEA distributions, I am convinced that they are just great for 95% of the development scenarios.
Preinstalled locally IDE is not enough to build a plugin. Using some files from locally installed IDE and some other files from fetched IDE leads to inconsistent build, there is no guarantees that all these files will be compatible to each other and gradle-intellij-plugin has no enough information to verify this, especially in case of using Android Studio. Using such configuration means that you can build the plugin that won't be compatible to any IDE.
Anyway, gradle is quite customizable so you can do it on your own risk in your own gradle-script. If it requires some changes in gradle-intellij-plugin (like making intellij-configuration public), please let me know.
There is another option how to build plugin agains Android Studio. It requires maven-repository with Android Studio binaries/sources like we have for IDEA: https://www.jetbrains.com/intellij-repository/releases. If there is one you can just define intellij.intellijRepo property in your build.gradle to use it. It's better to ask at https://code.google.com/p/android/issues/list whether Google can do such repository.
Thanks for the suggestion, here is the request: https://code.google.com/p/android/issues/detail?id=208227
Sad that there are no plans to support the "smaller ide's". However I wrote a little buildscript that downloads pycharm and sets it up with the alternativeIdePath. Appears to work fine 😄 although I might run in some dependency issue but we see about that.
We have no any plans about publishing small IDEs in maven.
@zolotov how? Just use alternativeIdeaPath? When specify alternative path it still tries to download idea from jetbrains repo.
@da1z yes, just use alternativeIdeaPath. IDEA is still needed for compilation.
because it has no other way to develop a plugin
@zolotov Android Studio and MPS too? Why exclude some and not others ? Surely it would not be too difficult to implement by adding PyCharm/CLion/... endpoints and downloading the binaries even if they're not published on Maven. Adding product specific plugin support would be great to have! @mikhailvink
@breandan It's more about including particular products, not excluding some of them.
I'm not aware of Android Studio plugin development, there is an issue to track this: https://code.google.com/p/android/issues/detail?id=208227. As soon as Google upload AS distribution and if it will be possible to build plugins with AS only (e.g. it's not possible to compile plugins with PhpStorm), I'll add the support for it.
This is exactly what happened with MPS. MPS team decided to upload their distributions and asked to implement support in gradle-intellij-plugin. I'm not sure why they did it and not sure when it's going to work. See https://youtrack.jetbrains.net/issue/IDEA-189818 for details.
Adding product specific plugin support would be great to have!
You can depend on that particular PHP plugin and develop plugins using it, uploading entire PhpStorm is not required.
You can depend on that particular PHP plugin and develop plugins using it, uploading entire PhpStorm is not required.
I suppose you could add a plugin dependency, but if I understand correctly, language plugins have a different update cadence from the primary IDEs and not all IDEs are available as plugins. Wouldn't it be in your interest to directly support sandboxing on other IDEs, to make it easier for plugin developers targeting unsupported IDEs (eg. CLion) and EAP versions? Perhaps the added complexity of refactoring the DSL would be too much trouble. Developers will just need to write their own custom scripts to download and unpack the IDE, then set the appropriate alternativeIdePath. But why not wrap that inside the gradle-intellij-plugin?
if I understand correctly, language plugins have a different update cadence from the primary IDEs and not all IDEs are available as plugins.
All minor IDEs are released in a single week along with IDEA. Every language plugin is published within the IDEA EAP otherwise it wouldn't be possible to use them, e.g. PHP, in IDEA EAP builds. As for the absence of some plugins, like CLion one, it's on CLion team and if they decide to publish IDE distribution to the maven, I will add the support in gradle-intellij-plugin. Adding and supporting custom ways of downloading IDE distribution is not in my plan. Still, you can make a PR and I'll consider merging it.
Excited to see this finally shipped, nice work! Are you planning to support running separate IDEs directly via the runIde DSL?
edit: Also the latest Maven dependency for CLion appears to be 2018.3.3. Are they planning to publish EAPs?
@breandan eap is here: https://www.jetbrains.com/intellij-repository/snapshots, not sure about non-snapshot build. @amakeev?
Are you planning to support running separate IDEs directly via the runIde DSL?
No particular plans yet. It sounds good, though.
@breandan As Alexander pointed, the EAP snapshot builds are currently available in https://www.jetbrains.com/intellij-repository/snapshots.
We are considering to stop publishing EAP builds to https://www.jetbrains.com/intellij-repository/releases (as they have limited lifetime). Please let me know if this could affect your workflow.
Could You help me please to setup alternativeIdePath for mac? /Applications/PhpStorm doesn't work for me. Thanks.
