riena emf dynamic views

Installation as redView – Team – Developer

Great: you like redView and have decided to help us 🙂

You need a special Eclipse Installation and Workspace described below in detail. You’re not sure if this is what you need ? Take a look at Installation site to learn about the different roles how to use redView.

Installation Instructions (1.0.0 – Helios SR1)

Mercurial – distributed version control system

redView uses a Mercurial Repository together with an Eclipse team Provider Plug-in ‘Mercurial Eclipse‘. If you don’t have installed Mercurial, here you can learn how to do this:

→ step-by-step install Mercurial on OSX, Ubuntu and Windows

redView’s Mercurial repositories are located at

  • SourceForge (our main repository)
  • Bitbucket (works as a mirror)
  • eclipseLabs (works as a mirror yet, but we plan to use eclipseLabs as main repository after some weeks of testing)

and can be accessed through ssh (read-write access) or through http / https (read-only) access.

If you’re about to start with redView development, you’ll only have read-only access. Your changes and enhancements can be provided as a patch to the redView team. Or create a fork and tell us about your fixes (Bitbucket supports this well).

If you’re a committer of redView you need ssh installed, because read-write access is only possible using a secure connection with ssh.

Here’s a detailed description how you can install ssh:

→ step-by-step: ssh on OSX, Ubuntu and Windows

As said above, you don’t have to install ssh if you only have read-only access to the repositories.

If you’re new to DVCS (distributed version control systems) or Mercurial – it’s a good idea to follow this blog series about Git and Mercurial before continuing.

Eclipse Helios EPP Modeling

redView 1.0.0 needs Eclipse Helios SR1 EPP Modeling (next major redView release version 1.5 will come out soon after Eclipse 3.7 – Indigo – in July 2011)

Download required software

The best fit for our installation is the Eclipse EPP Modeling Package. If you haven’t done this, please download the EPP Modeling for your operating system:

→ download Helios EPP Modeling Package

Expand the archive at a location where you normaly place your Eclipse Installations.

Edit Memory Allocation

Now edit the eclipse.ini to change the memory allocation (if you want) – the recommended memory:


On OSX it should look like this:

If you want to avoid the question about “install unsigned software”, then you can add


at the end of the eclipse.ini. read more about this here at Chris Aniszczyk blog.

Start Eclipse and select a new Workspace at a Location you like.

Edit Eclipse Preferences

Encoding and Workspace Name

Go to Preferences and edit the Encoding to UTF-8. It’s also a good idea to name your workspace, which is possible using Helios M7. As a redView team developer it’s usual to open more then one workspace, so naming each helps to distinguish.

OSX: Encoding must be changed:

Ubuntu: the default Encoding is already set to UTF-8:

Windows: Encoding must be changed

Software Sites

Please add the redview-team-developer updatesite:

Now we have to install new software.

Install New Software

Open menu  “Install New Software“. Please select the “–> redView Team Developer” site:

The checkbox ‘Contact all update sites…‘ must be selected.

Please select all redView Categories (Logging, Tasks, Tools, Mercurial) – and then hit Next – Next – Finish.

the operation can take some time - please be patient

It can again take some time to download all artifacts.

Then you have all what you need to work with:

  • Mercurial Eclipse
  • PDE Graph Visualization Dependencies
  • Neil Bartlett’s Bundle Monitor
  • Mylyn with Assembla Connectors. (redView uses Assembla as Issue Tracker)
  • XML, CSS, HTML, WebPage Editors
  • Logging with SLF4J

You have to restart Eclipse if all is done.

Prepare the workspace

Now its a good time to prepare the workspace for your work with redView.

Please add the Plug-in Perspective and go to this Perspective.

Go to Preferences Mercurial:

Under OSX hg is located at /usr/local/bin/hg.

You have to configure the Mercurial Preferences:

please uncheck the ‘prefer username value’ and enter your Default User Name as follows: yourCommitterName <yourMail@yourDomain>. Then Apply the changes.

There are some more Mercurial settings – but for now we can use the defaults:

It’s a good idea to show the Heap Status and also Source Plug-Ins:

redView Source Repositories

Now we’re ready to clone the redView Repositories into your workspace.

There are three repositories at redView’s SourceForge project:

  • redview/redview – all redView Plug-Ins
  • redview/deployment – all Features, Update Sites, Products etc.
  • redview/updatesites – a special repository containing all our deployed updatesites

