Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Mar 27, 2012
  1. @dotta
Commits on Mar 21, 2012
  1. @dotta
  2. @dotta

    Some heavy cleanup of pom files and scripts. Further, I have created …

    dotta authored
    …a parent
    pom project that contains properties common to all subprojects.
Commits on Mar 16, 2012
  1. @dotta
  2. @dragos @dotta

    Moved from to Sonatype's repository

    dragos authored dotta committed
Commits on Mar 15, 2012
  1. @skyluc

    Correctly handle preferences change events

    skyluc authored
    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. @dotta
  2. @dotta

    Build the IDE using 2.0.x p2 repo for scalariform and scala-refactoring.

    dotta authored
    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.
  3. @dotta

    Revert "Fixed build to adapt to new scalariform API."

    dotta authored
    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).
  4. @dotta

    Open Declaration via the context menu now works as expected.

    dotta authored
    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)
  5. @skyluc

    Fixed problem if typing braces at EOF.

    skyluc authored
    Added test cases.
    Re #1000926
    (cherry picked from commit 2405b62)
  6. @skyluc

    Improved closing braces managment

    skyluc authored
    - 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. @dragos
  2. @dragos
  3. @dragos

    Added project dependencies test, and refactored some other tests to r…

    dragos authored
    …euse more code. Fixed #1000894.
    (cherry picked from commit 390a1cf)
  4. @dragos

    Fixed transitive and direct dependencies for project builders.

    dragos authored
    (cherry picked from commit 493aa4f)
  5. @dragos

    Pass upstream projects API to the Sbt builder.

    Iulian Dragos authored dragos committed
    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)
  6. @dragos

    Fixed 1000893. Added an option to stop building downstream projects

    Iulian Dragos authored dragos committed
    if a project has compilation errors.(cherry picked from commit 0b3c20c)
    (cherry picked from commit bbd3aea)
  7. @dragos

    Merge pull request #77 from scala-ide/issue/code-completion-import-ba…

    dragos authored
    Issue/code completion import backport 1000855
  8. @misto

    Perform code-completion and import-adding in one step.

    misto authored
    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. @dotta

    Passing to -Xplugin a path containing whitespaces is finally parsed c…

    dotta authored
    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. @dragos

    Fixed a long-standing bug in the JavaScalaMapper, by adding an askOpt…

    dragos authored
    …ion when looking at TypeTree.symbol (cherry picked from commit 6a5d634)
Commits on Feb 20, 2012
  1. @dragos

    Fixing the build for Scala trunk. No more implicit conversions from S…

    dragos authored
    …tring to Name.
    (cherry picked from commit 876de6e)
  2. @dotta

    For no apparent reason, using `ScalaPlugin.defaultScalaSettings` is n…

    dotta authored
    …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. @dotta

    Override default when an explicit value is provided for `-XpluginsDir`.

    dotta authored
    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. @dragos

    Use File.pathSeparator when building the pluginsDir setting, to be pl…

    dragos authored
    …atform independent. Fixes #1000901.
    (cherry picked from commit 4ffdd09)
Commits on Jan 3, 2012
  1. @dotta

    Created bash script for signing the Scala IDE Eclipse plugin.

    dotta authored
    It needs some love, but it does the work. no review.
    (cherry-picked: 82421c5)
  2. @dotta

    Updated 'know issues' link in the 'Scala Setup Diagnostic' popup to p…

    dotta authored
    …oint to new location of the user documentation. no review.
    (cherry-picked: 9f539fc)
Commits on Dec 12, 2011
  1. @dotta

    Added 'org.eclipse.jdt.groovy.core' in Eclipse-SupplementBundle secti…

    dotta authored
    …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. @skyluc
  2. @skyluc

    Changed the Scala library/compiler version check

    skyluc authored
    It know checks at the major/minor level, not lower. And logs an error if
    it cannot find a match.
    Fix #1000793
  3. @dragos
Commits on Dec 8, 2011
  1. @skyluc
  2. @skyluc
  3. @skyluc
Something went wrong with that request. Please try again.