Commits on Apr 5, 2012
Commits on Mar 27, 2012
Commits on Mar 21, 2012
  1. Some heavy cleanup of pom files and scripts. Further, I have created …

    dotta committed Mar 16, 2012
    …a parent
    pom project that contains properties common to all subprojects.
Commits on Mar 16, 2012
Commits on Mar 15, 2012
  1. Correctly handle preferences change events

    skyluc committed Mar 14, 2012
    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
    Forcing those preference change to be run in the UI thread.
    Fixes #1000738
    (cherry picked from commit 8f534ee)
Commits on Mar 6, 2012
  1. Build the IDE using 2.0.x p2 repo for scalariform and scala-refactoring.

    dotta committed Mar 6, 2012
    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
    ```` 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.
  2. Revert "Fixed build to adapt to new scalariform API."

    dotta committed Mar 6, 2012
    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).
  3. Open Declaration via the context menu now works as expected.

    dotta committed Mar 5, 2012
    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:

    Fix #1000920.
    (cherry picked from commit d43126d)
  4. Fixed problem if typing braces at EOF.

    skyluc committed Mar 5, 2012
    Added test cases.
    Re #1000926
    (cherry picked from commit 2405b62)
  5. Improved closing braces managment

    skyluc committed Mar 5, 2012
    - closing brace is delete when deleting an adjoining opening brace
    - closing brace is jumped (not added) when hitting the '}' key.
    Added some weak regression tests.
    (cherry picked from commit 5af52de)
Commits on Mar 5, 2012
  1. Removed useless distinction between `hasErrors` and `hasBuildErrors`.…

    dragos committed Feb 29, 2012
    …(cherry picked from commit 24a4734)
  2. Added project dependencies test, and refactored some other tests to r…

    dragos committed Feb 11, 2012
    …euse more code. Fixed #1000894.
    (cherry picked from commit 390a1cf)
  3. Fixed transitive and direct dependencies for project builders.

    dragos committed Feb 11, 2012
    (cherry picked from commit 493aa4f)
  4. Pass upstream projects API to the Sbt builder.

    Iulian Dragos committed with dragos Feb 3, 2012
    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)
  5. Fixed 1000893. Added an option to stop building downstream projects

    Iulian Dragos committed with dragos Feb 3, 2012
    if a project has compilation errors.(cherry picked from commit 0b3c20c)
    (cherry picked from commit bbd3aea)
  6. Merge pull request #77 from scala-ide/issue/code-completion-import-ba…

    dragos committed Mar 5, 2012
    Issue/code completion import backport 1000855
  7. Perform code-completion and import-adding in one step.

    misto committed Jan 12, 2012
    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.
Commits on Mar 1, 2012
  1. Passing to -Xplugin a path containing whitespaces is finally parsed c…

    dotta committed Mar 1, 2012
    Up until now, passing to -Xplugin a path containing whitespaces resulted in
    *no* plugin being loaded. That because
    ``MultiStringSetting#tryToSetFromPropertyValue`` was splitting the passed value
    at whitespace occurrences, which was of course resulting in a mess.
    The pull request scala/scala#235 in the Scala compiler
    has fixed this issue (patch available in both 2.10 and 2.9.2). In short, now
    commas (``,``) are used to split -Xplugin value (when more than one plugin is
    passed to it). Some adaptation on our side was also needed for correctly
    handling commas as the splitting character.
    This commit also fix a issue with the way we used to hande -Xpluginsdir value.
    Read the big comment in ScalaPlugin.defaultScalaSettings for more information
    about this.
    As a side note, enabling continuations should now work as described in
    Fixes #1000917.
    Integrated @skyluc code review (pull #75) and added a couple of new tests to
    check that compilation of a source requiring the continuations plugin enabled,
    works as expected.
    (cherry picked from commit cbfd82d)
Commits on Feb 24, 2012
  1. Fixed a long-standing bug in the JavaScalaMapper, by adding an askOpt…

    dragos committed Feb 24, 2012
    …ion when looking at TypeTree.symbol (cherry picked from commit 6a5d634)
Commits on Feb 20, 2012
  1. Fixing the build for Scala trunk. No more implicit conversions from S…

    dragos committed Jan 16, 2012
    …tring to Name.
    (cherry picked from commit 876de6e)
  2. For no apparent reason, using `ScalaPlugin.defaultScalaSettings` is n…

    dotta committed Feb 20, 2012
    …ot the
    same as `new Settings` in `SettingsCleanup` class, and I honestly really can't
    see a reason (if anyone has an idea, please don't be shy).
    The issue with using `ScalaPlugin.defaultScalaSettings` is that SBT may fail
    compiling sources that depends on the continuations plugin. For instance,
    assume you have a `plugins` folder (located in ${PATH_TO_PLUGINS_DIR})
    containing the continuations.jar plugin, and in the project's settings the
    following options are passed:
      -Xplugin ${PATH_TO_PLUGINS_DIR}/continuations.jar
      -XpluginsDir ${PATH_TO_PLUGINS_DIR}
    The SBT compiler will fail to compile the sources because it can't locate the
    continuations plugin.  While, when using `new Settings`, it all works fine.
    I've add a FIXME note to remind us of the problem.
  3. Override default when an explicit value is provided for `-XpluginsDir`.

    dotta committed Feb 20, 2012
    In the IDE, for convenience we use to se the value of `-XpluginDir` to the
    default location in the distribution that contains the continuations.jar
    plugin.  This is convenient because users need only to pass
    `-P:continuations:enable` to use the continuations plugin.
    If in the IDE an explicit value is provided for `-XpluginsDir`, then we simply
    concatenate the user's provided plugins' directory to the default one.  This
    generally works fine and allows users to keep using the continuations plugin
    without having to copy the continuations.jar in the provided user's plugin
    However, by passing the additional parameter -Xplugin
    ${path-to-continuations-plugin}, the compiler is unable to load the
    continuations.jar. The reason is that there is ambiguity. `-XpluginsDir`
    instructs the compiler to load all plugins available in the passed
    directory(ies) and, as we said in the first paragraph, that means that the
    continuations' plugin gets always loaded. Now, when also `-Xplugin
    ${path-to-continuations-plugin}` the Scala compiler seems to get lost because
    it sees the continuations.jar twice, and it looks like it decided to simply not
    load it. Hence, the compiler will complain that the continuations plugin isn't
    enabled. That looks like a bug, and a ticket in the Scala compiler JIRA has
    been created for this:
    But in consideration of what has been said, I believe that we should not try to
    always set `-XpluginsDir` to point to the default location in the distribution.
    If the user decides that it should point to some other place, then provided
    location should be used. That actually matches the Scala compiler's behavior.
    Fix #1000908.
Commits on Feb 9, 2012
  1. Use File.pathSeparator when building the pluginsDir setting, to be pl…

    dragos committed Feb 9, 2012
    …atform independent. Fixes #1000901.
    (cherry picked from commit 4ffdd09)
Commits on Jan 3, 2012
  1. Created bash script for signing the Scala IDE Eclipse plugin.

    dotta committed Dec 19, 2011
    It needs some love, but it does the work. no review.
    (cherry-picked: 82421c5)
  2. Updated 'know issues' link in the 'Scala Setup Diagnostic' popup to p…

    dotta committed Dec 19, 2011
    …oint to new location of the user documentation. no review.
    (cherry-picked: 9f539fc)
Commits on Dec 12, 2011
  1. Added 'org.eclipse.jdt.groovy.core' in Eclipse-SupplementBundle secti…

    dotta committed Dec 12, 2011
    …on of
    MANIFEST. Fix #1000798
    To correct #3135 we removed the AJDT dependency from the Scala IDE. An
    undesired side-effect of this change was that the Scala IDE was no longer
    usable if the Groovy IDE was also installed.
    The problem was that our (aspect) class responsible of intercepting the call to
    create a ScalaSourceFile was no longer used, that because our class was
    targeting the 'org.eclipse.jdt.core' bundle, which is not loaded when the
    Groovy IDE is installed.
    The fix was to edit the MANIFEST's Eclipse-SupplementBundle section of our
    'org.scala-ide.sdt.aspects' project, and make sure that our aspect class is
    called also when the call is performed from the 'org.eclipse.jdt.groovy.core'
    bundle (which is the Groovy IDE core bundle). The AJDT plugin does exactly
    that, and that is why this problem was a side-effect of removing the AJDT
    dependency from the Scala IDE.
    (no review)
    cheery-picked from 3b477dd
Commits on Dec 9, 2011
  1. Changed the Scala library/compiler version check

    skyluc committed Dec 9, 2011
    It know checks at the major/minor level, not lower. And logs an error if
    it cannot find a match.
    Fix #1000793
Commits on Dec 8, 2011