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

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

    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)
    skyluc committed Mar 14, 2012
Commits on Mar 6, 2012
  1. Build the IDE using 2.0.x p2 repo for scalariform and scala-refactoring.

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

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

    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)
    dotta committed Mar 5, 2012
  4. Fixed problem if typing braces at EOF.

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

    - 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)
    skyluc committed Mar 5, 2012
Commits on Mar 5, 2012
  1. Removed useless distinction between `hasErrors` and `hasBuildErrors`.…

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

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

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

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

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

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

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

    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)
    dotta committed Mar 1, 2012
Commits on Feb 24, 2012
  1. Fixed a long-standing bug in the JavaScalaMapper, by adding an askOpt…

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

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

    …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.
    dotta committed Feb 20, 2012
  3. Override default when an explicit value is provided for `-XpluginsDir`.

    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.
    dotta committed Feb 20, 2012
Commits on Feb 9, 2012
  1. Use File.pathSeparator when building the pluginsDir setting, to be pl…

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

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

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

    …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
    dotta committed Dec 12, 2011
Commits on Dec 9, 2011
  1. Changed the Scala library/compiler version check

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

    added to the scala perspective list of views.
    created a 'Scala' view group.
    Fix #1000791
    (cherry picked from commit e866172)
    skyluc committed Dec 8, 2011