home

documentation

setup

releases

download

contributing

contact

Description

Mica is a common plugin architecture for creating Debian Linux and Maemo cross-development environments based on Eclipse.

Migration

This page covers in detail changes in the Mica architecture between releases in a form that should be useful both for migration from old patterns and for adaptation to new products.

Mica 2.0.0-I20090617

Templates and project wizards

The previous templates and project wizards were "kind of sort of" abstracted away from the Carbide template engine we primarily use. org.maemo.mica.common.project.core.ITemplate provided an abstraction to the template model, but the hierarchy of class wizards at org.maemo.mica.common.project.ui.wizards.AbstractProjectWizard very quickly started casting/adapting to the Carbide template to present the UI.

Now, this has been fixed. ITemplate can provide an adapter, org.maemo.mica.common.project.ui.adapters.ITemplateWizardUIAdapter, which provides the UI pages that are injected into a wizard.

Also, the end-user product wizards now have more flexibility in their template filtering. Instead of filtering basically on project type, wizards can use the ITemplate metadata directly.

(The previous template filtering model led to an unnecessary PluThon project type just because it looked like it was necessary to filter templates... yuck!)

Finally, the wizard hierarchy was modified, so that template wizards are the base for project wizards. This opens the door for a future file/class template wizard with a minimum of effort.

See the Templates and Project Wizards section of the Mica Architecture Guide for details.

Mica 2.0.0-I20090603

Launch configurations

Background

Mica provides several hierarchies of classes which allow you to hook up launch configurations to third-party debuggers and launchers, without rewriting a lot of code to perform file mapping conversions and validations and process launches.

Mica has support for C/C++ running and debugging with CDI and DSF debugger backends and for Python running and debugging in Pydev. In addition, it supports OProfile and Valgrind launches for C/C++ and Python.

org.maemo.mica.cpp.launch, org.maemo.mica.cpp.launch.cdi.gdb, org.maemo.mica.cpp.launch.cdi.dsf are the plugins with C/C++ support. These are in three plugins both to isolate backend dependencies and also to allow for DSF features to associated with its own feature (org.maemo.mica.cpp.dsf-feature TODO) since DSF is a separate product in CDT in Eclipse Ganymede and we don't to force it to be a dependency to the end user.

org.maemo.mica.python.launch provides the Python launch support.

In 2.0.0M4, all the launch configuration types, images, tab groups, and shortcut extensions were defined in Mica. This meant these shortcuts would be exposed in all products using Mica. I assumed at the time that any product would be able to use these launches without modification, and to a large degree this is true, except for product branding and filtering.

But we found with PluThon that it needed to filter out Python Maemo shortcuts with capabilities since it uses its own -- it does not have a split between "local" or a "remote" launch like in ESbox and the current target is used for remote launches; thus, it has some slightly different behavior and also wants to avoid the redundant "Remote" label in its shortcut.

Changes

I moved the C/C++ CDI and DSF and Python launch types, images, groups, and shortcuts out of Mica and put them into ESbox plugins (org.maemo.esbox.*.launch.*). These implement Abstract classes from in the Mica implementations. The only work done in the implementation is to return the real launch configuration type ID or to instantiate the corresponding launch shortcut. All the actual launch configuration delegate classes are provided by Mica (and should not need to be modified).

Similarly, the launch configs for OProfile and Valgrind (+Python variants) have been moved into product plugins for ESbox and PluThon.

As part of this refactoring, all the launch shortcuts and launch configuration tab groups are derived from a common tree of classes, and the launch shortcut's logic completely drives the behavior of creating a new launch configuration manually. A whole lot of redundant and sometimes inconsistent code was cleaned up this way.

Now that products must define the actual extensions, they are in complete control of which shortcuts/launches they expose and how they are branded. Mica provides all the common implementation for these, so products do not have to reimplement this logic. Mica's framework gives a unified model for providing defaults and names for launch configurations and allows launch shortcuts and UI to work the same.

See the Launching Model section of the Mica Architecture Guide for details.

Project types and builders

Mica has a model for distinguishing supported project types, like C/C++/Python, but these were not distinguished between products, and the versions in Mica were incorrectly called "ESbox". Thus, products like PluThon which have fundamentally different project types had to hide or filter out the core Mica types in order to provide its own.

Also, the build model was assumed to be identical to the project type -- e.g., that C/C++ would use autotools + make, and that Python would use Pydev. This presented a problem when deciding how to support Qt projects, which don't use autotools (but, like qmake, use make as a second step).

In this refactoring, this mechanism more clearly specified. The concept of a project type (typically, the language plugin that dictates the project model) and the project builder type (e.g., Make, autotools, or nothing) are specified and configured distinctly.

The main place this affects existing code is in the Carbide template extension point. You should specify the projectBuilderType metadata when defining a template:

<template
     templateId="org.maemo.maemosdk.cpp.templates.template.executable.emptyproject"
     displayName="Empty C Automake Project"
     groupLabel="Simple"
     filterArguments=".*"
     location="templates/EmptyProject/template.xml">
     <metadata name="projectType">org.maemo.mica.cpp.project.core.projectType.c</metadata>
     <metadata name="projectBuilderType">org.maemo.mica.cpp.project.core.projectBuilderType.autotools</metadata>
</template>

See the Project and Builder Types section of the Mica Architecture Guide for details.

Launch protocols

In a recent change, IP-based download methods ("launch protocols") in remote launch configurations are removed ([#3387]).

Along with this, I removed some assumptions in the org.maemo.mica.common.launch plugin about the kinds of launch protocols that exist and cleaned up the naming and ids and extension points for these.

See the Launching Model > Launch Protocols section of the Mica Architecture Guide for details.

Next steps

• Split packages into non-API and API packages
• Provide abstract base class implementations for any implementable interface
• Split ESbox plugin help into Mica and ESbox so PluThon can share.