There’s also a mirror at Bitbucket, where you also will find the three redView repositories:

  • redview – all redView Plug-Ins
  • redview-deployment – all Features, Update Sites, Products etc.
  • redview-updatesites – a special repository containing all our deployed updatesites

  • redview.redview – all redView Plug-Ins
  • redview.deployment – all Features, Update Sites, Products etc.
  • redview.updatesites – a special repository containing all our deployed updatesites

We’ll now clone the redview, deployment (optional) and updatesites (optional) repositories.

You only need the redview repository to have full access to redview’s sources and to test, launch or develop. Only if you’re interested into Features and Updatesites you need the deployment repository. Inside the updatesites repository you’ll find the deployed updatesites.

After cloning the file – structure of your workspace should look like this:

All Projects from repository redview/redview are under /yourWorkspace/redview, all projects from repository redview/deployment are under /yourWorkspace/deployment and all projects from redview/updatesites are under /yourWorkspace/updatesites.

Remember: you only need the redview repository to have access to redviews sources, target platforms etc.

Hint: If you later add projects to your workspace, you have to distinguish:

  • adding projects not under DVCS Control: as usual directly at the Root of your workspace
  • adding projects under DVCS Control:
    • change the location to <workspace-location>/repositoryname/projectname
    • per ex: /myworkspace/redview/

Clone redView Source Repositiores

Switch to Plug-in Development perspective and open the View “Mercurial Repositories“:

From this view we can create our Repositories:

To create the repositories we need the URL of this repository. Our Sources are hosted at Sourceforge, and there were also mirrors at Bitbucket and eclipseLabs. (If eclipseLabs has finished beta, then we’ll use eclipseLabs as our main repository)

Cloning from Sourceforge:

URL’s with read-write access:

URL’s with read-only access:

Cloning from Bitbucket:

URL’s with read-write access:

