Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Sep 2, 2012
  1. @dragos
Commits on Aug 7, 2012
  1. @vigdorchik @dotta

    Use stock sbt 0.13 from eclipse

    vigdorchik committed with dotta
    * Move sbt to 2.9.2 for 2.9.x series.
    * Use short sbt.compiled.version for 2.10.x
    * Use full version of sbinary.
    * Fixed continuation plugin test: Continuations plugin is _not_ enabled by default in 2.10
Commits on Jul 27, 2012
  1. @dragos

    More abstract dealings with Scala compilation units.

    dragos committed
    We need a way to treat uniformly different kinds of Scala-based sources. Until now
    we routed everything through `ScalaCompilationUnit`, that extends the JDT `CompilationUnit`
    class. This tight connection is counter-productive, and in most cases, unnecessary.
    This commit is a step towards extracting a set of interfaces for other Scala-based
    sources to benefit of reconciliation ('errors-as-you-type'), hyperlinking and completion
    engine that already exists.
    * extracted `InteractiveCompilationUnit` as a super type of `ScalaCompilationUnit`
    * switched from `ScalaCompilationUnit` to `InteractiveCompilationUnit` wherever possible, to allow
    hyperlinking to work in the scala-worksheet project
    * added a utility method to retrieve the compilation unit associated with an open editor that
    uses the platform adapter protocol to allow other plugins to participate.
Commits on Jul 21, 2012
  1. @dragos

    Only react to part-closed events related to the current project.

    dragos committed
    This regression manifested by having a Scala compiler started on all Java projects when
    a file was closed. Annoyingly, that lead to the FailedCompilerInitialization window asking
    about adding the Scala library.
