Skip to main content
Jump to: navigation, search

Difference between revisions of "OSEE/Developers Guide"

(Build Steps)
(Build Module Hierarchy (from highest to lowest))
Line 744: Line 744:
===Build Artifacts===
{| border="1" cellpadding="1"
! Path !!  Artifact !! Description
| rowspan="2" | plugins/org.eclipse.osee.client.all.p2/target/ || repository/ || OSEE IDE Client P2 Site
| || OSEE IDE Client P2 Archived Update Site
| rowspan="5" | plugins/org.eclipse.osee.client.all.product/target/products/ || build_label.txt || OSEE Build Information
| || OSEE Client IDE All-In-One Linux x86
| || OSEE Client IDE All-In-One Linux x86 64-bit
| || OSEE Client IDE All-In-One Win32 x86
| || OSEE Client IDE All-In-One Win32 x86 64-bit
| rowspan="4" | plugins/org.eclipse.osee.x.server.p2/target || repository/ || OSEE Application Server P2 Site
| server/ || OSEE Application Server
| || OSEE Application Server Archived Update Site
| || OSEE Application Server Zipped Runtime
====OSEE System Requirements====
====OSEE System Requirements====
*System with at least 1GB of RAM  
*System with at least 1GB of RAM  

Revision as of 19:26, 3 April 2012



Client Architecture

The central feature of OSEE is an extensible framework called the OSEE Application Framework. Default applications distributed with the OSEE framework are OSEE Define (for requirements management) and OSEE ATS (the Action Tracking System, for configuration management).

OSEE ArchitectureThe Application Framework provides all the necessary services to allow the applications to persist and share data in a common, version controlled object database. Just as Eclipse provides the ability to add a plugin to the existing Eclipse environment, so OSEE allows other applications to add plugins and share the common data store.

And just like Eclipse RCP allows an application to be built and deployed using the Eclipse framework but not include all the standard applications like JDT, OSEE allows an application to be built and deployed using the OSEE Application Framework without including such applications as OSEE Define and OSEE ATS.

Client/Server Architecture

In order to attain a greater degree of scalability, the Open System Engineering Environment (OSEE) has been slowly migrating into a distributed architecture where clients interact with an application server, which is in charge of managing access to an OSEE data store.

Additionally, in an effort to provide load balancing, failure recovery, and code compatibility, clients consult an arbitration server before connecting to an application server. The arbitration server's responsibility is to keep track of all the application servers interacting with a common data store and direct clients to a healthy application server compatible with the client's OSEE code version. In this arrangement, arbitration servers act as the initial access points into the OSEE server cloud where a collection of application servers manage client requests to access and operate on a common OSEE data store. Figure 1 shows an example of the OSEE Client/Server network.

Figure 1

In Figure 1, three application servers interact with a single OSEE data store. The data store is comprised of a relational database and a remote file system used to store binary data. It is not necessary for the database and the binary data to exist on the same machine; the only requirement is that the application servers have access to both resources. Upon start-up, each application server registers himself on the data store's server lookup table by entering its host address, port, supported code versions, and its unique id. When the arbitration server receives a request to find an application server to support a client connection, the arbitration server reads the data store's server lookup table and selects the best match for the client. The client requests this information from the arbitration server upon start-up or whenever it can't communicate with an application server. It is important to note that the arbitration server does not have to be a different server than an application server. All application servers are able to act as an arbitration server. An application server is referred to as an arbitration server when clients interact with it in this context. Figure 2 depicts the sequence of events involved in the arbitration process.

Figure 2

Once a client receives an application server's address and port information, the client must authenticate with the application server before it can gain access to the OSEE data store. During the authentication process, a client submits to the application server the current user's credential information and the authentication protocol id to use during the process. The application server verifies the user via the selected protocol and grants access to the data store by creating a session for the user. From this point forward, the application server will be responsible for managing access to the data store by identifying the user via the session id. Whenever a client wants to interact with the application server, it will need to submit its session id in order to gain access to the OSEE data store. Figure 3 shows the sequence of events involved in the authentication process.

Figure 3

Data Model

The OSEE framework is built around a user configurable and extensible data model consisting of attributes, artifacts, and relations. An attribute is a key-value pair representing a single data element such as a description, a date, a number, or a file. These basic data elements are grouped into artifacts. Artifacts can be configured to have any number of attributes. By default, an artifact will always have an attribute of type name. In addition, artifacts can be related to one another via relations. By default, an artifact will always have a default hierarchy relation type. This allows artifacts to be connected together in a tree. In the example below, two instances of the basic artifact type are shown. Artifact 1 has an attribute of type name set to string data "X". Artifact 2 has an attribute of type name set to string data "Y". These two artifact instances are related via the default hierarchy relation type. Artifact 1 is Artifact 2's parent artifact.

Basic artifact.png

Now that we have a basic understanding of the model, lets take a closer look at attributes and how they are defined.

An attribute is defined through its attribute type. The attribute type is a blue print for constructing attribute instances. It defines the type of data the will be held by the attribute, the data source or who provides it, how many instances can be created, default value to use during creation, whether the attribute can be tagged for word searches, and if the attribute holds file data, its file extension.

By default, data contained in the attribute can be represented through OSEE's basic data types:

  • String Attribute
  • Boolean Attribute
  • Integer Attribute
  • Floating Point Attribute
  • Date Attribute
  • Enumerated Attribute


OSEE provides three attribute data providers: the default attribute data provider, URI attribute data provider, and the Clob attribute data provider.

  • The default attribute data provider is used for data containing less than 4000 characters in length. Data is stored and retrieved from the OSEE relational database. Most attribute types will use this data provider to handle its data content.
  • The URI attribute data provider is used for large data. The provider communicates to the OSEE application server to store and retrieve data.
  • The Clob attribute data provider is a hybrid provider using both the OSEE relational database and the application server to retrieve and store data. When the data contained by the attribute has less than 4000 characters, the provider uses the relational database. If the data exceeds the 4000 character limit, then the application server is used.

Configuration Properties

OSEE can be configured by setting certain Java system properties when launching Eclipse and by setting various attribute values on the Global Preferences artifact in the datastore. Java system properties are key/value pairs and can be passed as launch arguments in the form of -D<key>=<value> (i.e. -Dosee.authentication.protocol=trustAll). These -D options can be specified directly in the command to launch Eclipse or in the corresponding .ini file for the eclipse executable used.

Datastore Preferences (via Global Preferences artifact)

Do a Quick Search on the Common branch for "Global Preferences" and open the resulting artifact in the artifact editor. The available attribute types for this artifact define what can be configured. Each attribute is self-documenting, because the attribute tip text documents how to use each one.

Common Java System Properties

System Property Name Values Default Description [FILE SYSTEM PATH] File system path or uri containing custom database connection information. <db identifier> Default from db.connection file Specifies which database OSEE should connect to. This id references connection information specified in the ...db.connection.xml file. Refer to the Database Connection Information section for more information. true, false false If true, adds the lookupList to the global lookup list such that a refresh will try to locate the service again
osee.jini.lookup.groups user defined group name the Jini Group that all OSEE provided Jini services will register with
osee.log.default FINE, INFO, WARNING, SEVERE WARNING the default logging level for all loggers
osee.port.scanner.start.port 1 - 65535 18000 the first port number to test for availability when a new port is needed

Application Server Java System Properties

System Property Name Values Default Description
org.osgi.service.http.port 1 - 65535 -1 Port the client will use to communicate with the OSEE Application Server [FILE SYSTEM PATH] User Home A directory on the file system to be used by the application server to store and serve artifact binary data.
osee.db.embedded.server [<address>:<port>] When specified, this system property sets the URL used to launch an embedded database server. [FILE SYSTEM PATH] User Home A directory on the file system to be used by the application server to store and serve artifact binary data.
osee.version [<"version 1">;<"version 2">] When specified, this system property sets the application server's supported client versions. NOTE: version string can use regular expressions
osee.check.tag.queue.on.startup true, false false When specified, this system property allows the application server to check the tag queue and begin tagging and pending tag jobs.

Client Java System Properties

System Property Name Values Default Description
osee.application.server <address>:<port> When specified, this system property sets the URL used to reference the application server and arbitration is bypassed.
osee.arbitration.server <address>:<port> The arbitration server address and port to use. This system property must be specified for the system to gain access to OSEE data. If the application server property is set then that address takes precedence and arbitration is bypassed.
osee.authentication.protocol protocol name protocol to be used by the client to authenticate with the server
osee.choice.on.db.init choice name the predefined database initialization choice
osee.file.specified.schema.names.on.db.init true, false false Specifies whether OSEE database initialization should use the schema names specified in the schema.xml files instead of using the connection schema. Using the connection specified schema is the default behavior. [FILE SYSTEM PATH] Specifies where table data should be imported from during OSEE database initialization. The default is to use the database connection id specified in the schema.xml files.
osee.import.on.db.init true, false false Specifies whether OSEE database initialization should import database data as part of its tasks.
osee.local.application.server true, false false When set to true launches an application server upon start up. Uses org.osgi.service.http.port arg to determine port to use.
osee.local.http.worker.port <port> Port Scan starting from 18000 Port to use for local worker server.
osee.prompt.on.db.init true, false true Specifies whether to interactively prompt the user during database initialization for init choice
osee.record.activity true, false true Specifies whether user activity should be logged
osee.ote.benchmark true, false
osee.ote.cmd.console true, false Specifies whether to enable the OTE command console
osee.ote.server.title free text name name given to the OTE server which is displayed in the test manager
osee.ats.ignore.config.upgrades true, false

Developer Workspace Configuration

Import Java Code Auto Formatting Preferences

  1. Start OSEE
  2. File-->Import...
  3. Select General/Preferences
  4. Click Next >
  5. Click Browse and navigate to (and select) the file [workspace_root]\org.eclipse.osee\plugins\\osee_team_preferences.epf
  6. Click Open
  7. Check Import all
  8. Click Finish

Configure New Code Template Preferences

  • Window-->Preferences
  • Java/Code Style/Code Templates
  • Code/New Java Files
  • Click Edit...
  • Paste the following (or some variant).  Be careful not to modify the template variables, i.e.: "${package_declaration}":
 * Copyright (c) 2012 Boeing.
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * Contributors:
 *     Boeing - initial API and implementation
 * @author Joe P. Schmoe
  • Code/Catch block body
  • Click Edit...
  • Paste the following (or some variant):
OseeLog.log(Activator.class, Level.SEVERE, ${exception_var});

Database Connection Information

To define a custom database connection for the application server, a path to an xml with the following format is required when launching the application server. This path will need to be specified using the and JVM arguments on launch.

<?xml version="1.0" encoding="UTF-8" ?>

<DatabaseInfo id="postgresqlInfo" >
  <DatabaseHome key="#DBHOME#" value="DATABASE HOME LOCATION" />
  <DatabaseName key="#DBNAME#" value="DATABASE NAME" />
  <DatabaseType key="#TYPE#" value="postgresql" />
  <Prefix key="#PREFIX#" value="jdbc:postgresql" />
  <UserName key="#USERNAME#" value="DATABASE USERNAME" />
  <Password key="#PASSWORD#" value="DATABASE PASSWORD" />
  <Host key="#HOST#" value="@AvailableDbServices.hostAddress" />
  <Port key="#PORT#" value="@AvailableDbServices.port" />

<ConnectionDescription id="postgresql" >

  <Server id="ANY NAME" dbInfo="postgresqlInfo" 
          hostAddress="DATABASE IP ADDRESS" port="DATABASE PORT" 
          connectsWith="postgresql" isProduction="false" />

The sample file above defines PostgreSql connections but it can be changed easily to define oracle or H2 connections.

The file is divided as follows:

  • Database Info: This entry describes the database to connect to by defining the database name, database home location and user name (or schema) and password to use during connection. When using the OSEE PostgreSql installation instructions, the fields should be set to the following:
    • DATABASE HOME LOCATION: not used therefore remove the value field from this attribute
  • Connection Description: This entry describes how the database connection url should be assembled. At connection time, the fields enclosed in ## are substituted with the information defined in the database info section. There shouldn't be a need to change this unless you want to connect to a database other than PostgreSQL.
  • Available Database Services: This section contains entries for each database server and connection option needed at launch time. An entry is referenced at launch time by calling out the entry id in the argument. When using a local OSEE PostgreSql install, the attributes on a server entry should be set to the following:
    • id: any meaningful name to identify this entry
    • hostAddress: localhost
    • port: 5432 (the default PostgreSql port)
    • isProduction: false unless you want to prevent clients from initializing the database

Custom Data Model

The data model in OSEE is extensible and user configurable. Users can define new artifact, attribute, and relation types and their constraints such as multiplicity and applicability. Type inheritance allows similar types to be defined and modified without tedious redundancy because similar types inherit what is common from their super type.

The OSEE data model is defined using a tabular format involving 5 tables. See the following link for an example.

The full data model can be defined using a single spreadsheet or be divided among multiple spreadsheets that can reference types defined in any spreadsheet.

Artifact Type Table

Column Name Description
Artifact Type Name any valid UTF-8 characters with a max length of 75 bytes
Super Type Name The super artifact type from which this type will inherit associated attributes and relations. Another concrete artifact type or an abstract one that exists only in data model definition.

Artifact Factory

When defining new artifact types, by default, the Java class used to create the artifact at runtime is org.eclipse.osee.framework.skynet.core.artifact.Artifact. When a specialized subtype of Artifact is desired, the extension point org.eclipse.osee.framework.skynet.core.ArtifactFactory can be used to contribute an artifact factory that extends the class org.eclipse.osee.framework.skynet.core.artifact.ArtifactFactory. The factory's isResponsibleFor(String artifactTypeName) method determines if a particular factory will be used to construct an artifact of a given artifact type. Thus the artifact factory extension point can be used to case user defined artifact types to be constructed at runtime using a custom Java class that extends Artifact.

Attribute Type Table

Column Name Description
Attribute Base Type

Fully qualified java class name of a class that extends org.eclipse.osee.framework.skynet.core.attribute. The typical and simplest case is to specify one of the built-in types:

  • org.eclipse.osee.framework.skynet.core.BooleanAttribute
  • org.eclipse.osee.framework.skynet.core.CompressedContentAttribute
  • org.eclipse.osee.framework.skynet.core.JavaObjectAttribute
  • org.eclipse.osee.framework.skynet.core.DateAttribute
  • org.eclipse.osee.framework.skynet.core.FloatingPointAttribute
  • org.eclipse.osee.framework.skynet.core.IntegerAttribute
  • org.eclipse.osee.framework.skynet.core.StringAttribute
  • org.eclipse.osee.framework.skynet.core.EnumeratedAttribute
  • org.eclipse.osee.framework.skynet.core.WordTemplateAttribute
  • org.eclipse.osee.framework.skynet.core.WordWholeDocumentAttribute

If a custom java type that extends Attribute is needed, then that type should be specified here.

Attribute Data Provider The attribute data provider is responsible for storing and retrieving attribute data. Fully qualified java class name of a class that implements org.eclipse.osee.framework.skynet.core.attribute.providers.IAttributeDataProvider. org.eclipse.osee.framework.skynet.core.DefaultAttributeDataProvider may be used when the data to be stored does not exceeded 4000 bytes, otherwise org.eclipse.osee.framework.skynet.core.UriAttributeDataProvider may be used.
Attribute Type Name Any valid UTF-8 characters with a max length of 500 bytes
File Extension Any valid UTF-8 characters with a max length of 50 bytes; only applies when using the org.eclipse.osee.framework.skynet.core.UriAttributeDataProvider
Tagger ID If the attrbiute’s content is to be included in the search index for the quick search, use DefaultAttributeTaggerProvider, otherwise leave blank.
Default Value The initial value given an attribute upon initialization, this may be left blank
Validity Xml For the attribute base type org.eclipse.osee.framework.skynet.core.EnumeratedAttribute, specifies the valid enumerations. For example, <Page_Type><Enum>Portrait</Enum><Enum>Landscape</Enum></Page_Type>
Min Occurrence The framework with prevent having lest than this number of this attribute type on a single artifact
Max Occurrence The framework with prevent adding more than this number of this attribute type to a single artifact
Tip Text Text to describe an attribute. Any valid UTF-8 characters with a max length of 4000 bytes

Artifact Type / Attribute Type Mapping Table

Column Name Description
Artifact Type Name Exact name of an artifact type defined above (or previously)
Attribute Type Name Exact name of an attribute type defined above (or previously) to be associated with the corresponding artifact type

Relation Type Table

Column Name Description
Relation Type Name Any valid UTF-8 characters with a max length of 50 bytes
Side A Name Descriptive name for the A side of the relation. Any valid UTF-8 characters with a max length of 50 bytes
A to B Phrase An optional phrase that describe the relation between the artifacts from the side A perspective. Any valid UTF-8 characters with a max length of 50 bytes
Side B Name Descriptive name for the B side of the relation. Any valid UTF-8 characters with a max length of 50 bytes
B to A Phrase An optional phrase that describe the relation between the artifacts from the side B perspective. Any valid UTF-8 characters with a max length of 50 bytes
Short Name Five or less characters is typical. This abbreviated name is used in the user interface when space is at a premium
Ordered Yes to have artifacts on the same side of this relation type use a user defined ordered, otherwise No

Artifact Type / Relation Type Mapping Table

Column Name Description
Artifact Type Exact name of an artifact type defined above (or previously)
Relation Type Exact name of an relation type defined above (or previously)
Side A Max An artifact of type "Artifact Type" can be on side "A", "Side A Max" number of times for relation links of type "Relation Type"
Side B Max An artifact of type "Artifact Type" can be on side "B", "Side B Max" number of times for relation links of type "Relation Type"

Importing an OSEE Data Model

To import changes to the data model for an existing OSEE database:

  1. In Package Explorer, Select a file(s) containing the OSEE data model to import. If there are any enum overrides, you must select them either explicitly or by import statement (hierarchically).
  2. Right click and select Import...
  3. Under the OSEE category, select OSEE Types
  4. Ensure that all types files are included in Resolved dependencies and Report Changes is checked. Select Finish.
  5. Review all tabs to ensure that all changes are expected.
    1. Osee Default Enum will always show up on OseeEnum Types tab
    2. Ensure each column's data is correct. All "true" values are what is being changed.
  6. When ready to persist changes, you must restart the client (Still Necessary??) and only run import once with Persist Changes checked

To automatically import the data model during database initialization use the extension point org.eclipse.osee.framework.skynet.core.OseeTypes

OSEE Branches

OSEE Branches

Workspace Setup

Workspace Setup

Downloading and Configuring Eclipse

Downloading and Configuring Eclipse

Working with GIT

Working with Git


JUnit Method Rules:

Rule class Reason
Checks if the Artifact Cache is clean
public class MyTest {
   public MethodRule oseeHousekeepingRule = new OseeHousekeepingRule();

   public void testArtifactChangeName() throws Exception {
      //Arifact change name code

Location of OSEE Bundles

Location of OSEE Bundles

Migrating Branches to Another OSEE Database (including from previous OSEE version)

  1. From the source application server's osgi console: export_branch myExportFolder
  2. The results will be placed in <user home>\Exchange\myExportFolder
  3. Zip the resulting folder and save it for possible reuse
  4. Run database initialization on destination database

eclipsec -application org.eclipse.osee.framework.database.init.configClient -vmargs -Xmx512m -Dosee.log.default=INFO -Dosee.application.server=http://localhost:8089 -Dosee.authentication.protocol=trustAll -Dosee.prompt.on.db.init=false -Dosee.choice.on.db.init="Base - for importing branches"

  1. Import any custom types into the destination database
  2. From the destination application server's osgi console: import_branch <user home>\Exchange\myExportFolder
  3. From the application server run tag_all
  4. Restart destination application server
  5. Start corresponding OSEE client

Configuring ATS for Change Tracking

Configuring ATS for Change Tracking

Custom OSEE Operations using BLAM

the extension point org.eclipse.osee.framework.ui.skynet.BlamOperation can be used to contribute a custom OSEE operation that provides the developer a very quick way to define the graphical interface that supplies the operation with the user specified parameters. org.eclipse.osee.framework.ui.skynet.blam.operation.ChangeArtifactTypeBlam provides a simple example.

Event Handling

General Design Considerations

  • Event Handlers should run VERY quickly
  • A private implementation is more secure
  • Separate classes == maintainable but potentially costly
  • Ensure each listener is safeguarded from other listeners (wrap in event handling)


  • Need local client events and remote events to other clients
    • Local event model should be abstracted from remote model so app code doesn't change
    • Remote events should be versioned so event service can know how to handle
  • Need to handle events where artifact or relation is not in client's cache, but event may still matter
    • Client can't load every artifact to determine if it's desired
    • Registration needs to be at base level guid,artTypeId,branchId so these can be filtered out without loading all artifact data.
  • Need to provide lowest level registration (branch, artType and possibly even attrType) so event msgs reduced
  • Need to support versions of remote events so remote event model can change without causing exceptions
  • MUST have regression tests that are light-weight and easy to run so event service doesn't break
  • Since Artifact, Relation, Attribute types are dynamic, can't create static message model/brokers
  • Since artifact/relation/branch caches must be updated PRIOR to events propagate to GUI
    • Need priority listeners for caches to update prior to UI updates
  • Applications should be able to define their own higher level events while still listening to lower level events

Event Handling Revelations

  • Reduce the necessity of events as much as possible - Restful
  • Data injection to keep caches up-to-date a complex/impossible solution for enterprise, multi-client, multi-server operations
  • All clients MUST be connected to event service if connected to database/app service
  • Applications shouldn't have to know what events to handle, but instead presented all the events to handle
    • Don't have separate purge, modified, change type events, but instead Artifact listener that has change types of purge, modified, deleted, change type, etc
  • Since artifacts/relations are cached, application to application events are prone to errors if cache not updated yet

Event Handling Ideas / Goals

  • How could we have a version for each artifact so clients could know if they are up-to-date or missed an update and reload-all. This would allow for self-healing.
  • Reduce the items in the cache by improving our use of weak references. Anything not in the cache, doesn't have to get updated
  • Move configurations that have to be loaded by all clients to the server. Branch and type caches already there. Users and ATS Config could go there.
  • Is there a way to have events go straight to UIs (Editors, Views) to see if anyone cares that the cache is updated before updating the cache?

OSEE Event Handling - Current

  • Design Issues
    • Communication mechanism - Jini
      • Clients are not connecting
      • Clients not staying connected
    • Event System
      • Events are at the data level; applications are required to turn high level operations (eg: save, transition) into low level data events (30 attributes modified, 10 relations added, 5 deleted) which are sent across the wire to another client to re-assemble into a high level operation.
      • Registration is for too high a level, each editor,view has to process through all events to find ones they care about
      • Have to filter between loaded and unloaded artifacts and handle them differently so as not to accidentally load everything
      • Have to register/handle separately for deleted versus purged
      • Two levels of registration for artifacts/attributes/relations, by transaction and by dirty. By dirty is too much information, but necessary sometimes. By transaction is ok, but have to filter through all un-necessary stuff to find what want. Dangerous and costly.
      • Access control is not handled in events
      • Not extensible, so applications can't create/propagate their own events
  • Registration
    • ArtifactPurgedEvent
    • FrameworkTransactionEvent
    • RelationModifiedEvent
    • BranchEvent

OSEE Event Handling - New

  • Registration - Need lower level registration of framework events
    • By Artifact (branch, guid)
    • By Object Type (artifact, attribute, relation) - include inheritance
    • By Mod Type (added, modified, deleted, purged)
    • By Transaction (persist to DB of group of changes)
    • By Combinations (Artifact type and relation type or Artifact type and attribute type)
  • ArtifactEventManager
    • Sends BasicGuidArtifact for each mod type
    • Modification Types: Purged, Added, Modified, Deleted, Change Type, Access Control
    • Allow registration with filters
      • ArtifactGuidFilter - only sends event if artifact is affected
      • BranchGuidFilter - only send event if artifact on this branch is affected
      • ArtifactTypeGuidFilter - only sends event if artifact of one of these types is affected
  • BranchEventManager
    • Modification Types: Added, Deleted, Purged, Access Control, Renamed
    • Allow registration with same filters as Artifact
  • Remote events are different and versioned classes so abstract from framework events
  • Created via jaxb

Event Model

Remote Events

  1. Remote events classes are auto-generated via jaxb which keeps toXml, fromXml implementation hidden and thus requires less junit tests for base clasess.
  2. Each class is versioned by name (1, 2, 3). When RemoteBranchEvent1 changes, will create RemoteBranchEvent2 so there is no conflicts and implement backward compatibility that will
    1. Create RemoteBranchEvent2 events when RemoteBranchEvent1 are received - for old clients
    2. Create RemoteBranchEvent1 events when RemoteBranchEvent2 are received - for new clients
  3. Current classes:

Framework Events / Listeners

  • ArtifactEvent
  • BranchEvent
  • BroadcastEvent
  • AccessControl?? - Potentially roll into ArtifactEvent
  • TransactionDeleted?? - Potentially roll into ArtifactEvent

Use Cases

  • Artifact Editor
    • Current Design
      • Registration = All Branches, Mod Types, Object Types
      • Handling
        • If not branch, throw away
        • If unloaded, ignore
        • If loaded refresh/update all
        • If relation, refresh relation tree
        • If attribute, refresh attribute tab
    • New Design
      • Registration = One guid and relations for that guid
      • Handling
        • If relation, refresh relation tree
        • If attribute, refresh attribute tab
  • Artifact Explorer
    • Current Design
      • Registration = All Branches, Mod Types, Object Types
      • Handling
        • If not branch, throw away
        • If unloaded, ignore
        • If loaded refresh/update all
        • If relation, get parent and call tree.refresh()
        • If attribute (name only), call tree.update(element)
    • New Design
      • Registration = One branch, One relation type, All Object Types
      • Handling = About the same, but don't have to filter through un-necessary stuff
  • SMA Editor - Edits single team workflow, but watches related tasks, reviews, user assignments, etc
    • Current Design
      • Registration = purged, relation modified, framework transaction, branch event. NOTE: Should register by branchId (Common), guids of workflows, artifact types (eg. don't care about general document artifact type changes on common)
      • Handling
        • If not Common branch or in transition, ignore all artifact/relation/attribute changes
        • If is purged/deleted, close editor
        • If is modified, deleted, relChanged, relDeleted, relAdded of main artifact, redraw pages
        • If related review is any of above, redraw pages
        • If relation modified, dirty editor
        • If branch event and working branch added, deleted, purged, committed, redraw pages
    • New Design
      • Registration - One branch, 12 artifact types
      • Handling = About the same, but don't have to filter through un-necessary stuff


Building OSEE using Tycho/Maven

Build Requirements

  • Java Runtime Environment (JRE) 1.6 or higher
  • Maven 3.0 or higher

Build Steps

  1. Download and install Maven. See for installation details.
  2. Download the OSEE source code from Git Web Client (see clone section for more information] or
    Note: Tycho/Maven build support available for source code versions 0.9.9_SR6 and higher.
  3. Download and unzip 3rd party dependency P2 archived site:
  4. Build commands:
    1. cd org.eclipse.osee/plugins/org.eclipse.osee.parent
    2. mvn clean verify -Declipse-ip-site="file:<PATH TO 3rd PARTY P2 SITE>"
    3. If you run into any problems (to display debug and stack trace info)
      mvn -e -X verify -Declipse-ip-site="file:<PATH TO 3rd PARTY P2 SITE>"
Assuming the following layout:

machine@user /UserData/org.eclipse.osee/plugins/org.eclipse.osee.parent:
$mvn clean verify -Declipse-ip-site="file:../../../org.eclipse.ip.p2_1.0.0.v201203200040-DEV"

Build Module Hierarchy (from highest to lowest)

  1. org.eclipse.osee.parent
    1. org.eclipse.osee.ide.parent
      1. org.eclipse.osee.client.all.parent
      2. org.eclipse.osee.client.parent
      3. org.eclipse.osee.ote.parent
      4. org.eclipse.osee.runtime.parent
    2. org.eclipse.osee.x.parent
      1. org.eclipse.osee.x.server.parent
      2. org.eclipse.osee.orcs.parent
      3. org.eclipse.osee.x.core.parent

Build Artifacts

Path Artifact Description
plugins/org.eclipse.osee.client.all.p2/target/ repository/ OSEE IDE Client P2 Site OSEE IDE Client P2 Archived Update Site
plugins/org.eclipse.osee.client.all.product/target/products/ build_label.txt OSEE Build Information OSEE Client IDE All-In-One Linux x86 OSEE Client IDE All-In-One Linux x86 64-bit OSEE Client IDE All-In-One Win32 x86 OSEE Client IDE All-In-One Win32 x86 64-bit
plugins/org.eclipse.osee.x.server.p2/target repository/ OSEE Application Server P2 Site
server/ OSEE Application Server OSEE Application Server Archived Update Site OSEE Application Server Zipped Runtime

OSEE System Requirements

  • System with at least 1GB of RAM
  • Relational database. H2 is included by default. If you wish to use something else such as PostgreSQL or Oracle, please see instructions for installing Supported Databases to complete this step.

Database Schema

Each row in an item table (osee_artifact, osee_attribute, and osee_relation) has an id and a version (GAMMA_ID). The version is unique across all rows of all item tables.



How to Define Classes for Coverage Importing

The following steps walk a developer through defining the classes necessary to begin importing coverage data into the OSEE application.  Please keep in mind that these are meant to be simplified examples and developers are encouraged to 'get creative' when adapting these examples to their own particular context.

1. Write a class that extends AbstractCoverageBlam

public class MyCoverageImportBlam extends AbstractCoverageBlam {
   public static String COVERAGE_IMPORT_DIR = "Coverage Import Directory";
   public static String NAMESPACE = "Code Namespace";

   public String getName() {
      return "My Coverage Import";

   public Collection<String> getCategories() {
      return Arrays.asList("Blams");

   public String getDescriptionUsage() {
      return "Import coverage from coverage directory.";

   public void runOperation(final VariableMap variableMap, IProgressMonitor monitor) throws Exception {
      try {
         final String coverageInputDir = variableMap.getString(COVERAGE_IMPORT_DIR);
         if (!Strings.isValid(coverageInputDir)) {
            throw new OseeArgumentException("Must enter valid filename.");
         final String namespace = variableMap.getString(NAMESPACE);
         if (!Strings.isValid(namespace)) {
            throw new OseeArgumentException("Must enter valid namespace.");

         File file = new File(coverageInputDir);
         if (!file.exists()) {
            throw new OseeArgumentException("Invalid filename.");

         MyCoverageImporter myCoverageImporter = new MyCoverageImporter(coverageInputDir, namespace);
         CoverageImport coverageImport =;
      } catch (Exception ex) {
         OseeLog.log(Activator.class, OseeLevel.SEVERE_POPUP, ex);

   public String getXWidgetsXml() {
      StringBuffer buffer = new StringBuffer("<xWidgets>");
      buffer.append("<XWidget xwidgetType=\"XDirectorySelectionDialog\" " + getDefaultDirectory() + " displayName=\"" + COVERAGE_IMPORT_DIR + "\" />");
      buffer.append("<XWidget xwidgetType=\"XText\" displayName=\"" + NAMESPACE + "\" />");
      return buffer.toString();

   private String getDefaultDirectory() {
      if (CoverageUtil.isAdmin()) {
         return " defaultValue=\"C:\\UserData\" ";
      return "";


2. Define a class that implements ICoverageImporter

public class MyCoverageImporter implements ICoverageImporter {
   private final String coverageInputDir;
   private final String namespace;
   private final CoverageImport coverageImport = new CoverageImport("My Coverage Import");

   public MyCoverageImporter(String coverageInputDir, String namespace) {
      this.coverageInputDir = coverageInputDir;
      this.namespace = namespace;

   public String getName() {
      return "My Coverage Importer";

   public CoverageImport run(IProgressMonitor progressMonitor) throws OseeCoreException {
       * Use any member variables to populate coverageImport
      return coverageImport;


3. Add extension point declaration to package's plugin.xml

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>

Helpful links

Design Questions

I have strange eclipse/osee issues can I delete stuff from my configuration folder?

yes. Everything except:


Is OSEE an application framework or an application?

The simple answer is BOTH. OSEE Application Framework is created to allow applications to be built on top and share the common data model. This can be used independently of any OSEE applications. In addition, there are applications that are delivered with and use the OSEE Application Framework. This includes a full featured Requirements and Document Management System (OSEE Define), a powerful change tracking and configuration management application (OSEE ATS - Action Tracking System), a fully customizable peer-review module and other project, reporting and metrics tools. These application can be used out-of-the-box and new applications can be created or integrated on the framework to share and contribute to the same data.

Other products sound similar. Why OSEE?

  • Open Source Extensible Platform
  • Open Eclipse Project w/ Collaboration
  • Tight Integration Around A Common Data Model
  • Full Lifecycle Engineering Environment

Is OSEE only for Avionics Engineering?

No. OSEE's was created by The Boeing Company in support of the Apache AH-64 Attack Helicopter flight control software. Although it was created to handle the complexity of a large US Department of Defense program, it was architected to support any systems engineering project from a simple application built for a single customer to a large complex application like the Apache flight controls. In addition, since OSEE is an independent application, the OSEE development team uses OSEE to develop, deploy and maintain OSEE.

What is Skynet?

Skynet is a legacy term for the persistence portion of the OSEE Application Framework.

What are Artifact Framework types?

OSEE provides Artifacts, Attributes and Relations that are strongly typed. This means that the user can create their own artifact type, for example a "Software Requirement" to represent the requirements at a software level and their own attribute types, for example a "Qualification" attribute or a "Safety Criticality" attribute and event their own relations, for example a "Software Requirement to Allocation" relation. These types are defined in the Artifact Framework and can be created dynamically in the system during database creation or while running. This allows the end user to expand the data that is being stored in OSEE without providing a new release.

What is the Action Tracking System (ATS)?

The Action Tracking System is the tightly integrated configuration management system built in OSEE and very tightly integrated with the OSEE Application Framework. It uses a powerful workflow engine to provides a fully customizeable workflow to track improvements, problems and support for any number of teams/tools/programs simultaneously. This gives the user a single point view into all the work that they are required to do.

Why build yet another bug tracking tool like the Action Tracking System (ATS)?

Although there are a number of open source and commercial bug tracking systems available, OSEE's goal to integrate workflow management and provide a tight integration with the Application Framework, and the applications built on top, required us to develop ATS. ATS is meant to be more than simple bug tracking since it can be used to manage multiple teams working on multiple products or support simultaneously. This means that you can create a single "Action" to "Fix the XYZ capability" that will create the necessary workflows for all the teams that need to perform work. For example, a workflow may be created for not only the Software Development team, but also the test team, documentation team, integration team and even facilities like labs or conference rooms. Each team then moves independently through its workflow to perform the work necessary for the common "Action". In addition, ATS enables complete customization of different workflows for each configured team. This means that the documentation team can follow their own "process" which may contain 5 different states while the application developers can follow their own more complex "process" which may contain 30 different states.

How does OSEE handle traceability?

Traceability is handled in OSEE through the use of Relations. These relations can be defined in OSEE according to their need and the users can then add and remove these relations throughout the lifecycle of the requirements or other artifacts. Deliverable documents or any report generation would also use this traceability.

What is Define?

OSEE Define is OSEE's advanced Requirements and Document Management System. OSEE Define can be used to track a simple application's requirements, code and test or configured to support a large program doing concurrent development with multiple parallel builds and manage requirements for multiple product lines simultaneously. Although any application file (document) can be stored and managed, OSEE Define is tightly integrated with Microsoft Word(c) to store and manage individual requirement objects (stored in XML) and provide advanced features like index based searching and showing differences between historical changes. Integrated tightly with the Action Tracking System, OSEE Define can be configured to provide advanced configuration management for any set of requirements object.

What is an HRID and how is it used?

The HRID creation, storage and use are currently under re-design. Below are the notes.

  • HRID = Human Readable ID
  • HRID Provider = provides the HRID when the artifact is constructed


To have a unique, short, constant, communicatable and customizable number that artifacts in the system can be referenced by. By definition, this number is database dependent which means it may occur in another database.

Note: All artifacts currently have a GUID. This number id long, constant, un-consomizeable, un-communicatable, database independent number and thus could not work as the HRID.


<character sequence><numeric sequence>

where TBD <character squence> - Alpha numeric, All caps, > 1 and < 6 characters <numeric sequence> - blank or unique numeric number, not zero padded TBD by default, the framework will provide a unique 6 character Alpha-numeric number


ATS is one of the main consumers of this number and is thus an important portion of the design considerations.

  • Each provider will have a unique sequence number available
  • One HRID Provider can be used by multiple ATS Team Definitions
  • Each Artifact will have at least TBD 0,1 HRID
    • Question still remains as to whether every artifact should have at least one HRID.
    • Reasons for always having
      • Users will always be able to reference HRID instead of switching between GUID and HRID
      • Code won't have to check if HRID is null if trying to get an ID for display
      • UI's don't have to show both GUID and HRID
    • Reasons against
      • Users don't often reference non-ats artifacts by HRID
  • ATS Action will have it's own provider and provide something like ACT1234. Team Workflows will provide their own sequence related to their team like CODE9233, TEST2345, REQ3243.
  • ATS will automatically designate the first workflow as the "driving workflow". The displayed action number will be <action hrid>-<driving workflow hrid>. Example: ACT123-REQ1134
  • HRID will be stored in database. TBD either in current HRID column in artifact table or as attribute on artifact
    • Reasons for attribute
      • No special queries to get at HRID
      • Tagging framework already works for attributes
    • Reasons for hrid column
      • Minimal framework/query changes
      • Searching by HRID is faster than by attribute value
      • Would need to limit users/API/UI from changing that special attribute
      • Migration of HRIDs to existing artifacts would require pushing HRID to parent branch and migrating it down to all children
      • Attribute value would be branched and add addressing information to all database and all branches
      • Attributes are for data that can be changed by user. HRID can't


  • Need tagging rules to enable numbers to be split apart and searched by either number alone or character sequence number. Example REQ3243 and 3243 should both work. Keep in mind that 3243 may return 2 objects cause prefix is what makes it unique.
  • ATS, and other places, will need specialized sorter to make sure REQ31 comes after REQ4
  • ATS will need to programatically set first workflow to "driving workflow" and allow user to change.
  • UI to configure for ATS and framework


  • TBD keep same HRID for existing and start with new now or save HRID in ATS actions / static ids and change all historical ids using new sequence

Back to the top