Equinox Framework

Equinox
The Equinox Framework component is tasked with being a full implementation to the OSGi Core Framework R4 specification. In addition, the Framework component produces launchers, bootstrap infrastructure and application models that facilitate the use of Equinox OSGi in end-user product scenarios.

Framework Projects

	OSGi R4 Framework (org.eclipse.osgi) The main framework project. This includes a set of adaptors and enough function to make a standalone OSGi framework. When built this project produces org.eclispe.osgi.jar.
	Java Launcher (org.eclipse.equinox.launcher) This helps setup the framework classloader and launches the Framework etc. Note: this code used to be included in the startup.jar and has be moved from its old location in the org.eclipse.platform project. See bug 113069 for more details.
	Native Launcher (org.eclipse.equinox.executable) The launcher is the native executable that finds and runs the java launcher org.eclipse.equinox.launcher and thus the framework. It is also responsible for putting up the splash screen etc. The launcher is written in C and currently supports a wide range of operating systems, window systems and processor architectures. The launcher is split into a small native executable and a platform specific library. The source for both the launcher and the library can be found in the org.eclipse.equinox.executable project.

Equinox_Launcher@Wiki

You can start Eclipse by running eclipse.exe on Windows or eclipse on other platforms. This small launcher essentially finds and loads the JVM. On Windows, the eclipsec.exe console executable can be used for improved command line behavior.

Alternatively, you can launch Eclipse by directly invoking the JVM as follows:

   java -jar eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar

Find the JVM

If a JVM is installed in the eclipse/jre directory, Eclipse will use it; otherwise the launcher will consult the eclipse.ini file and the system path variable. Eclipse DOES NOT consult the JAVA_HOMEenvironment variable.

To explicitly specify a JVM of your choice, you can use the -vm command line argument:

   eclipse -vm c:\jre\bin\javaw.exe              ''start Java by executing the specified java executable
   eclipse -vm c:\jre\bin\client\jvm.dll         ''start Java by loading the jvm in the eclipse process

See the launcher page for more details on specifying a JVM.

Starting Eclipse Commandline With Equinox Launcher

Ant Script

<!-- set path to eclipse folder. If local folder, use '.'; otherwise, use c:\path\to\eclipse or /path/to/eclipse/ -->
  <property name="eclipse.home" value="."/>
 
  <nowiki><!--  get path to equinox jar inside ${eclipse.home} folder (copy/rename actual jar) --></nowiki>
  <copy tofile="''${eclipse.home}''/eclipse/plugins/org.eclipse.equinox.launcher.jar">
    <fileset dir="''${eclipse.home}''/eclipse/plugins"
      includes="**/org.eclipse.equinox.launcher_*.jar"/>
  </copy>
 
  <nowiki><!-- start Eclipse w/ java --></nowiki>
  <java classpath="''${eclipse.home}''/eclipse/plugins/org.eclipse.equinox.launcher.jar"
  .../>

Or, if you are using Ant 1.7 and don't like copying resources around (or don't have permission to do so) this appears to work to set the path to the newest available equinox launcher jar in a property for later use:

<!-- set path to eclipse folder. If local folder, use '.'; otherwise, use c:\path\to\eclipse or /path/to/eclipse/ -->
  <property name="eclipse.home" value="."/>
 
  <!-- store path to newest launcher JAR in path id 'newest.equinox.launcher.path.id' -->
  <path id="newest.equinox.launcher.path.id">
    <first count="1">
      <sort>
        <fileset dir="${eclipse.home}/eclipse/plugins" includes="**/org.eclipse.equinox.launcher_*.jar"/>
 
        <nowiki><!-- Seems the default order is oldest >
 newest so we must reverse it.
            The 'reverse' and 'date' comparators are in the internal antlib
            org.apache.tools.ant.types.resources.comparators.
         --></nowiki>
        <reverse xmlns="antlib:org.apache.tools.ant.types.resources.comparators">
          <nowiki><!-- 'date' inherits 'reverse's namespace --></nowiki>
          <date/>
        </reverse>
      </sort>
    </first>
  </path>
 
  <!-- turn the path into a property -->
  <property name="equinox.launcher.jar.location" refid="newest.equinox.launcher.path.id" />
 
  <!-- you can now reference the jar through the property ${equinox.launcher.jar.location} -->
  <echo message="Using equinox launcher jar: ${equinox.launcher.jar.location}" />

