I'm developing for Android and have downloaded IDEA 13.1.3. The reason for that was the missing option in Android Studio to reorganize dependencies.
I'm going to ProjectStructure -> Modules -> MyModule -> Dependencies
But every time gradle rebuilds the project the imports are automatically reorganized bringing the Android API as the first dependency (i.e. the MyApp.iml is modified and <orderEntry type="jdk" jdkName="Android API 19 Platform" jdkType="Android SDK" /> is moved to the top.
Additionally the project SDK is being changed to java (i.e. .idea\misc.xml is modified)
I'm using the latest InetelliJ Community Edition RC - that is v 13.1.3 build 135.909. I've tried android gradle plugin 0.9.+ and the most recent 0.10.4
For Gradle-based projects, setting order of entries in the classpath is not supported at this time. As you've seen, for Gradle-based projects it rewrites the .iml files every time it syncs the project with the Gradle files, which happens frequently. In this scenario, the .iml project files aren't considered to be user-editable and aren't intended to be checked into source control or treated as anything other than ephemeral. The same goes for everything in the .idea folder.
Where this is usually a problem for Android Studio users is for those who want to do plain Java unit testing (rather than the androidTest support in the Android Gradle plugin). This is known to not work very well at this time; you can track its progress at https://code.google.com/p/android/issues/detail?id=65186. I realize that bug doesn't mention anything specifically about classpath ordering, but it's all part of the same larger issue.
Related
I created a new project from VCS (Kotlin and Gradle). I added three testImplementation() calls to the build.gradle.kts. IntelliJ didn't pickup the changes so I did File -> Invalidate caches / Restart and now Intellij shows every implementation() call and every testImplementation() call in red. In fact every line in every build.gradle.kts in every module is red.
Intellij has lost its mind. What do I have to do to restore IntelliJ's intelligence when it comes to kotlintest in Gradle?
I started seeing this with AS 4.2.1. Invalidating caches and re-importing the project didn't work for me. I found this article on the JetBrains issue tracker where people found that they had an extraneous JDK set in the project settings. While I did not have an extraneous JDK set in my project structure, I tried changing the JDK from the AS embedded version to an alternate AdoptOpenJDK 1.8 version I had installed. After switching to that version all the red went away and everything is resolving as expected. I was then able to switch the SDK back to the embedded version and everything continued working as expected. When switching back to the embedded version I did notice a brief message in the progress bar at the bottom of AS saying that it was processing a JDK 11. I'm not sure where that's coming from, but it does seem to be in line with what others in the JetBrains issue were talking about.
The way I was finally able to solve this was with File -> Invalidate caches / Restart. It must have been cache corruption.
What do I have to do to restore IntelliJ's intelligence when it comes to kotlintest in Gradle?
Re-import the project: File | New | Project from Existing Sources action and select build Gradle file to load the project from.
Change your jdk.
Go to File>Project Structure > SDK Location > GradleSettings
Change the Gradle JDK to use the embedded or a compatible JDK (Azul JDK) if you're using a MAC.
Then Invalidate and refresh cache after deleting the .idea and .gradle files.
We upgraded one of our Eclipse 3.x plugins to work with Java 9.
But when we generated the plugin update site content, and used Eclipse Update functionality to install the new version of the plugin, we encountered the following error in Eclipse Oxygen.
Removing part descriptor with the 'pluginxxx.bla.bla' id and the 'bla bla' description. Points to the invalid 'bundleclass://org.eclipse.ui.workbench/org.eclipse.ui.internal.e4.compatibility.CompatibilityView' class.
This error also appears due to some of the bundled plugins of Eclipse Oxygen itself.
After a hard week we had to
Uninstall our plugin
Remove the older versions of the plugin from the Eclipse/plugins folder
Export the plugin as a deployable plugin under the eclipse plugins directory. (Eclipse/plugins/blabla.jar)
Restart Eclipse and it worked.
Right click the eclipse plugin project and Run as "Eclipse Application" works fine, but installing the plugin from an "Update Site" causes the plugin to fail loading.
We could not find a solution yet, but it certainly effects our delivery of the plugin. The plugin is used by almost 500 CS students on their personal computers, and 200 lab computers. So the update should be installed using regular Eclipse Update functionality, not by copying the jar into the plugins directory.
Was there a better way to fix this, or something quicker we could've tried (in case this happens again)?
Update (7 days into the problem)
We have a workaround:
Export the feature project with the following settings in the Export Wizard
Destination/ Directory: Folder of your Plugin Update Site project
Options/ Package as individual JAR archieves (selected)
Options/ Generate p2 repository (selected)
Options/ Allow for binary cycles in target platform (selected)
Options/ Use class files compiled in the workspace (essentially selected)
Install (or update) the plugin from the local (or remote) plugin update site, and the CompatibilityView problem is solved.
In order to have the category listing displayed correctly during install/update new software operations, we added a category.xml file (File/New/Other/Plugin-in Development/Category Definition) in the update site project, defined the categories, and added the feature (versioned as "qualifier").
This is certainly not the way it should be, and we just hope it will be solved in the future Eclipse releases.
By the way current Eclipse Photon integration version has the same problem unfortunately.
Be it an example project, freshly downloaded from Play Framework's website, or my project which is derived from that with a few changes to templates - nothing big - IntelliJ just can't seem to find the appropriate dependencies or sources necessary for Play development.
I've already installed Scala plugin for IntelliJ, which includes support for Play Framework. I'll outline the process that I've followed, after reading multiple articles from Play's documentation as well as questions asked on here though no answer has proven incredibly useful as yet.
Open Project Settings within IntelliJ IDEA Ultimate 2017.2.6
Click Modules > [+] > Import Module
Find build.sbt within project root
Import with default SBT settings:
Download: [checked] Library sources, [checked] SBT source
[unchecked] Use SBT shell for build and import (requires sbt 0.13.5+)
Project JDK: [9.0 (java version 9.0.1)] -- Could this be the problem? (compatibility)
SBT compiles and I get this error, which I somewhat dismissed but reading it now seems to be somewhat telltale but I am unsure of what: https://pastebin.com/tXbHQdek
Running the site works, using sbt run, but when opening .java sources, IntelliJ marks errors upon import play.mvc.* though import views.html.* works fine. Adding framework support for Play 2.x seems to do next to nothing, as no project settings seem to change, and the error is not resolved.
This behavior exists with a clean IntelliJ 2017 Ultimate install (as of today) and an example project from Play Framework with no modifications, so if a solution cannot be found I'll probably consider posting an issue on one or more of their issue trackers.
Any ideas on how to get my Play Framework development environment working?
Thanks :3
This did not originally occur to me but in my search through the Play Framework Google group, I found a suggestion on a somewhat recent post to uninstall Java 9 as Play's dependencies are not yet compatible with it and hence won't resolve.
For anyone who might come across this issue, hopefully this saves you some days headbanging:
Optional - Uninstall JDK and JRE 9
Install JDK 8 (comes with JRE)
From within IntelliJ, File > Project Structure > SDKs > [any Java 9 JDK] > [-]
[+] > `Find your JDK 8 installation folder
32 bit: C:/Program Files (x86)/Java/jdk****/
64 bit: C:/Program Files/Java/jdk****/
Where **** is your Java version, such as 1.8_152, as in jdk1.8_152
Press OK. You'll get a warning that the project SDK is missing or similar, so click the link it provides you to configure that and select your newly configured JDK.
Everything should work from there, just straight away after IntelliJ indexes, which can be tracked in the bottom right corner as with all other operation progress.
If I import a Maven project (Import Project > choose the main pom.xml file > check Import Maven projects automatically > Next ...):
in IntelliJ IDEA 14.1 Ultimate Edition it takes about 5 hours until is ready.
in IntelliJ IDEA 14.0.3 Ultimate Edition it was about 20 times faster.
During the processing, if I maximize a popup it looks like:
The modules (folders) in the Project area are shown only at the end (only the files from the main directory are shown during the "resolving" - in this case immediately).
The jar files are already in the .m2 folder, so the problem is not related to the time for downloading those jars.
Is there a "hidden" setting needed to improve the performance? (a check box, a command, etc.)
Details:
Windows 7
Java 7
Apache Maven 3.2.1
Edit:
JDK, Maven, .m2, IntelliJ IDEA and the project sources are on the same drive
JetBrains wrote:
Your projects open faster and the IDE is more responsive as some processes now run in the background.
regarding IntelliJ IDEA 14.1 and probably it is faster but (at least for me) not using the default settings.
If you use the bundled Maven that comes with Idea 14.1, have a look here: Slow Intellij IDEA deployment . Using an installed Maven seems to be much faster.
Another improvement could be to change the JDK for importer (and probably the VM options for importer) from Use internal JRE to your own JDK:
It's all because Maven version. Maven 3.0.5 or Maven 2.x use simplified dependency resolution so often it can be used during import for big projects. Thought it can work incorrect for some projects which uses 3.1+ Maven.
Switching off auto-importing is another solution.
I have 2 completely separate projects where one depends on the other. I've very recently mavenized the main project but can mavenise the dependency if absolutely necessary.
Originally these were Netbeans projects, with the main project having several modules. What I liked is that I could declare the dependency as a dependent project. This allowed me to use the most recent code as it changes a lot (the project is in its infancy). NetBeans would put the dependent project on the classpath when running, and build a jar in the /dist directory when doing a clean and build.
Now that the main project is in maven, I can't do this anymore. The only alternative I've found was to manually copy it into the project repository, but that removes a lot of automation and ease of use. Every time I wanted to test a change I would have to rebuild the dependency, move it to the buried project repository folder, rename it appropiatly, switch back to NetBeans, then run. This is vs clicking run and everything being done automatically.
Maybe I'm just lazy, but is there an easy way to do this?
I have 2 completely separate projects where one depends on the other. I've very recently mavenized the main project but can mavenize the dependency if absolutely necessary.
Mavenizing the dependent project would help a lot. Like Eclipse or IntelliJ, NetBeans supports something Eclipse calls Workspace dependency resolution: if a project A depends on a project B and you open both of them in your IDE, A can be configured to depend on B sources instead of B jar (and any change would become immediately visible).
mavenizing the depedency project is the best option.
Alternatively you might get away with using a system scope dependency which points to the dependency project's dist/ folder jar artifact.