- 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.
parser combinator dependencies.
AspecJ has a new release in their /dev update site, with a different version of the weaving hook. We upgrade to this one to fix our builds. This is (probably) brought in as a transitive dependency from aspectj.runtime, and I couldn’t find a way to use the weaving.hook available in the release Luna repository (there is one there as well). We might investigate whether we should use the AspectJ release from the Spring Tool Suite (since that’s the most likely conflict we’ll ever have), at least until there’s a stable release of AJDT for Luna (none yet).
…uild. This commit “merges” the platform/luna branch into master, using separate source folders for the source-incompatible differences between the two platforms. In this way we don’t need to regularly merge master into Luna, and it makes it easier to use Luna for developing the IDE itself. * Changes that proved to be source-compatible, but only added in Luna, I merged them as-is (without relying on a separate source dir for those) * jdt.core versions in the manifest file are now replaced when they are copied using the maven-antrun plugin. The substitution is performed automatically, but the syntax is slightly different than for pure maven resources. It’s not ideal but there is no way to both substitute variables and rename a given file. * I made src-luna be the default in project definitions.
The Scala 2.11 feature for the 2.11 build has a reference to the bundled Scala 2.10 jar. We don't want this reference for the Scala 2.12 build. This will be removed when the need of the bundled Scala 2.10 jar is fixed.
Missing groupId cause the tycho-set-version plugin to fail with an NPE, see https://dev.eclipse.org/mhonarc/lists/tycho-user/msg04571.html (cherry picked from commit 2127604)
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.