Bash Shell Script

 #!/bin/bash

 # set path to eclipse folder. If the same folder as this script, use the default; otherwise, use /path/to/eclipse/
 eclipsehome=`dirname $BASH_SOURCE`;

 # get path to equinox jar inside $eclipsehome folder
 cp=$(find $eclipsehome -name "org.eclipse.equinox.launcher_*.jar" | sort | tail -1);

 # start Eclipse w/ java
 /opt/java50/bin/java -cp $cp org.eclipse.equinox.launcher.Main ...

Cmd/Bat Script

Save this as eclipse.cmd. This has been tested with Windows XP Pro (SP2).

 @echo off

 :: set path to eclipse folder. If local folder, use '.'; otherwise, use c:\path\to\eclipse
 set ECLIPSEHOME=.
 
 :: get path to equinox jar inside ECLIPSEHOME folder
 for /f "delims= tokens=1" %%c in ('dir /B /S /OD %ECLIPSEHOME%\plugins\org.eclipse.equinox.launcher_*.jar') do set EQUINOXJAR=%%c
 
 :: start Eclipse w/ java
 echo Using %EQUINOXJAR% to start up Eclipse...
 java -jar %EQUINOXJAR% ...

APE DOM Extensions Overview

1. Introduction

Before CS5, the communication between an ActionScript program running in a Flash Player instance embedded in an application and the application itself was limited to ActionScript's ExternalInterface class. This class offered a XML-based communications protocol to exchange data between the ActionScript world and the application it was embedded in. The application had to write C++ code to use the interface on its side.

This way, an ActionScript program and its embedding host could exchange simple data, such as strings and numbers. But the only realistic way to exchange Live Objects, like a Document object, is through heavy administration and maintenance of several layers of code. Bernd Paradies' PatchPanel technology provided such a layer.

These limitations kept integrators from embedding a Flash Player in an application that was able to efficiently talk to the application's scripting object model.

The APE DOM Extensions are implemented in the APE library. The API is not present in the Flash Player library, or browser plug-in. SWF files that work with DOM Extensions cannot be loaded into a browser environment; they can only load and run in the APE environment.

2. The APIs

Most of the APIs are symmetric. The host has a set of APIs to access the ActionScript object model in an embedded Flash Player instance. Typical calls include the reading and writing of object properties, or the invocation of an object method.

The host application registers a set of function pointers. Again, there are functions to read or write object properties, or to invoke an object method, this time for a host object.

Before working with host or ActionScript objects, there must be a way to get such an object. In a scripting environment, there are several ways.

Access a DOM tree: Often, a host's object model is organized as a tree of objects, starting from a root object that contains elements that themselves contain other objects:

Class objects: Another way to organize a DOM may be to provide several distinct class objects, each of them encapsulating unique functionality.

Creatable objects: Many objects are only present when needed, like colors, files, and more.

The DOM Extensions offers all of these mechanisms to access a host's object model. A host can decide freely which of these object structures to offer. A JavaScript-based host would, for example, offer all three combinations, while a plug-in that offers a restricted set of services might only offer class objects, and neither a root object (because there is no tree-like object structure) nor creatable objects (because there are no objects that are creatable).

The APE environment takes care of object lifetime issues and maintains the connection between host objects and the ActionScript object that they are wrapped into. The ActionScript programmer does not need to worry about issues like garbage collection, asynchronous state changes and the like.

Exceptions are a vital part of ActionScript. The APIs help with generating exceptions and forwarding them between the host and ActionScript. This way, a JavaScript based host could throw JavaScript exceptions into ActionScript, and vice versa.

Mush as the PatchPanel product today, there will be a set of wrapper libraries available that define a host's object model in ActionScript. These wrapper libraries can be used to speed up performance, and to provide safe type checking, code hints, help information and much more.

3. Flow Chart

The host loads a SWF file containing code that uses the HostObject APIs to access the host's DOM. 