Commits on Jul 18, 2012
  1. @dotta

    Fixed exception occurring when deleting or closing a Scala project

    dotta committed
    Issue Description
    The issue was occurring only when a source was open in the editor and the
    corresponding project was deleted/closed. Apparently, when deleting/closing a
    project, any of its opened sources can still be reconciled (this only happens
    if you have the Java breadcrumb enabled in the editor). The problem with
    running the reconciler on a virtual source (i.e., the source does no longer
    exist in the filesystem) is that the reconciler participants (e.g., semantic
    and implicit highlight presenters) expect the source file to phisically exist.
    When that's not the case, a ``java.lang.IllegalArgumentException`` was thrown
    to the user's face.
    Implemented Solution
    The current fix is to check in ``SemanticHighlightReconcilationParticipant``
    that the compilation unit is linked to an existing (and currently opened)
    project (i.e., the project actually exist in the filesystem).
    Mind that this is actually *not* a proper fix, but a workaround. The problem is
    that the ``SemanticHighlightingReconciliation`` mantains a map of
    ``ScalaCompilationUnit`` to ``SemanticDecoratorManager``, and the map is not
    properly cleaned when a project is deleted/closed.  This is a memory leak and
    the only way I see to properly fix this is to completely re-work the way
    semantic highlighting is executed (Re #1001156).
    Furthermore, when a Scala project is about to be deleted, the Scala project is
    now disposed (i.e., the presentation compiler is shut down). This was not
    needed to fix the issue described in this commit, but it seemed a valid
    Unfortunately, the changes cannot be tested in a UI-less environment, hence no
    Fixed #1001058
    Integrated comments from pull #154
  2. @dotta

    Some code cleanup

    dotta committed
    * Removed unused methods.
    * Renamed ``Scalaproject.initialize`` into ``ScalaProject.initializeSettings``
    * Improved encapsulation of members.
Commits on Jul 13, 2012
  1. @dragos

    Fixed warnings.

    dragos committed
    - catching `Throwable` (in 2.10 only). I tried to make sense of each case, and where safe replace `Throwable` by a smaller type. Not always possible
    - unchecked warnings (in one case it was completely wrong) in pattern matches
    - missing cases in a pattern match
Commits on Jul 11, 2012
  1. @dragos

    Don't report nonexistent projects in `directDependencies`. The JDT ha…

    dragos committed
    …s a very annoying habit of
    caching dependent projects, and there's no way to clear that cache. I've seen the build fail because it
    thought it depends on a nonexistent project. Neither closing, refreshing or restarting Eclipse helped,
    so we filter it explicitly here.
Commits on Jul 4, 2012
  1. @dotta

    Refactoring in ``ScalaProject``

    dotta committed
    * Moved ``toString`` declaration.
    * Both ``javaProject`` and ``transitiveDependencies`` members declared in a single line.
    * Shortened references to ``ScalaPlugin.plugin`` to ``plugin`` alone.
    * Explicit type for API members.
    * Renamed a few methods to better express intent.
    * Improved members encapsulation.
    * Organized imports.
  2. @dotta

    Truncate too long build error messages displayed in resources' marker

    dotta committed
    Markers are a general mechanism for associating notes and meta-data with
    resources.  The Eclipse environments dictates that the text message passed to a
    marker should not be bigger than 21000 chars, or an assertion failure saying
    > Marker property value is too long
    is thrown on the user's face.
    The actual logic for resizing the build error problem passed to a marker
    already existed in two places. While the message passed to the created marker
    was correctly truncated in ``FileUtils.buildError``, it was not in
    As part of this commit, I've centralized the creation of resource markers in
    ``MarkerFactory``, and build problem markers are now created using
    ``BuildProblemMarker`` (it's a subclass of ``MarkerFactory```).
    More cleaning up could be done so that all markers are created only through
    sublcasses of `MarkerFactory``. Though, such a big refactoring seem too risky
    at the moment, as this commit will be merged in ``release/2.0.x`` branch.
    Fix #1001107
Commits on Jun 26, 2012
  1. @dotta

    Minor refactoring in ``testsetup`` classes

    dotta committed
    * Removed ``ScalaUnit`` type alias and replaced usage of ``ScalaUnit`` with ``ScalaSourceFile``.
    * Added explicit method's return type.
    * Changed signature of ``SDTTestUtils.addFileToProject``: the passed ``content`` is now an ```Array[Byte]`` instead of a plain ``String``.
    Note: This commit should be probably backported in 2.0.x branch
  2. @dotta

    Better implementation of ``ScalaProject.sourceFolders``

    dotta committed
    No need to traverse the collection twice.
Commits on Jun 18, 2012
  1. @dotta

    Better encapsulation of ``ScalaProject`` members

    dotta committed
    * Reduced visibility of methods
    * Removed unused member ``scalaProject``
  2. @dragos

    Merge pull request #117 from dragos/issue/separate-runtime-compiletim…

    dragos committed
    Correct handling of source Scala libraries on the class path.
Commits on Jun 14, 2012
  1. @skyluc

    Clean file handle on refreshing changed files

    skyluc committed
    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
Commits on Jun 12, 2012
  1. @dragos

    Correct handling of source Scala libraries on the class path.

    dragos committed
    If a dependent project provides a Scala library as source, use the output directory
    as the bootclasspath for the current project.
    Don't filter out the Scala library from the class path. This allows compiling the Scala library itself.
Commits on May 24, 2012
  1. @dragos

    Extracted classpath management into its own trait.

    dragos committed
    Extended the logic for finding the Scala library in source folders, and not to rely on the 
    JDT (and implicitly the presentation compiler being present).
Commits on May 17, 2012
  1. @dotta

    Merge pull request #108 from JamesEarlDouglas/master

    dotta committed
    Fix typo: "paramters"
Commits on May 16, 2012
  1. @dragos

    Fixed deprecation warnings for things that are deprecated since 2.9.0…

    dragos committed
    … and may be removed in 2.10.
Commits on May 11, 2012
  1. @earldouglas
Commits on May 10, 2012
  1. @dragos

    Use the configured JDK when instantiating the presentation compiler.

    dragos committed
    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
Commits on Apr 26, 2012
  1. @dragos
Commits on Mar 13, 2012
  1. @mdr @dotta
Commits on Feb 29, 2012
  1. @dragos

    Incorporated reviewer's comments.

    dragos committed
  2. @dragos
Commits on Feb 17, 2012
  1. @dotta

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

    dotta committed
    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 16, 2012
  1. @dotta
Commits on Feb 9, 2012
  1. @dragos

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

    dragos committed
    …atform independent. Fixes #1000901.
Commits on Feb 7, 2012
  1. @misto

    Merge pull request #65 from scala-ide/issue/move-class-refactoring-10…

    misto committed
    Issue/move class refactoring 1000422
Commits on Feb 6, 2012
  1. @misto

    Initial commit of the Move Class refactoring.

    misto committed
    You can either move a single class from a file with multiple definitions to its
    own file, or move the complete file. The package declaration will be updated,
    and the imports/references to the moved class are adjusted in the project. The
    refactoring is also involved when a source file is moved from the package
    Of course Move Class also works on Traits and Objects.
    Some restrictions: it works only on Scala sources, and not across multiple
    projects. Also, visibility issues that might arise are completely ignored.
    I also implemented Iulian's suggestion to filter the files in the project and to
    only create an index for those that contain the name of the class we move or
    rename. This speeds up renaming and moving considerably.
    Apart from the refactoring changes, I also had to change how existing
    compilation units are reconciled: When moving a compilation unit, the
    presentation compiler is reset and reconciles all the managed units. At this
    point, the moved compilation unit doesn't exist anymore, resulting in an
    Exception later on because the resource can't be found anymore. So now we only
    reconcile units that exist.
    Fixes #1000422, #1000836, #1000842
Commits on Feb 3, 2012
  1. @dotta

    Improved logging infrastructure and plugged Log4J in the…

    dotta committed
    We used to have too many alternatives to create log items (Eclipse Log
    framework, our ad-hoc naive internal Logger and println statements originating
    from scalac). In short, we did not have an ideal logging infrastructure.
    Now, I plugged Log4J as the backend logger (I'll refer to it as the "default
    logger" in the rest of this commit message), which replaces our naive ad-hoc
    Logger. Further, all log events occurring in the Eclipse Log Framework are now
    *forwarded* to the default logger. Also, the Standard Output and Standard Error
    are *redirected* to the default logger.  The  goal is to have a single place
    to consult the log, and that is now the *scala-ide.log* file that is produced
    by the default logger, located in
    It's easy to consult the log from within Eclipse, just open the Eclipse
    Preferences, then Scala > Logging, and there is a link to open the
    *scala-ide.log* file in the editor (though, mind that it is not automatically
    refreshed while it's open).
    From the same preference's page, you can also control the amount of produced
    log, i.e., you can set the log level that better suits you (the default level
    is WARNING).  If needed, you can also enable a console appender to print all
    produced log items in the console (this is quite handy when doing development
    on the Scala IDE sources).
    To get a handle on the loggers you simply need to mix-in the HasLogger trait,
    which contains a reference to both the default logger and the Eclipse Log. You
    may wonder why we have two loggers. The reason is simple, if you want to
    communicate a message to the user, you should use the Eclipse Log. This becayse
    messages sent to the Eclipse Log are shown in the Eclipse Log View (remember
    that all messages sent to the Eclipse Log are also forwarded to the default
    logger, so you don't need to log the same message twice). In all other cases,
    you should use th default logger.
    Finally, I removed the "plugininfo" option, which it was used to enable debug
    information in the ScalaIndexBuilder. As a matter of fact, the amount of logged
    information can now be easily controlled through Log Levels.
    One element I'm not happy with is that I plugged Log4J within the
    scala-ide.sdt.core project and not as an external plug-in. I've tried to do so
    but failed due to my lack of understanding of OSGi.  This is something that I
    believe we should do at some point (maybe someone can help with this?!).
    Fixes #1000880.
Commits on Nov 23, 2011
  1. @skyluc

    Re #1000764. Refreshing presentation compiler data

    skyluc committed
    Play 2.0 works fine in Scala IDE, except for the fact that information in the presentation compiler
    about file changed in the filesystem is not correctly updated.
    This change detect those changes, and trigger the presentation compiler.
    Cherry-picked from 795e18f
Commits on Nov 21, 2011
  1. @skyluc

    Tweaks for Re #1000757

    skyluc committed
    - configured the new marker ids as extensions, so they are visible in the UI.
    - recursively removed all marker in the projects with invalid classpath, and fixed the test.
  2. @dragos

    Better build error management, and cleaned up interactions between bu…

    dragos committed
    …ild, compiler settings,
    and class path validation errors.
    1. The class path validator deletes all Java and Scala error markers *only* when there is an
       class path error.
    2. Build errors, settings errors and class path errors have different marker IDs.
    3. Invalid setting errors are now reported. Until now they went unreported.
    4. Fixed #1000757.
Commits on Nov 13, 2011
  1. @dotta

    Replaced all calls to ScalaPlugin.check and ScalaPlugin.checkOrElse w…

    dotta committed
    …ith Utils.tryExecute.
    I believe the latter better describes the method's intention.
Something went wrong with that request. Please try again.