Version 1
Created by phantomjinx on Jun 26, 2014 3:49 PM. Last modified by phantomjinx on Jun 26, 2014 3:49 PM.

    Random Development Conventions

    Plugin Naming

    • Most plugin code will make use of the Eclipse target platform. Those plugins that depend on Eclipse should be labelled as such, eg. org.komodo.eclipse.teiid.client;
    • Eclipse dependencies include the use of extensions points since these would require one of the Eclipse plugins;
    • Plugins that have no requirement for Eclipse dependencies should be suitably labelled, eg. org.komodo.utils.

    Messages and message.properties

    • A variety of ways are available for externalising strings, eg. using NLS. However, such methods can depend on Eclipse plugins and while this is fine for org.komodo.eclipse... plugins, it is problematic for other plugins since it forces an Eclipse dependency when none is required;
    • An example not requiring an Eclipse dependency is available here and here;
    • Whichever method is chosen, it is better to utilise either static constants or enums to represent the actual string values since these will display compile-time errors if they are accidentally removed.

    ErrorHandler for displaying errors

    • Since Eclipse has facilities for logging, it has been easy to just 'log' exceptions then forget them. However, they can really be forgotten since they get logged to the ${workspace}/.metadata/.log file and this is not frequently monitored;
    • Displaying errors requires a UI plugin so some kind of ErrorHandler is required that is located in a UI plugin but available for all plugins to utilise hence some kind of extension point will be needed for the connection plumbing.

     

    Minimum Teiid Version

    • Designer made great efforts to continue support for Teiid 7.7.x, based on JBoss 5.1;
    • Komodo with start with a minimum version of 8.7 but, where plugins have been ported from Designer, code can still support a minimum version of 8.0.x. This is a natural minimum due to a dependency on JBoss 7.x.

     

    Status and IStatus

    • The Status object and its interface IStatus are useful Eclipse classes for storing errors, warning and information;
    • Use of these classes depends on org.eclipse.core.runtime;
    • An alternative has been added to allow plugins that do not depend on Eclipse to produce the same behaviour without the Eclipse dependency - IOutcome;
    • The OutcomeFactory has methods for creating errors, warnings and info outcomes as well as the default 'ok outcome'. All methods return an IOutcome.