- There is a common problem when definitions should be shared that are defined in plugin fragments. It turned out that this is necessary for the test fragments. They define some reusable test classes which should be accessed in other test fragments. Because these test classes are only defined in fragments but not in their corresponding plugins, it is not directly possible to access them. However, by defining the property Eclipse-ExtensibleAPI: true in the `MANIFEST.MF` of a plugin, the Eclipse builder allows to access fragment definitions at compile time. More information about this property can be found at http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html Other solutions and a more in depth explanation to the class sharing problem can be found at https://rcpquickstart.wordpress.com/2007/06/20/unit-testing-plug-ins-with-fragments/ - The above solution of adding the `Eclipse-ExtensibleAPI` does only work for the Eclipse builder but not for our build tool maven. In order to allow maven to access the classes of fragments one has to put the property jars.extra.classpath = platform:/fragment/<id> to the `build.properties` of the fragment that needs to access another fragments' definitions. `<id>` has to be replaced with the plugin id of the fragment, whose definitions should be accessed. - The `build.properties` of a plugin should include the current directory (represented as .) in the `bin.includes` property. If it is not included there, no classes are put into the output directory. In Eclipse itself, one does not get a warning about that, but the maven build fails because it can't find the classes.
The Scala IDE used to package the continuations plug-in to match the Scala distribution. While this conveniency was appreciated by the few using continuations in their projects, it imposed a technical debt on the Scala IDE codebase (have a look at how the compiler `Settings` used to be instantiated). Recently, the continuations plug-in has been refactored and splitted into two separate JARs (a compiler plug-in, and a library). After this modularization, the Scala IDE codebase could no longer be compiled inside Eclipse because the continuations library isn't included in the project's classpath. Of course, we could implement a workaround to restore the functionality, but it just doesn't seem worth the time, considering the Scala Team has deprecated the continuations plug-in and will effectively drop supporting it the moment 2.12 is released. Hence, the decision of dropping the out-of-the-box support in the Scala IDE. From now on, if you want to use continutions in a project, you will have to provide the location of the continuations JAR via the -Xplugins setting. Finally, a couple of tests exercicing the behavior of both the presentation compiler and the build compiler when compiling a sourcefile that requires the continuations plug-in are now executed only for Scala 2.11 or later. This is needed because the continuations.jar is no longer loaded when starting the compiler inside Eclipse, and that turns out to affect semantic of programs using continuations in Scala 2.10, because the compiler does no longer report an error if a source file (requiring continuations) is compiled without passing the flag to enable the plugin. Why? Because up until Scala 2.10 the compilation error is reported by the continuations.jar (!!). Of course, that error cannot be reported if the continuations.jar isn't available anymore (which is the whole point of this commit). The behavior with Scala 2.11 is different because the continuations library has been moved out of the scala library (see scala/scala@858a5d5), and hence a compilation error is reported whenever a source is compiled without the continuations library in the classpath. That explains why the tests are now only executed on 2.11+. This commit undos all changes related to supporting continuations made by @adriaanm in #604 Fix #1002012 Fix #1002011
Split the dependencies along the scala-2.10.x and scala-2.11.x profiles. The goal is to evolve the 2.11 module structure to get a leaner set of dependencies on Scala Core, with a separate Scala Modules container. Support the 2.11 swing/continuations modules: Rename `continuations.jar` to `scala-continuations-plugin.jar`. In 2.10 this was called `continuations.jar`, in 2.11 it's `scala-continuations-plugin_2.11.jar`, and the library part is distributed separately, so add that to the Scala container. TODO: add scala-xml and scala-parser-combinators to the scala container and to the repl classpath (These dependencies should move to the Scala Modules container eventually.) Fix the outputDirectory-es of scala-(refactoring|swing) Plugin goes to lib/. Long live XML copy-paste reuse.
- added Scala compiler sources - added xml and combinator versions only in the 2.11 profile - removed useless dependency on HasLogger - removed exported dependencies from sdt.core project files - removed superfluous version numbers in dependencies - fixed runtime library for build-tools to always be 2.10
* toolchain is used only to build sbt * all Scala-related dependencies are resolved through Maven * bundles not needed for execution (scala-swing, continuations, various source attachments) are added to sdt.core * features need an extra step, because in 2.11 we need to ship two extra bundles (xml and parser combinators). This is done through the new -Pset-features profile in build-all.sh As a bonus, all Scala bundles have correct source attachments now, so plugin development should be much easier. Fixed #1001889.
This commit allows debugging, hyperlinking, etc. towards sbt sources. Useful when working on the Sbt builder. * create a source bundle for the sbt library. I needed to inline the contents of sbt jars in order to get Eclipse to correctly associate sources with classfiles * created a new compiler.interface bundle, only for the compiler interface, together with the matching `compiler.interface.sources` bundle. Sbt requires this to be a separate jar and there was no way to build a single sbt bundle with only some of the dependencies inlined. A similar approach could be used for the Scala library/compiler bundles, but we should investigate the possibility of having the Scala team publish source bundles too (Re #1001889). (this was originally a commit from @dragos, which I have adapted based on the comments in #482) Fixes #1001888
After the major rewrite of our maven build (SHA-bfc88fd04d80d68760e43dbe60b638c314280f0d), the `release-build-ide-29.sh` is henceforth useless (and worse, it's not even working anymore because the `release-ide-29` maven profile does no longer exist in the POMs). Now, to build the IDE (for instance, for Scala 2.10.0-M6), the following plain maven command is enough: > ./build-all.sh -Dscala.version=2.10.0-M6 -Drepo.scala-refactoring=http://download.scala-ide.org/incoming-release-210/dependencies/scala-refactoring -Drepo.scalariform=http://download.scala-ide.org/incoming-release-210/dependencies/scalariform -Dversion.tag=m2 -Pscala-2.10.x clean install Note that the above command assumes that you have produced the p2 repository for both our dependencies (scalariform and scala-refactoring).
The new launch delegates are added to the Equinox weaving launch configurations, if available in the Eclipse setup. Fix #1001158
Made the dependencies of library, compiler and sbt optional, so they don't have to be excluded later. Moved the 'allowConflictingDependencies' option to the projects which require it (feature and site). It is needed because of the mix of versions for the elements coming from the m2 repo. Removed the dependency to aspectjrt (not needed) Cleaned-up an invalid property definition in sbt.full.library. Created properties for all plugin version numbers Fixed typo Fixed git location Added parameter to the p2 repositories ids
No bash script needed anymore. Everything is managed through maven. The new pom at in root folder contains version information and general configuration. org.scala-ide.build-toolchain is the root of the toolchain part org.scala-ide.sbt.build is the root of the sdt part The version numbers of some plugins has been upgraded The downloaded libs have been moved to the target/lib folders, to simplify the clean up process. The first time, run './build-all.sh (or './build-all.sh install -P scala-2.10.x' for 2.10) from the root to generate an initial build and install the top pom locally. Then use maven from any project or subproject. Use the scala-2.10.x profile ('-P scala-2.10.x') to compile the 2.10 version. Re #1001056