1. The Scala Developer's Perspective
2. The Plugin Contributor's Perspective
3. Technical Documentation
Before reading this page, you may want to have a look at the description of the Build Process for one ecosystem
An extra profile has been added to the project's top
pom.xml. It is used to set strict dependency to Scala Library and Scala Compiler. It is trigger in the general build script if the system variable
SET_VERSIONS is set to any value.
It should be enabled when creating a version to be added to the ecosystem. It can be run like this:
SET_VERSIONS=true ./build-all.sh <your normal parameters>
The next subtree is a staging zone, meaning forthcoming versions of the Scala-IDE plugin are built into the
next hierarchy of the Scala-IDE team's repositories. Note that for one specific forthcoming release (its stable, milestone or RC status notwithstanding), there are usually several versions of the Scala-IDE artifact : one for every (Eclipse × Scala) version we are currently supporting.
This subtree serves as a pre-release emplacement for plugins authors to test the forward-compatibility of their plugins. When a release occurs, the contents of that repository are merged into the root repository of the server (using the Merging tool). The layout of those repositories is described in Plugin maintenance and update.
When a new version of Scala-IDE has been flagged for a release , it needs to be folded from
/next/<site_path>/base into the
<site_path>/base update site. It can be done using the Merging tool.
First, duplicate the current
mvn -Drepo.source=http://download.scala-ide.org/ecosystem/<site_path>base -Drepo.dest=~/tmp/ecosystem/base package
Then, merge in the new version of Scala IDE:
mvn -Drepo.source=http://download.scala-ide.org/ecosystem/next/<site_path>/base -Drepo.dest=~/tmp/ecosystem/base package
Finally, the resulting folder needs to replace on the web server.
next/subtree contains a single version of the Scala-IDE for a given flavor. That version is overwritten when a new candidate for release appears, not during the release.
next/reproduces the folder layout for
Here are some hypothetical examples, assumed to happen in
chronological order, with stable releases postfixed with
|I have just pushed||to||contents of /next/.../dev/base||contents of /next/.../stable/base|
|Scala-IDE 2.01-final||/next/<site_path>/stable/base||Scala-IDE 2.01-RC3||Scala-IDE 2.01-final|
|Scala-IDE 2.02-M1||/next/<site_path>/dev/base/||Scala-IDE 2.02-M1||Scala-IDE 2.01-final|
|Scala-IDE 2.02-RC1||/next/<site_path>/dev/base||Scala-IDE 2.02-RC1||Scala-IDE 2.01-final|
|Scala-IDE 2.02-final||/next/<site_path>/stable/base||Scala-IDE 2.02-RC1||Scala-IDE 2.02-final|
next, the root subtree retains previous versions of a plugin as well as previous versions of Scala-IDE. The only deletion rule is that for a given flavor (i.e. Eclipse/Scala/Scala-IDE version), only the latest version of a given plugin will be retained.
base site has been updated, the ecosystem build has to be performed again, in order to create whatever plugins can be based from it. The plugin managers that have in the feature site which points to a plugin that can build on this new Scala-IDE release will automatically get the appropriate new version of their plugin. Note that a plugin that had versions built against the
next/base hierarchy right before release fit into that category. When this build is done, users can use the site to install or update to the new version.
The Scala SDK build uses the ecosystem sites by default. It will automatically pick the latest version of Scala IDE and Scala Worksheet.
When the build is done, the content of
org.scala-ide.product/target/repository has to be merged in the existing
base site. The steps are the same as for Scala IDE.
As for Scala IDE, the ecosystem build has to be run after the
base site has be updated, so the new product is available for update.