Skip to content

How to upgrade a development environment

Jump to bottom
Fernando Dodino edited this page Dec 8, 2019 · 17 revisions

Useful tips for upgrading a development environment

In order to prepare a new development environment you should find

  • the latest version of Eclipse
  • the latest version of Xtext
  • any new version of Xpect

Eclipse

As a rule of thumb, we always prefer Eclipse for Java Developers because Eclipse DSL environment has older versions than recreating the environment manually.

Xtext

Xpect

Generating a new product

Eclipse uses p2 repositories which contain bundles of jars, and Wollok uses Tycho as a plugin for using those p2 repositories in a target platform and generate the final product (so you don't have to sync Maven and p2 repositories).

So, if you want to succesfully build a product, you must look for the latest bundles and the right p2 repositories (common failure is that you are looking for a newer version of a component in an old repository, or you try to use two versions of the same component)

Maven, Tycho P2 Architecture for Wollok

Which files you should take into account

You can point to this commit as the first step to collect the files you should review whenever you want to upgrade.

Target platform file

  • org.uqbar.project.wollok.targetplatform/
    • org.uqbar.project.wollok.targetplatform.target

In this target platform file you locate p2 repositories and bundle jars, specially Xtext, EMF (Eclipse Modeling Framework), MWE/MWE2 (Modeling Workflow Engine), Xpand & Eclipse components (like SWT, GEF), and also JUnit, Xtend, EGit, Xpect... You must take care of locations & versions, based on this recommendations.

To accomplish that you should take a look at Eclipse Bundles Migration Support. You'll find there FAQs, incompatibilities,a and advises for migrations from latest version to the new one. If you are upgrading from 4.8 to 4.12, you should take a look at 4.9, 4.10, 4.11 & 4.12 release notes. This is the starting page for migrations and here is the deprecated API log.

An advise is to use locations where you can use a feature with no specific version:

<location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit">
  <unit id="org.eclipse.equinox.sdk.feature.group" version="0.0.0"/>
  <unit id="org.eclipse.emf.mwe2.launcher.feature.group" version="0.0.0"/>
  ...
  <repository location="https://download.eclipse.org/releases/2019-09/"/>
</location>

instead of

<location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit">
  <unit id="com.google.guava" version="27.1.0.v20190517-1946"/>
  <unit id="org.apache.commons.collections.source" version="3.2.2.v201511171945"/>
  <unit id="org.apache.commons.collections" version="3.2.2.v201511171945"/>
  <repository location="http://download.eclipse.org/tools/orbit/downloads/drops/R20190827152740/repository/"/>
</location>

Product file

  • org.uqbar.project.wollok.updatesite/wollok-product.product

The product file is the configuration used for generating the user-end product (the Wollok the students will use). changeVersions.sh file will update the current year & version, but you should also take care of initial configuration settings, like

  • showing line numbers
  • using GTK for Linux product
  • the min and max initial heap

and a very important thing: the plugins Eclipse should start on initialization. This could cause a succesfull build but a crashing Eclipse start, so remember the link Eclipse Bundles Migration Support, because we've found equinox.ds bundle was preventing Eclipse start even if the build was ok, and previously a failing build because of <plugin id="org.eclipse.ecf.provider.filetransfer.httpclient4"/> having been removed.

Maven files

  • org.uqbar.project.wollok.releng/pom.xml: upgrade Xtext & Tycho versions for main release engineering (releng) project
  • org.uqbar.project.wollok/pom.xml: if there's a change in MWE (Modeling Workflow Engine) version

MANIFEST.MF files

  • All MANIFEST.MF files should change the component versions. If there's a possibility, you should avoid setting a specific version and trust target platform one. The more you do that, the less you'll need to change it every time you upgrade.

Additional information

These are must-see pages if you plan to release new products:

And also take a look at:

Clone this wiki locally