A file-system path may correspond to several resources in the workspace. We used to choose the first one, which lead to build errors being attached to the top-level project in nested project setups, even when the error belonged to a nested project. Fixes #1000734, #1000621, #1000881. Should be back ported to 2.0.x (cherry picked from commit ca87df4) Conflicts: org.scala-ide.sdt.core/src/scala/tools/eclipse/buildmanager/BuildReporter.scala org.scala-ide.sdt.core/src/scala/tools/eclipse/buildmanager/sbtintegration/SbtBuildReporter.scala
…lay templates. (cherry picked from commit 7b530c4)
Display a dialog when trying to run a scala application if: * The project cannot be built (if that is the case, no binary is produced, hence the application cannot be run). * The package name doesn't match the source's physical location (this is a known limitation Re #1000541) * The main type name provided in the Launch Configuration does not point to an existing source. Fixed #1000911 (cherry picked from commit 0b5f458) Conflicts: org.scala-ide.sdt.core.tests/src/scala/tools/eclipse/TestsSuite.java
The custom code I wrote to read an IFile was not releasing the file handle correctly. It was eventually closed when the object was GCed. Replaced the code with some internal jdt util method. Removed the incorrect method. Fix #1000909 This is a manual merge of bfb6d58 and part of be46489 from master.
…r menu Disabled Java specific actions for Source Generation and Externalizing String. These actions were displayed in the editor's context menu, under the Source menu item. Created an enhancement ticket (Re #1001018). Fixed #1000972 (cherry picked from commit 0fe0f5b)
The Scala compiler adds the currently running JDK to the class path, taking precedence over the JDK configured in the build path. This commit fixed #1000820, and generalizes the scheme used by the Sbt builder.(cherry picked from commit ab2137e)
…y POM (it is suffixed in the name assigned to the bundled JAR)" This is not needed (and actually it turns out to be just completely useless). The reason is that when creating a p2 repository the version suffixed to the JAR's name is the ``<Bundle-Version>`` declared in the MANIFEST. Sorry for the noise. This reverts commit 4bad326.
…t is suffixed in the name assigned to the bundled JAR)
…the 2.9.2-SNAPSHOT profile (in the pom file)
…a parent pom project that contains properties common to all subprojects.
Some Java preferences get set the first time a code template is used. This preference changes trigger UI updates, but the Java editor (base of the Scala editor) does not execute these UI updates in the right thread. Forcing those preference change to be run in the UI thread. Fixes #1000738 (cherry picked from commit 8f534ee) Conflicts: org.scala-ide.sdt.core/src/scala/tools/eclipse/ScalaSourceFileEditor.scala
The release/scala-ide-2.0.x branch need to be built using the release/scala-ide-2.0.x branches of both scala-refactoring and scalariform projects (look at the forked projects under scala-ide on github). To this end, I've made the necessary changes in the ``org.scala-ide.build`` POM file (look at the ``scala-2.9.2-SNAPSHOT`` profile). As part of this commit, I've also removed all profiles we don't use for building the Scala IDE 2.0.x. FInally, we don't need to build 2.0.x nightly for Scala 2.10 (it makes little sense, and it would actually require compiling scalariform and scala-refactoring with 2.10, create a Jenkins build, and such...). No review.
This reverts commit 9b7d398. The commit was needed because we used to build the release/scala-ide-2.0.x branch against scalariform and scala-refactoring *master*, indeed not a wise thing. Now, to build the release/scala-ide-2.0.x we are going to use the scala-ide-2.0.0-29 tag (which was created for the 2.0.0 release).
When the user right clicks on a element and select "Open Declaration" in the context menu, an instance of ``OpenAction`` is used to resolve the binding and jump to the declaration. Because the Eclipse API does not expose an extension point for this action, I had to create a custom extension point (using AJDT), which allows weaving in to JDT and can be used to intercept the creation of ``OpenAction``, if it originates from a Scala editor. This seem to be the only solution, which does not involve creating our own Scala Editor. Hopefully, we will be able to remove this custom extension point once we implement the Scala Editor (this is planned for Milestone 2 of the Scala IDE Helium). Using AJDT for customizing the behavior of ``OpenAction`` was also suggested by Andrew Eisenberg in the following StackOverflow question: http://stackoverflow.com/questions/1882053/how-can-i-define-a-custom-action-for-open-declaration-shortcut-f3-in-eclipse Fix #1000920. (cherry picked from commit d43126d)
…(cherry picked from commit 24a4734)
…euse more code. Fixed #1000894. (cherry picked from commit 390a1cf)
(cherry picked from commit 493aa4f)
Retrieve upstream analysis recursively, on all dependent projects. Moved the analysis store to the build manager level, instead of the compile run. (cherry picked from commit 8860921) Conflicts: org.scala-ide.sdt.core/src/scala/tools/eclipse/buildmanager/sbtintegration/EclipseSbtBuildManager.scala org.scala-ide.sdt.core/src/scala/tools/eclipse/buildmanager/sbtintegration/SbtConf.scala
We need to to code-completion and import-adding in one step, otherwise we risk that adding the import fails because the code-completion has changed the underlying file and the AST positions are out of date for the refactoring-library. Fixes #1000854. This is a backport of dcec1f3.