Immediately after the SWF has been loaded, the SWF is not yet operational, because it has to execute its startup code (a.k.a frame #1) first. 

This gives the host time to register one or more DOM extensions, and to wait for the SWF to initialize. This wait is necessary if the host wishes to access the objects inside the SWF itself, since most of these objects will be created during the SWF's startup phase. If the host does not want to access the SWF's objects, it does not need to wait either.

The startup code inside the SWF already has full access to the host's object model, because the host registered its DOM extensions before allowing the startup code to execute.

For the interested: The SWF executes its startup code by sending out timer events.

4. Flash events

An ActionScript program often relies on Flash events. A typical Flash event is the click of a button. The ActionScript program can forward these events to the host, who in turn can choose to process these events. This makes it possible for a host environment to e.g. process Flash dialog events.

A Flash event is an ActionScript Event object, so it can be passed on, or created, just like any other ActionScript object. If a host application wants to process Flash events, it registers a function thatreceives these handlers. 

On the ActionScript side, there is a static HostObject.eventListener() method that can be registered as the event processing function. That method directs the event to the host application.

The host, on the other hand, can, of course, create Flash Event objects, and send them off to ActionScript to process. Thus, a host environment can e.g. choose to generate a Button Click event and send it off to a Flash dialog.

Develop Acrobat Plug-ins

Plug-ins

Plug-ins are dynamically-linked extensions to Acrobat or Adobe Reader. They can hook in to the user interface in a number of ways and can register to be called when a variety of events occur in the application.

A plug-in is written in ANSI C/C++ and uses the Acrobat public APIs. It can add functionality to Acrobat Pro Extended, Acrobat Professional, Acrobat Standard, or Adobe Reader. A plug-in program file goes into a Plug_ins folder or directory and is initialized during Acrobat or Adobe Reader startup.

There are three types of plug-ins:

• Regular Acrobat plug-ins—These plug-ins run on Acrobat Professional and Acrobat Standard. Plug-ins for Acrobat Professional can use any of the Acrobat SDK APIs. Plug-ins for Acrobat Standard do not have access to some APIs.
• Adobe Reader-enabled plug-ins—These plug-ins use a restricted set of APIs. Adobe Reader-enabled plug-ins are developed with permission from Adobe and require special processing to load under Adobe Reader. Plug-ins for Adobe Reader can use additional APIs if the PDF document has additional usage rights.
• Certified plug-ins—These plug-ins have undergone extensive testing to ensure that they do not compromise the integrity of Acrobat's security model. A checkbox in the Acrobat and Adobe Reader user interface can be used to ensure that only certified plug-ins are loaded. Certified plug-ins can be provided only by Adobe.

On Windows, plug-ins are DLLs. However, plug-in names must end in .API, not .DLL. On Mac OS, plug-ins are code fragments, whereas on UNIX, plug-ins are shared libraries.

How to develop plugin:

When developing plugins using AFC Library the user has to derive his own plug in application class from the AFC core class AfcPIApp. And subsequently he/she has to override the member functionsSetPluginName , PluginInitialize , PluginImportReplaceAndRegister , PluginExportHFTs and PluginUnload.  The SetPluginName function needs to be overridden by the user and should be implemented thus, so that the  function returns a pointer to a character string which is a unique name associated with the plug-in. The PluginInitialize function is called by the Acrobat viewer during initialization to allow a plug-in to do any sort of initialization it requires, such as adding user interface. If the function returns false, thePluginUnload member function is called. The PluginUnload function is called by the Acrobat viewer when the plug-in unloads to allow it to perform any sort of cleanup needed. Use this member function to release any system resources you may have allocated. The PluginExportHFTs member function is called by the Acrobat viewer during initialization to allow a plug-in to export one or more HFTs to other plug-ins. Inside this member function the user should not do anything other than export HFTs. Plug-ins should not change the user interface at this time, do that in the PluginInitialize member function. The PluginImportReplaceAndRegister member function is called by the viewer during the initialization to allow a plug-in to import HFT to another plug-in or replace an HFT method. This is the only place that a plug-in may replace a HFT method. Plug-ins should not change the user interface at this time, do that in the PluginInitialize member function.

// MyApp construction MyApp ::MyApp () {       // add construction code here,       // Place all significant initialization in PluginInitialize  } // The one and only MyApp object MyApp thePIApp; // MyApp registering unique name char* MyApp ::SetPluginName() {       char* m_szName;       ......................       ......................       return m_szName; } // MyApp initialization bool MyApp ::PluginInitialize() {        // intialization code goes here           .......................           .......................           .......................                return true;           .......................           .......................           .......................                return false; } // Import HFT to another plug-in or replace an HFT method. bool MyApp ::PluginImportReplaceAndRegister() {           .......................           .......................           .......................                return true;           .......................           .......................           .......................               return false; } // Export one or more HFTs to other plug-ins bool MyApp ::PluginExportHFTs() {           .......................           .......................           .......................               return true;           .......................           .......................           .......................              return false; } // MyApp,plug-in unloads bool MyApp ::PluginUnload() {           .......................           .......................           .......................               return true;           .......................           .......................           .......................               return false; } // MyApp destructor MyApp ::~MyApp () {       // add destruction code here,       // Place all significant resource clean ups }