Description
Mica is a common plugin architecture for creating Debian Linux and Maemo cross-development environments based on Eclipse.
| Maemo IDE Common Architecture
Integration releases
These are developer tested drop without full integration test. They are released more frequently than milestone releases and serve the demands of quick bug fixes and feature requests. Once a release is made, notes are moved into the "Detailed Changes" of that release page.
Download integration releases here.
Mica 2.0.0-I20090617
The goal for this sprint is to finish refactoring and provide a mostly stable API base.
- The template model and project wizard hierarchy were fixed to allow easier
extension for foreign engines, better template filtering, and use for the template
wizard in other non-project wizards.
See the Templates and Project Wizards section of the Mica Architecture Guide for details.
- Fixed some bugs with launch shortcut enablement. I had changed things to use the org.eclipse.core.resources.projectNature test, but this doesn't work on files or editor inputs. So I added org.maemo.mica.common.hasNature to do this correctly.
- Added property testers for more convenient launch shortcut enablement checks. The C/C++ and Python launches in several products and plugins had a long series of repetitive checks, which were destined to need changes in the future, so these were condensed into org.maemo.mica.cpp.isCppLaunchable and org.maemo.mica.python.isPythonLaunchable. These plus the product nature checks, and some maemo SDK checks for emulator/remote/x86/armel targets, are sufficient for any currently supported launch.
- Fixed an oversight with the Convert to Maemo projects wizards. The "Show up-to-date projects" checkbox only checked whether Mica recognized a project, but not whether the project is considered up to date for the wizard itself. (E.g. the "Convert to ESbox C/C++ project" wants to check whether the ESbox C/C++ nature is present; the check for a Mica C/C++ project type will succeed even without it.)
- Revamped the IProcessLauncher* APIs to reduce code size and make things more
consistent:
- Make the IProcessLauncherFactory#createProcessLauncher() API accept ProcessLauncherParameters instead of a list of current directory, command line, and environment.
- Remove ProcessLauncherCreator and instead have ProcessLauncherParameters
provide multiple #create(...) methods which take the same patterns as
it used to. So now the pattern is:
IProcessLauncherFactory factory = ...; IPath cwd = ...; List<String> cmdLine = CommandLineArguments.createFromVarArgs("ls", "-l"); IEnvironmentModifierBlock envBlock = ...; IProcessLauncher launcher = factory.createProcessLauncher( ProcessLauncherParameters.create(cwd, cmdLine, envBlock );or, in a more common case without environment block or current directory changes:
IProcessLauncherFactory factory = ...; IProcessLauncher launcher = factory.createProcessLauncher( ProcessLauncherParameters.create("ls", "-l") ); - Fix confusing behavior in IProcessLauncherFactory#defaultEnvironmentModifierBlock().
Previously, this returned a mutable block which a client could modify and which would "automagically" be used in a process launcher if no environment modifier block was passed explicitly. This kind of behavior meant that (1) the factory held state, and had to be recreated every time, and (2) it was confusing that passing either null or the modified environment block from #defaultEnvironmentModifierBlock() would have the same effect.
Now, the method is named IProcessLauncherFactory#getDefaultEnvironmentModifierBlock() and always returns a copy of the default environment changes. The client can change this but must pass this block to when creating the process launcher for the changes to be used. If a null environment block is passed, then the unmodified default environment changes will be used.
Also, this means that an ISDKTarget or IMachine may return the same IProcessLauncherFactory instance for #getProcessLauncherFactory() every time, which matches the documentation.
- Split unit tests so that Mica has product-independent unit tests. Product extensions may implement Abstract...Test classes to create their own unit tests. Note, however, that all the tests expect some product-specific extensions to be provided, especially sdk_provider so that SDK-specific tests can be executed.
-
Cleaned up the package arrangement of API and non-API code to spell out what is really
API and what is not. This distinction is spelled
out in the Mica Developer's Guide, are repeated here. In order of specificity:
- Packages named org.maemo.mica.internal.api.* should be used only by other Mica plugins or internally maintained products (ESbox, PluThon). Third-party plugins may use these, but there is no guarantee these will be stable, even from week to week.
- Packages named org.maemo.mica.internal.* may be used only by the same plugin. In some cases, unit tests use these as well, but these are explicitly exposed via "x-friends".
- Packages named org.maemo.mica.* are API. These will follow the standard Eclipse guidelines for APIs (so that binary compatibility is assured in the same major version). Note that the APIs will not be frozen until shortly before 2nd edition final.
- Refactored SDK manager related classes used to locate ISDK
and ISDKTarget instances.
- Rename SDKFactory to SDKManager, since this doesn't create things but manages them
- Provide a reduced interface via ISDKManager for the vast majority of uses (looking up SDKs and targets and attaching listeners). SDKManagerInternal can be used to get full access to SDKManager for use in internal API. This still exposes implementation details related to waiting for refreshing and/or force a refresh, and I plan to make this more predictable in the future.
- Provide symmetric #getAllSDKs() to #getAllSDKTargets()
-
Cleaned up GeneralUtils, splitting it into functional groups
(EFSFileUtils for file operations on IFileStore and IFileSystemAccess,
ProductUtils to retrieve the product name,
WorkspaceUtils to encapsulate some common Eclipse resource/seelection utilities)
- And move GeneralUtils itself to internal API for the messy leftovers
- Provide general method for getting the ".mica" path in MachineUtils#getTemporaryPath(IMachine)
- Ensure that the file-based methods in EFSFileUtils take IProgressMonitor
- Finish some progress monitor usage in Debian packaging, so we can actually cancel it.
- Move EnvironmentModifierBlock into API rather than providing long-winded and unnecessary creator function in EnvironmentManager
- Use PreferenceMigratorAdapter in our own implementations as recommended
- Started work on improving OProfile and Valgrind usability. OProfile now supports running for longer than one launched process (though there is a known issue that you must manually Stop the profiler if you launch a second process under profiling). [#4190] [#4191] [#4192]
- The Externalize Strings support now understands Python and Qt sources (though the latter is not hooked up to anything yet). [#4031]
Mica 2.0.0-I20090603
The goal for this sprint, in addition to fixing bugs after beta 1, is to make Mica more reusable by other IDEs. This is the first major round of refactoring to prepare for API stability after beta 2.
- Launch configuration refactoring. [#3354]
- Remove launch configuration extensions (which are currently ESbox-centric). Every product needs to define its own launch extensions now. See the migration guide for details.
- Make abstract classes for launch delegates, shortcuts, and tab groups useful for most purposes
- Unified the creation of launch configurations through ILaunchShortcut and launch configuration UI. [#3870], [#3854]
- Added method to IProjectType to determine what files are build artifacts for SSH/RSE launches for C/C++ and Python. This reduces a lot of redundancy in individual launches. This routine should also come in handy in the future for Debian packaging autogeneration.
- Removed the SSH IP-based launch protocol type. The SBRSH launch asks for an RSE connection now.
- Renamed the SSH and SBRSH launches to be clearer and modified internal logic to avoid relying on the name of the protocol. Updated the launch protocol type ids so they won't need to change due to future refactorings.
- Builder splitting. Make and Autotools builders are separated, so other Make-based
builders may be added. There is a new extension point projectBuilderType and
interface IProjectBuilderType to interact with builders for projects. These
are distinct from the language for the project. So now, Python projects can be built
from Debian imported packages.
ESbox and PluThon project natures were also split so that each uses a Mica Python project nature and a product specific nature on top. This pattern has been extended to C/C++ as well, to ensure that future users of Mica do not drag in ESbox dependencies or branding. [#3932]
See the Project and Builder Types section of the Mica Architecture Guide for details.
- Conversion wizard updates. The Convert to ... Wizards for ESbox and PluThon have been rewritten from scratch. They support a cleaner UI now and work for C/C++ or Python. The wizard will guess the correct project and builder type.
- Remove "ESbox" historical text references in source to avoid false assumptions that ESbox is "in" Mica still
- Fixed internal IDs of *.cpp.templates and *.python.templates so they don't use *.esbox.* in the ID
Non-refactoring related features and bugfixes:
- Remove IP-address based launch configurations [#3387]
- Improve SSH exchange keys support for SBRSH [#3827]
- Fix issues with "Run standalone" option being reset or initialized inconsistently [#4026]
- Add more Python code templates: GTK, multimedia, Hildon widgets, ...
- Fixes for Externalize Strings wizard: