Implement the packaging of the plugin, embedding the backend server

[ymeine]

The plugin must be able to embed the code of the backend server and to launch and manage an instance of it properly.

For now it's easier for the Eclipse plugin to communicate with an already running backend instance, that is launched externally.

There is still some work to do to enable the plugin to launch a backend packaged with it, especially because it is developed externally.

There are two kinds of environments to consider:

• development: just have a quick and dirty solution to make it work in development mode
• production: make it work in the context of a packaged plugin

For development, the sources of the server are available, and can be put inside the project. Therefore to launch it ( without hardcoding paths!! ), there is just a need to resolve the relative paths inside the project (i.e. equivalent to programatically find the path of the project).

For production, the problem is different.

First, once installed, the plugin will reside in the Eclipse installation, among every other bundles. The thing would be - as it is for development - to resolve the path of the plugin (but in this case it's not in the context of the project but the one of the Eclipse installation). Have a look at FileLocator.find: the Bundle required in this method can be taken from the Activator class of this project.

But then there is a problem due to the fact a plugin is packaged in an archive by default. If the Java system works fine with binaries contained in archives, it is not the case of the externally made server. It relies on a standard file system access.

For that there are two solutions:

• either finding a solution to execute the server in a virtual file system - personally I don't know how
• or finding a solution to extract the files of the archive for the server. See this thread on stackoverflow talking about plugin packaging: an option to avoid archiving would be available in case we wrap the plugin in an Eclipse feature.

NB: to bring files from the backend project into the Eclipse Plugin project without versioning issues, Git Submodules can be used (I think this is more suitable in this case than the alternative solution to handle subprojects that are Subtrees)

[ymeine]

Update of the issue, please refer to this comment instead of the issue description

---

Recap of the issue

We would provide the plugin to users with a version containing a ready-to-work backend server.

While having an external, common backend installed can have some advantages — considering this configuration works properly (notably assuring that the current version of the backend remains supported by the plugin) — it should not be the only alternative.

Plugin installation with extracted backend

This is a requirement to be able to run the backend packaged along with the plugin.

In fact the export of the plugin is even more simple than that, Eclipse supports two forms of packaging for a plugin:

• a jar file having the name of the plugin
• a folder having the name of the plugin, whose content is exactly the one of the jar

Then it's just a matter of exporting it properly, and if this export is automated — and it should be — take care of configuring this task the same way. In any case, it should take care of not creating a jar archive but a simple folder instead.

Then, it depends on how the plugin is distributed. I don't know if the Eclipse update sites (see #16) require a jar version of the plugin, in which case we should configure the site to extract it at installation.

How to embed the plugin during export?

I don't know yet which technology to choose to automate this — Ant, grunt, ... — so I will focus on the theory.

1. Ideal solution

   The ideal solution would be if the backend had an available released package, with everything built, configured, and embedding all dependencies, including Node.js. Then it would be only a matter of downloading this package and extracting it in the chosen folder inside the plugin project.

2. Almost ideal solution

   If no backend package is provided but the latter's project provides all the tools to create one automatically, it's almost the same. There would just be an intermediate step where the project is cloned/installed, the tool is run, and the resulting package is taken to apply the ideal solution above.

3. Alternative solution

   If none of this is provided, we should do all this work ourself. This means:

   • installing the the project directly inside where we want it to be embedded
   • running the build script — at least we know it provides that
   • downloading the proper version of node

   This is not a big deal but it should rather be done on the backend side to avoid duplicating effort.

[ymeine]

Note that there is already a task in the backlog for the backend to create a build system: ariatemplates/editor-backend#21

[ymeine]

Please update this comment to develop the final solution instead of concealing it over multiple comments

Missing stuff

• add the fetch of node with the proper version: read package.json, get version requirements, download from official Node.js repositories (32 or 64 bits?)
• decide the file system layout to put node along with the backend code
• continue to specify how to access those files in the context of the plugin bundle

Final solution

Have files extracted in the plugin installation

#16 tells we will have to create a feature, so there is an option to do that.

Embed the server

Comment above indicates there should be something available from the backend to build it, but for the time being implement the third solution.

Solution 3 specifications

Requirements:

• git installed and in the PATH
• npm installed and in the PATH (make sure it is configured to work with an installation of Node.js)

Procedure:

# 1 ----------
# Create a temp folder, let's say 'temp'
cd temp

# 2 ----------
# Install the backend inside it, with the specified version
npm install https://github.com/ariatemplates/editor-backend#vX.X.X # of course replace with any git hash pointing to the wanted version

#3 ----------
# Build the backend
cd node_modules
cd editor-backend
npm run-script build

# 4 ----------
# Put the final result into the wanted folder: take the files directly, without the wrapping folder ('editor-backend')
# For instance, from the root of the project, inside 'resources/backend'

Of course this (incomplete) script is just to give an idea, it would be better to use an automation tool like grunt.js:

• install from npm: grunt-npm-install, or use the plugin just below since it's just a matter of running a command
• build the package by running shell commands: grunt-shell — however be careful with cross-platform issues! Especially to create files & folders for instance
• create folders: grunt-mkdir, even if it might not be needed. However creating a temporary folder could be safer.
• move final result where wanted: grunt-contrib-copy, grunt-contrib-clean to use official packages or grunt-rename otherwise
• download external resources, like node: grunt-curl

Access the server files during runtime

• Find the root URL of the backend like this: public static URL org.eclipse.core.runtime.FileLocator.find(Bundle bundle, IPath path, Map override), passing:
  • the Bundle instance from the BundleContext instance passed to the activator class: public Bundle org.osgi.framework.BundleContext.getBundle()
  • a IPath compatible instance pointing to the common root of the wanted resources