Migrating icCube : 1.3 to 2.0

This section explains the differences introduced in the version 2 of icCube. First of all, let's clarify the main two directories mentioned in this page:

  • the installation directory (referred to $install hereafter) : this is where the icCube binaries are installed,
  • the application directory (referred to $app hereafter) : this is the place where a running instance of icCube server is storing its data (e.g., users, roles, cubes, etc...). Upon the very first startup of icCube this directory is created and initialized with the content of the $install directory.


The two versions of icCube can be installed side-by-side on the same machine and no file will be removed during the installation of icCube v2.0.


The configuration file is: $install/bin/icCube.xml. The version 2.0 is different from the previous one. But unless you've edited the 1.3 file, there's no need to migrate this file. For more information, have a look to this file that is self-commented. The most notable changes are the default name of the $app directory (i.e., no more a hidden file) and the new entry for the report server configuration.


You can skip this section if you've not defined any users nor roles in the 1.3 installation as starting (for the very first time) icCube 2.0 will initialize properly default users and roles.

The definitions of users are backward compatible and can be reused; copy the $app/users/icCubeUsers.icc-users from your 1.3 server (~username/.icCube-1.3/users) into the 2.0 server (~username/icCube-2.0/users).

The definitions of roles are not backward compatible and cannot be reused as such; copy the $app/roles/icCubeRoles.icc-roles from your 1.3 server (~username/.icCube-1.3/roles) into the 2.0 server (~username/icCube-2.0/roles) and add the 'reportDocManagement' entry (an example is available in $install/bin/icCubeRoles.icc-roles) into each defined role.


The schema/cube definition files are backward compatible and can be reused. You'll have to manually import those files using the UI or for a faster setup you can copy them directly both into the $app/builder and the $app/cubes directory. The /builder directory contains the schemas being edited into the builder application whereas the /cubes directory contains the deployed (i.e., potentially loaded) schemas. You can safely ignore the *.rev directories during this copy (they're used internally to keep an history of changes).

Javascript Visualization Library (GVI)

Next chapter : 2.0 to 2.0.1.