URL’s with read-only access: (you can also use…&#8230;)

Cloning from eclipseLabs:

its always the same URL – if you have read-only or read-write access depends from project settings. You have to use your eclipsLabs (GoogleCode) User Account as “login name” and your special password generated from GoogleCode for your:

Please copy/paste the URL into the View:

  • using http: you don’t need a Username or Password
  • using https (bitbucket): the username is automatically extracted and you need your password
  • using https (eclipseLabs): the Username is your eclipseLabs (GoogleCode) Username and the password is the special GoogleCode Password you’ll find in your account (see screenshot above)
  • using ssh: your username will be automatically extracted, you don’t need a password – Sourceforge or Bitbucket are using your public key.

Hint: if cloning using ssh fails, then please check if you are a developer with read-write access and if your public key on your machine is the same you’re using at Sourceforge or Bitbucket. If you connect the first time to the host from your URL on your machine, then you have to add Sourceforge / Bitbucket to the known hosts. Go to your terminal / commandline and enter: ssh or ssh

Important: if using ssh: uncheck the “Init Repository” checkbox !

Now your Mercurial Repositories View will contain some entries. In your case of course only one set of repositories from SourceForge, bitbucket or eclipseLabs:

To speed things up we change the workspace preferences temporarily :

Uncheck “Build automatically” and set “save interval” to a high value.

Now we’ll clone the redview/redview repository – please option-click on a repository entry:

and you’ll get this view:

You should use the defaults. Hit Next – after some seconds you get an overview of Branches, heads, Tags etc.

It’s the best to got to “Tags“:


Select what you need:

  • the newest released version or milestone (recommanded if you’re new to redView – at the moment 1.0.0 (Helios SR1) is newest one.
  • go to Branches to get the newest changeset from Indigo Branch if you’re committer and working on the latest snapshots (Warning: Eclipse 3.7 Indigo development just started)

Hit Next and after some seconds you’ll get the list of all projects from this repository – all are selected and that’s ok – we need them all.

To differentiate between projects from redview and deployment, please select a working-set:

Check the “add project to working set” and hit select. Then create a new Java working set named “redview“:

Hot OK to go back:

The hit Finish.

the operation can take some time - please be patient

This can take a while.

ATTENTION: wait until the progress bar does nothing !

Now you have all needed redView sources – if you don’t need deployment and updatesites you can switch to the next chapter “Set Target Platform” !

  • Using Sourceforge:
    • clone the redview/deployment repository
      • at default location deployment
      • create and select java working set “deployment
  • clone the redview/updatesites repository
  • at default location updatesites
  • create and select java working set “updatesites
  • Using Bitbucket:
    • clone the redview-deployment repository
      • change location to deployment
      • create and select java working set deployment
    • clone the redview-updatesites repository
      • change location to updatesites
      • create and select java working set “updatesites
  • Using eclipseLabs:
    • clone the redview.deployment repository
      • change location to deployment
      • create and select java working set deployment
    • clone the redview.updatesites repository
      • change location to updatesites
      • create and select java working set “updatesites
  • If all is cloned, set the Top Level Element in Package Explorer to Working Sets and configure them:

    Set Target Platform

    Now it’s time to set the Target Platform to get your projects compiled:

    Go into Working Set “redviewand open project

    Open folder


    Then Open the default Target Platform Definition:

    Double-click should automatically open the file in Target Platform Definition Editor:

    PDE is automatically resolving the Target Platform Definition.

    the operation can take some time - please be patient

    This can take a while.

    ATTENTION: Do nothing until progress bar does nothing and all is resolved !

    If all is done, check if there are no errors…

    Hint: if you’ve installed a newer Eclipse Version then RC3 and you got some errors, simply edit the updatesite-location and check the features you see on the screenshot.

    … then Click “Set as Target Platform“. This can take some seconds. If its ready you can close the Target Platform Definition File.

    Now we have to reset our Workspace preferences:

    After Applying this all projects should be compiled without any error 🙂

    Export Target Platform (optional)

    Since Helios M7 you can export your Target Platform’s to a local directory. This is great, if you want to install on more machines without waiting that eclipse fetches all the plug-ins. …or if you want to be sure that you can use the Target Platform even if there are some Sites not reachable or you have to work offline.

    Be sure, that the correct Target Platform is active, then go to “File Export -> Target Definition“:

    hit “Next” and select a folder where you like to store the exported Target Platform outside your workspace-repositories:

    hit “Finish” and all Plug-ins will be exported:

    you’ll get the Features, Plug-ins and content Repository.

    As next we need a Target Platform Definition for this – its very easy:

    Go to folder


    inside your project

    or any other place outside your Workspace repositories and create a new Target Definition:

    give it the name you want and start with “nothing“:

    we only have to add a Directory Location:

    choose the Directory where you have exported to before and hit Finish. All should be resolved well – please save and “Set as Target Platform

    One last step: if you placed the Target Platform under “local-configurations” we have to tell Mercurial, that this file isn’t under source control:

    Right-Click on the .target file, then “Team Ignore…

    …choose the first option to ignore only this one file explicitely.

    Now you’re using a local Target Platform from a directory – this will speed up the start. Don’t forget to reset if you need new versions – but this is now under your full control.

    Launch Eclipse Application

    The last we do to check if all went well is to start an Eclipse Application and to see if redView is running well.

    There is already a predefined Launch configuration. You’ll find them in the same project as the target platform definitions. please copy/paste the launch template into the folder “local-configurations” in the same project or into a folder you like outside the Mercurial repository. Now rename the *.launch_template into *.launch:

    Attention: because we don’t want your local launch configuration into the repository, please option-click “Team… Ignore…” to let Mercurial ignore this one:

    Please select the first option: Only this file should be ignored.

    Now open the Run Configurations… :

    … and you should find the Eclipse Application:

    This launch config is feature-based ( a new Helios functionality ) and should run on all platforms.

    Now you can “Run” the Application.

    Lets verify that all works  well. redView examples – Views should be found:

    – please open the “Actions” View:

    Great: redView has dynamically rendered a View.

    Now lets open an EMFStore Example View:

    There should be a message that no EMFStore Server is running – thats right. The View should open from a temp EMFStore.

    Please open two Views from EMFStore Server: EMFStore Browser and Unicase Navigator:

    The EMFStore Browser:

    (Redview localhost) is the temp repository redView created on-the-fly without running an extra Server.

    Unicase Navigator: shows all Views from EMFStore. Double click on one of them and the redView designer was opened.

    Great: redView Designer Editor works and also the EMFStore Server 🙂

    Now the last test: Open View “Plug-ins” and import a redView Example Plug-in as Source into the Workspace:

    The project should compile without an error. Then open a view from /viewstore:

    Double click on “ActionsExample.redview” should open the Designer Editor.

    Go to the Preferences of the launched Application to change redView – Look and Feel: Preferences -> redview -> themes:

    set to “light-blue“, “Apply” and the result should be visible in the Views:

    Great: Projects compile, Preferences with Look and Feel works.

    You’re done

    all looks good and you can start developing for redView 🙂


    1 Comment

    1. […] as redView Team Developer: cloned from Mercurial Repositories, installation instructions here […]

      Pingback by redView 0.7.4 (Helios M7) available « ekkes-corner: eclipse | osgi | mdsd | erp | May 16, 2010

    %d bloggers like this: