Eclipse Kura Developer Experience

Getting started with Eclipse Kura can seem daunting for new developers. For this reason there have been several attempts at simplifying the getting started process. Unfortunately, not all of these methods have been fully explained or maintained. This document will offer a summary of the different methods along with pros and cons. Ideally, we use this document as a resource to reduce the options for getting started as to better support new developers.

For the remainder of this document, 'developer' will refer to developers interested in contributing to Eclipse Kura while 'user' will refer to developers creating applications using Eclipse Kura APIs.

Developer Environment

The default method for setting up a developer workspace is here. This process involves cloning the Eclipse repo, building with Maven, importing into Eclipse, etc. This has been the standard method for new developers since the release of Kura.

Pros:

• It is well understood by the existing development team
• It leads to a deep understanding of how Kura is assembled

Cons:

• It is complicated and error prone, likely leading to fewer committers

User Workspace

The User Workspace was the original method for users to get started with Eclipse Kura. The User Workspace is created during the build process and distributed as a Zip archive. The contents of the archive include:

• P2 repository containing all artifacts needed to develop applications against Kura and to run the local emulator.
• Local emulators in the form of Eclipse launch files (for OSX and Linux).
• Example projects

Pros:

• Easy setup, the application developer only has to import the archive into Eclipse and set the target definition.
• The local emulators provide a nice environment for testing Kura inside of Eclipse

Cons:

• The setup does not offer guidance in setting up Maven or CI builds
• The launch configuration files are difficult to maintain and keep up to date
• The setup only works with the Eclipse IDE

Oomph

The new method for installing the Eclipse IDE is through an installer based on Oomph. This installer can not only install the IDE, but also install pre-defined software projects based on setup files. Jens added a setup to the Kura repo that allows for setting up either a developer environment or user environment. Instructions for using Oomph can be found here.

Pros:

• Vastly improved setup for developers. The installer installs the IDE, downloads the Kura Git project, imports the project, builds the project, and sets the target platform.
• The setup is controlled through a single file maintained in the Github repo. This should allow for tighter control of pesky system references (i.e. emulator launch files).
• In theory, a developer or user could work almost entirely in the Eclipse IDE. I suppose this could also be a con, but we will leave it as a pro for now.
• This is the direction of the Eclipse IDE for the foreseeable future. Jens already has Eclipse Kura listed in the installer, which is great.

Cons:

• Obviously this is also Eclipse IDE specific. Likely not a big deal for developers as I think enforcing Eclipse practices (i.e. Tycho builds) is acceptable. However it doesn't help users wishing to use IntelliJ, etc.
• The installer installs a completely fresh version of the Eclipse IDE. Again, this could be considered a pro, but I am not so sure.

Yatta Profile

Yatta Profiles are a way to manage Eclipse Oomph installs. Yatta is very similar to Oomph, so a full description is not provided. The largest issue with Yatta is that the configuration is maintained at a user level (i.e. your eclipse login). This means that the setup files cannot be stored in a repository, but instead maintained by individuals. The Yatta project is looking into this, but until this is addressed this is a non-started for the Kura project.

Maven Archetypes

Maven Archetypes are a way to create generic templates for users through a single Maven command. A first pass of this in the Kura project was to create a "New Project" archetype that would setup the scaffolding for a new OSGi bundle project that included a maven build with DP generation. More investigation should be made into this as combining Archetypes with other proposed features (Maven Central, hosted P2, etc) could make this a powerful utility. TODO: How to use