Migrate to new registry (v5.4.0 SNAPSHOT and above)

Migrate to new registry (v5.4.0+)

We have found several issues related to the old registry that led us to rewrite a brand new registry. This new registry is only compatible with Kevoree versions v5.4.0-SNAPSHOT and above.

What about that new registry?

The new registry replaces the old one at https://registry.kevoree.org and provides a REST API secured with OAuth2.
The registry is read-only for non-authenticated users, which was not the case before and could lead to untrustable Kevoree models. Authentication means that from now on you cannot publish Kevoree models generated from your projects without a valid Kevoree Registry Account.
In order to create an account, you will have to go to this page and follow the procedure there.

The Kevoree Registry Account

Your Kevoree Registry Account allows you to publish to a specific namespace which is a new concept that we brought to Kevoree.
By default, when you create an account on the registry it will also create a namespace with the same name as your login. The newly created account will be the owner of that namespace. Being an owner means that you are able to add and remove users from your namespace.
Users added as members to a namespace can also publish/modify the TypeDefinitions & DeployUnits of that namespace.

Example:

• "joe" creates a new account on the Kevoree Registry
• the registry automatically creates a new namespace named "joe"
• the registry sets the user "joe" as the owner of the "joe" namespace
• Joe can now publish his Kevoree models under the "joe" namespace

How to publish my models to the new registry?

• In order for the new Kevoree model generation grunt task ("grunt-kevoree-genmodel": "^3.0.0") to know about your namespace you have to specify it in your package.json file.

{
  "name": "your-awesome-module",
  "version": "1.2.3",
  "kevoree": {
    "namespace": "mynamespace"
  }   
}

• The Kevoree Grunt task for publishings has been updated ("grunt-kevoree-registry": "^3.0.1") in order to communicate with the new registry's REST API.
  In order for the task to authenticate itself, you will have to specify a Kevoree config file

What does it change for the KevScript

TypeDefinitions in v5.4.0+ are now part of a namespace. The de-facto namespace, if you do not specify one in your KevScript, it will be kevoree. If you want to specify another one (ie. mynamespace) you will have to prepend your TypeDefinition name with: mynamespace.

// example of namespaced TypeDefinition
add yourNode.yourComp: mynamespace.MyTypeDefinition

The default namespace being kevoree, you do not have the specify it for standard libraries:

// no need to prepend "kevoree." before JavascriptNode
add node0: JavascriptNode

In the end, the KevScript interpreter will automatically add "kevoree" as namespace when none are specified. So add node0: JavascriptNode and add node0: kevoree.JavascriptNode have the same behavior.

More explainations

The new registry comes with a new way to handle versioning.
Now the TypeDefinition and the DeployUnit versions are independent and have to be specified in the KevScript.
Before you used to write something like:

add node0: JavascriptNode
add sync: WSGroup/5.3.2

This meant that you wanted the "latest" version of the JavascriptNode but you wanted to specify an exact version of 5.3.2 for the WSGroup.
This led to issue because of the cross-platform nature of Kevoree. The 5.3.2 version had to be the same for every platform (ie. you had to have a 5.3.2 version on Maven AND on the npm registry for Java & JavaScript). So in the end it forced you to increment and re-publish your components on every platform anytime you wanted to add a fix (even thought the fix was only for one of the platform)

Now with the new registry you can do something like that:

add node0: JavascriptNode
add sync: WSGroup/1/RELEASE

You can still specify nothing add node0: JavascriptNode which means that you want the registry to do get the version for you. And so if you do not specify anything, the registry will take the latest TypeDefinition version and the latest released version of that TypeDefinition.
But for the WSGroup here, we want to be precise, so we tell the registry that we want the version 1 of the WSGroup TypeDefinition and we want the latest RELEASE version of that type (ie. not a -SNAPSHOT or -alpha)

Remember that Kevoree is SemVer based?

The overall idea with this new behavior is to let the registry resolve versions for us without hard-coding them in the KevScript.

Short form	Equivalent in long form	Meaning
JavascriptNode	JavascriptNode/LATEST/RELEASE	The latest JavascriptNode type using the latest released version available
JavascriptNode/LATEST	JavascriptNode/LATEST/RELEASE	The latest JavascriptNode type using the latest released version available
JavascriptNode/LATEST/RELEASE	JavascriptNode/LATEST/RELEASE	The latest JavascriptNode type using the latest released version available
JavascriptNode/42	JavascriptNode/42/RELEASE	The version 42 of the JavascriptNode type using the latest released version available
JavascriptNode/42/RELEASE	JavascriptNode/42/RELEASE	The version 42 of the JavascriptNode type using the latest released version available
JavascriptNode/42/LATEST	JavascriptNode/42/LATEST	The version 42 of the JavascriptNode type using the latest version available (including development versions)

Code modifications

Because the TypeDefinitions have to specify a version then we have to specify it in the code so that the model generator can know about the version.
TypeDefinition versions are INTEGER so you should not put float numbers here.

var AbstractComponent = require('kevoree-entities/lib/AbstractComponent');

var HelloWorldComp = AbstractComponent.extend({
  toString: 'HelloWorldComp',

  // this is what you have to add to specify your version
  tdef_version: 1,

  start: function (done) {
    console.log('Hello World!');
    done();
  }
});

module.exports = HelloWorldComp;

It is our job to specify the version using tdef_version, and it is also our job to increment it if we modify the TypeDefinition of our components. By doing so we enforce type checking because the publication tool (grunt task) will not let us publish a modification to an already published TypeDefinition unless we increment the version.
This brings reliability to the Kevoree TypeDefinition system.