Mail Archive Home | fractal-commits List | April 2008 Index
| <-- Date Index --> | <-- Thread Index --> |
Various fixes in documentation
--- trunk/cecilia-framework/cecilia/src/site/apt/index.apt 2008-04-29 14:42:01 UTC (rev 7549)
+++ trunk/cecilia-framework/cecilia/src/site/apt/index.apt 2008-04-29 15:40:56 UTC (rev 7550)
@@ -1,113 +1,118 @@
- ---
- Introduction
- ---
-
-Overview
-
- <<Cecilia>> is a development environment for programming
- {{{http://fractal.objectweb.org}Fractal}} components on top of the C and C++
- programming languages.
-
- It leverages previous development made in the the {{{http://think.objectweb.org}Think}} and Plasma projects.
-
- Cecilia environment includes a toolchain for building software systems from
- their architecture descriptions. This toolchain is implemented on top of the
- original Fractal ADL toolchain, adding the possibility to perform sophisticated
- code generation tasks as part of the toolchain execution. In other terms, the
- role of this toolchain is to read a set of Fractal ADL architecture description
- files defining the configuration of a given software, and to build the corresponding
- software by gathering the components to be used from component libraries and
- generating the glue code to fit them in the required configuration, and also
- to compile the set of generated and hand-written implementation files to
- produce an executable application, or a bootable kernel.
-
- Thanks to this toolchain, primitive Cecilia components are programmed with
- respect to a programming guide on top of C and C++ programming languages,
- allowing the developer to concentrate only on writing component-related aspects
- such as instance data, interface implementations, invocations and so on.
-
- <Note that the generated code conforms to standard C, and the tools used to
- compile both the implementation and generated files are standard C or C++
- compiler and linker for a given target hardware platform.>
-
-Quick Start tutorials
-
- If you want to have familiarity on how to develop Fractal application with
- Cecilia, it is recommended to begin with these quick start tutorials:
-
- * {{{http://fractal.objectweb.org/cecilia-examples-site/current/helloworld/index.html}HelloWorld}}:
- it is a basic Cecilia example, showing a composite component containing a
- primitive client component which calls a <<<print>>> method on a primitive
- server component. The example is then progressively <extended>, to have
- the server component counts the number of times its <<<print>>> method is
- called. In order to do that a <<<nrOfInvocations>>> <component instance
- variable> is added, and it is initialized using the Fractal
- <<<LifeCycleController>>> interface.
-
- Inside the tutorials you will find references to other documentation needed to
- setup the working environment or understand some concepts.
-
-APIs
-
- {{{runtime/fractal-cecilia-api/package.html}Cecilia API}} are written in the
- {{{toolchain-parent/idl-parser/language.html}Cecilia IDL language}}.
-
-Component Model
-
- Cecilia implements the Fractal Component Model. You may look at the
- {{{http://fractal.objectweb.org/specification/index.html}Fractal specification}}
- for more information on the abstract component model.
-
-Cecilia primitive programming languages
-
- You can write primitive components for Cecilia in different languages on top of C:
-
- * {{{toolchain-parent/cecilia-adl/thinkmc.html}Cecilia thinkMC language}}.
- <It is the language in which the examples are provided.>
-
- * C++ language. <Support for developing Cecilia components in C++ is still experimental.>
-
-Cecilia ADL
-
- {{{toolchain-parent/cecilia-adl/}Cecilia ADL}} is both the name of an extension
- of the {{{http://fractal.objectweb.org/tutorials/adl/index.html}Fractal ADL language}}
- and the name of a personalization of the
- {{{http://fractal.objectweb.org/fractaladl/index.html}Fractal ADL Toolchain}}.
-
- You can then follow one of these two links:
-
- * {{{toolchain-parent/cecilia-adl/language.html}Cecilia ADL Language}}:
- a description of the Cecilia Architecture Description Language, starting
- with a basic example and then providing the full ADL grammar specification
-
- * {{{toolchain-parent/cecilia-adl/toolchain.html}Cecilia ADL Toolchain}}: a
- description of the Cecilia Toolchain architecture. The toolchain reads an
- architecture description, generates corresponding C source code and compile
- the resulting application.
-
-Libraries
-
- The following is a list of component based libraries that can be used with Cecilia:
-
- * {{{runtime/cecilia-baselib}cecilia-baselib}}: it contains a minimal set of
- interfaces and components needed to develop a Cecilia application.
-
-Tools
-
- The Cecilia modules (api, impl and libs) are built and packaged with the open
- source tool {{{http://maven.apache.org}Maven}}.
-
- You are suggested to use Maven to develop 3rd party applications based on
- Cecilia, because you may find that there is
- {{{maven-parent/index.html}Maven support for Cecilia}} by means of custom
- plugins and archetypes which can speedup and simplify development.
-
-Frequently Asked Questions
-
- As some sort of short reference to some Cecilia practices, there is a {{{faq.html}Frequently Asked Questions page}}.
-
-Mailing list
-
- Questions, comments, ideas, etc. related to Fractal can be posted on the
- {{{mail-lists.html}Fractal mailing list}} (preferably prefixing your email subject with [cecilia]).
-
\ No newline at end of file
+ ---
+ Introduction
+ ---
+
+Overview
+
+ <<Cecilia>> is a development environment for programming
+ {{{http://fractal.objectweb.org}Fractal}} components on top of the C and C++
+ programming languages.
+
+ It leverages previous developments made in the {{{http://think.objectweb.org}Think}} and Plasma projects.
+
+ Cecilia environment includes a toolchain for building software systems from
+ their architecture descriptions. This toolchain is implemented on top of the
+ original Fractal ADL toolchain, adding the possibility to perform sophisticated
+ code generation tasks as part of the toolchain execution. In other terms, the
+ role of this toolchain is to read a set of Fractal ADL architecture description
+ files defining the configuration of a given software, and to build the corresponding
+ software by gathering the components to be used from component libraries and
+ generating the glue code to fit them in the required configuration, and also
+ to compile the set of generated and hand-written implementation files to
+ produce an executable application, or a bootable kernel.
+
+ Thanks to this toolchain, primitive Cecilia components are programmed with
+ respect to a programming guide on top of C and C++ programming languages,
+ allowing the developer to concentrate only on writing component-related aspects
+ such as instance data, interface implementations, invocations and so on.
+
+ <Note that the generated code conforms to standard C, and the tools used to
+ compile both the implementation and generated files are standard C or C++
+ compiler and linker for a given target hardware platform.>
+
+Quick Start tutorials
+
+ If you want to have familiarity on how to develop a Fractal application with
+ Cecilia, it is recommended to begin with these quick start tutorials:
+
+ * {{{http://fractal.objectweb.org/cecilia-examples-site/current/helloworld/index.html}HelloWorld}}:
+ it is a basic Cecilia example, showing a composite component containing a
+ primitive client component which calls a <<<print>>> method on a primitive
+ server component. The example is then progressively <extended>, to have
+ the server component counts the number of times its <<<print>>> method is
+ called. In order to do that a <<<nrOfInvocations>>> <component instance
+ variable> is added, and it is initialized using the Fractal
+ <<<LifeCycleController>>> interface.
+
+ Inside the tutorials you will find references to other documentation needed to
+ setup the working environment or understand some concepts.
+
+APIs
+
+ {{{runtime/fractal-cecilia-api/package.html}Cecilia APIs}} are written in the
+ {{{toolchain-parent/idl-parser/language.html}Cecilia IDL language}}.
+
+Component Model
+
+ Cecilia implements the Fractal Component Model. You may look at the
+ {{{http://fractal.objectweb.org/specification/index.html}Fractal specification}}
+ for more information on the abstract component model.
+
+Cecilia primitive programming languages
+
+ You can write primitive components for Cecilia in different languages on top of C:
+
+ * {{{toolchain-parent/cecilia-adl/thinkmc.html}Cecilia thinkMC language}}.
+ <It is the language in which the examples are provided.>
+
+ * C++ language. <Support for developing Cecilia components in C++ is still experimental.>
+
+Cecilia ADL
+
+ {{{toolchain-parent/cecilia-adl/}Cecilia ADL}} is both the name of an extension
+ of the {{{http://fractal.objectweb.org/tutorials/adl/index.html}Fractal ADL language}}
+ and the name of a personalization of the
+ {{{http://fractal.objectweb.org/fractaladl/index.html}Fractal ADL Toolchain}}.
+
+ You can then follow one of these two links:
+
+ * {{{toolchain-parent/cecilia-adl/language.html}Cecilia ADL Language}}:
+ a description of the Cecilia Architecture Description Language, starting
+ with a basic example and then providing the full ADL grammar specification
+
+ * {{{toolchain-parent/cecilia-adl/toolchain.html}Cecilia ADL Toolchain}}: a
+ description of the Cecilia Toolchain architecture. The toolchain reads an
+ architecture description, generates corresponding C source code and compiles
+ the resulting application.
+
+Libraries
+
+ The following is a list of component based libraries that can be used with Cecilia:
+
+ * {{{runtime/cecilia-baselib}cecilia-baselib}}: This library contains a minimal set
+ of interfaces and components needed to develop a Cecilia application.
+
+ * {{{http://fractal.objectweb.org/minus-site/current}Minus}}: This library
+ provides components to build exo-kernels and middlewares for embedded platforms.
+ It is delivered with a set of examples, as well as wrapper components to run on
+ POSIX systems (Linux).
+
+Tools
+
+ The Cecilia modules (api, impl and libs) are built and packaged with the open
+ source tool {{{http://maven.apache.org}Maven}}.
+
+ You are suggested to use Maven to develop 3rd party applications based on
+ Cecilia, because you may find that there is
+ {{{maven-parent/index.html}Maven support for Cecilia}} by means of custom
+ plugins and archetypes which can speedup and simplify your developments.
+
+Frequently Asked Questions
+
+ As some sort of short reference to some Cecilia practices, there is a {{{faq.html}Frequently Asked Questions page}}.
+
+Mailing list
+
+ Questions, comments, ideas, etc. related to Fractal can be posted on the
+ {{{mail-lists.html}Fractal mailing list}} (preferably prefixing your email subject with [cecilia]).
+
--- trunk/cecilia-framework/cecilia/src/site/site.xml 2008-04-29 14:42:01 UTC (rev 7549)
+++ trunk/cecilia-framework/cecilia/src/site/site.xml 2008-04-29 15:40:56 UTC (rev 7550)
@@ -1,74 +1,75 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-<!--
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
--->
-
-<project name="Cecilia framework">
- <skin>
- <groupId>org.objectweb.fractal.cecilia</groupId>
- <artifactId>maven-skin-cecilia</artifactId>
- <version>1.0</version>
- </skin>
-
- <body>
- <!-- the '%v' in menu name will be replaced by ${project.version} by the
- maven-skin-cecilia. -->
- <menu name="Cecilia %v" inherit="top">
- <item name="Introduction" href="" />
- <item name="Download"
- href="" />
-
- <!-- WARNING : don't forget to update documentation pages when
- menu items are updated -->
- <item name="Documentation" href=""
- <item name="Programming Model" href=""
- <item name="Cecilia ADL"
- href="" />
- <item name="Cecilia IDL"
- href="" />
- <item name="ThinkMC"
- href="" />
- </item>
- <item name="ADL Toolchain" href=""
- <item name="Users guide"
- href="" />
- <item name="Developers guide"
- href="" />
- </item>
- <item name="Examples"
- href=""
- <item name="Quick Start Tutorial"
- href="" />
- </item>
- <item name="FAQ" href="" />
- </item>
- <item name="External Links" href=""
- <item name="Fractal Component Model"
- href="" />
- <item name="ObjectWeb Forge Site"
- href="" />
- </item>
- </menu>
-
- <menu ref="reports" />
- <menu ref="modules" />
-
- <links>
- <item name="Fractal" href=""
- <item name="Fractal ADL" href=""
- <item name="Cecila Examples" href=""
- </links>
- </body>
-</project>
\ No newline at end of file
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!--
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+-->
+
+<project name="Cecilia framework">
+ <skin>
+ <groupId>org.objectweb.fractal.cecilia</groupId>
+ <artifactId>maven-skin-cecilia</artifactId>
+ <version>1.0</version>
+ </skin>
+
+ <body>
+ <!-- the '%v' in menu name will be replaced by ${project.version} by the
+ maven-skin-cecilia. -->
+ <menu name="Cecilia %v" inherit="top">
+ <item name="Introduction" href="" />
+ <item name="Download"
+ href="" />
+
+ <!-- WARNING : don't forget to update documentation pages when
+ menu items are updated -->
+ <item name="Documentation" href=""
+ <item name="Programming Model" href=""
+ <item name="Cecilia ADL"
+ href="" />
+ <item name="Cecilia IDL"
+ href="" />
+ <item name="ThinkMC"
+ href="" />
+ </item>
+ <item name="ADL Toolchain" href=""
+ <item name="Users guide"
+ href="" />
+ <item name="Developers guide"
+ href="" />
+ </item>
+ <item name="Examples"
+ href=""
+ <item name="Quick Start Tutorial"
+ href="" />
+ </item>
+ <item name="FAQ" href="" />
+ </item>
+ <item name="External Links" href=""
+ <item name="Fractal Component Model"
+ href="" />
+ <item name="ObjectWeb Forge Site"
+ href="" />
+ </item>
+ </menu>
+
+ <menu ref="reports" />
+ <menu ref="modules" />
+
+ <links>
+ <item name="Fractal" href=""
+ <item name="Fractal ADL" href=""
+ <item name="Cecila Examples" href=""
+ <item name="Minus" href=""
+ </links>
+ </body>
+</project>
--- trunk/cecilia-framework/cecilia/toolchain/cecilia-adl/src/site/apt/ceciliac.apt 2008-04-29 14:42:01 UTC (rev 7549)
+++ trunk/cecilia-framework/cecilia/toolchain/cecilia-adl/src/site/apt/ceciliac.apt 2008-04-29 15:40:56 UTC (rev 7550)
@@ -21,23 +21,23 @@
Installing the <<<ceciliac>>> compiler:
- [[1]] Unpack the archive where you would like to store the binaries (
+ [[1]] Unpack the archive where you would like to store the binaries (
<<</usr/local>>> for instance)
- [[2]] A directory called "cecilia-framework-${project.version}" will be created.
+ [[2]] A directory called "cecilia-framework-${project.version}" will be created.
- [[3]] Add the <<<bin>>> sub-directory to your PATH environment variable
+ [[3]] Add the <<<bin>>> sub-directory to your PATH environment variable
- [[4]] Make sure that tha <<<JAVA_HOME>>> environment variable is set to the
- location of your JDK.
+ [[4]] Make sure that the <<<JAVA_HOME>>> environment variable is set to the
+ location of your JDK.
- [[5]] Run <<<ceciliac>>> to verify that it is correctly installed.
+ [[5]] Run <<<ceciliac>>> to verify that it is correctly installed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Running the <<<ceciliac>>> compiler
- The ceciliac compiler compiles a given architecture definition file.
- It is used with the following command-line arguments:
+ The ceciliac compiler compiles a given architecture definition file.
+ It is used with the following command-line arguments:
--------------------------------------------------
$ ceciliac [OPTIONS] (<definition>[:<output-name>])+
@@ -46,37 +46,37 @@
where <definition> is the name of the component to be compiled,
and <execname> is the name of the output file to be created.
- Available options are (from command line, options must be prefix with '-') :
+ Available options are (from command line, options must be prefix with '-') :
- * src-path (S) : the search path of ADL,IDL and implementation files
+ * src-path (S) : the search path of ADL,IDL and implementation files
* out-path (out-dir, o) : the path where generated files will be put
- * compiler-adl : Specify the name of the ADL of the compiler itself
+ * compiler-adl : Specifies the name of the ADL of the compiler itself
- * compiler-command (cc) : the command of the C compiler (default is 'gcc')
+ * compiler-command (cc) : the command of the C compiler (default is 'gcc')
- * defs (D) : the -D compiler directives
+ * defs (D) : the -D compiler directives
- * c-flags (cf) : the c-flags compiler directives
+ * c-flags (cf) : the c-flags compiler directives
- * inc-path (I) : the -I compiler directives
+ * inc-path (I) : the -I compiler directives
- * linker-command (ld) : the command of the linker (default is 'gcc')
+ * linker-command (ld) : the command of the linker (default is 'gcc')
- * ld-flags (lf) : the ld-flags compiler directives
+ * ld-flags (lf) : the ld-flags compiler directives
- * ld-path (-L) : the -L compiler directives
+ * ld-path (-L) : the -L compiler directives
- * executable-format : the binary format associated to "executable" output format (default is 'elf')
+ * executable-format : the binary format associated to "executable" output format (default is 'elf')
- * archive-command (ar) : the command of the archive tool, (default is 'ar')
+ * archive-command (ar) : the command of the archive tool, (default is 'ar')
- * linker-script (T) : linker script
+ * linker-script (T) : linker script
- * executable-name (exec-name) : the name of the target executable file (can be used with only one ADL to be compiled.)
+ * executable-name (exec-name) : the name of the target executable file (can be used with only one ADL to be compiled.)
- * jobs (j) : The number of concurrent compilation jobs
+ * jobs (j) : The number of concurrent compilation jobs
Setting the verbosity level of the ceciliac compiler
@@ -84,7 +84,7 @@
Use the CECILIA_OPTS environment variable to specify verbosity level.
- For instance to use FINE level for console messages and FINER for messages
+ For instance, to use FINE level for console messages and FINER for messages
dumped in log file, use:
+------------------------------------------------------------------------------+
@@ -96,14 +96,14 @@
Addition of extension modules to the <<<ceciliac>>> compiler
- Set the CECILIA_CLASSPATH environment variable to include the .jar files or the classes
- of the extension module(s).
+ Set the CECILIA_CLASSPATH environment variable to include the .jar files or the classes
+ of the extension module(s).
+------------------------------------------------------------------------------+
$ export CECILIA_CLASSPATH="MyModule1.jar:MyModule2.jar"
+------------------------------------------------------------------------------+
- or
+ or
+------------------------------------------------------------------------------+
$ set CECILIA_CLASSPATH="MyModule1.jar;MyModule2.jar"
--- trunk/cecilia-framework/cecilia/toolchain/cecilia-adl/src/site/apt/extension-tutorial.apt 2008-04-29 14:42:01 UTC (rev 7549)
+++ trunk/cecilia-framework/cecilia/toolchain/cecilia-adl/src/site/apt/extension-tutorial.apt 2008-04-29 15:40:56 UTC (rev 7550)
@@ -4,51 +4,52 @@
Introduction
- <<Purpose>>
+ <<Purpose>>
- This tutorial illustrates how to extend the Cecilia ADL toolchain for
- supporting a new programming model in addition to the default one which
- is called {{{http://fractal.objectweb.org/cecilia/thinkmc.html}thinkMC}}.
- To keep the tutorial as simple as possible, we will assume that the new
- programming model the same as the {{{http://fractal.objectweb.org/cecilia/thinkmc.html}thinkMC}}
- programming model except that it will be called <myLanguage>.
- That way, we will identify in this tutorial the set of plugin components
- that need to be developed for supporting such a new programming model
- without going into the implementation details of these plugin components.
- Developers are then encouraged to use the extension module that is provided
- with this tutorial for implementing their own extensions.
+ This tutorial illustrates how to extend the Cecilia ADL toolchain for
+ supporting a new programming model in addition to the default one which
+ is called {{{http://fractal.objectweb.org/cecilia/thinkmc.html}thinkMC}}.
+ To keep the tutorial as simple as possible, we will assume that the new
+ programming model is the same as the {{{http://fractal.objectweb.org/cecilia/thinkmc.html}thinkMC}}
+ programming model except that it will be called <myLanguage>.
+ This way, we will identify in this tutorial the set of plugin components
+ that need to be developed for supporting such a new programming model
+ without going into the implementation details of these plugin components.
+ Developers are then encouraged to use the extension module that is provided
+ with this tutorial for implementing their own extensions.
- <<Getting Started>>
+ <<Getting Started>>
- * First, download the source code of the tutorial from here {{downloads/cecilia-${project.version}-tutorial.zip}} or here {{downloads/cecilia-${project.version}-tutorial.tar.gz}}.
+ * First, download the source code of the tutorial from here {{downloads/cecilia-${project.version}-tutorial.zip}} or here {{downloads/cecilia-${project.version}-tutorial.tar.gz}}.
- * Extract the source code. A directory called <<<cecilia-${project.version}-tutorial>>> will be created.
+ * Extract the source code. A directory called <<<cecilia-${project.version}-tutorial>>> will be created.
- * Launch your Eclipse with {{{http://m2eclipse.codehaus.org/}maven plugin}} installed
+ * Launch your Eclipse with {{{http://m2eclipse.codehaus.org/}maven plugin}} installed
- * Import the project found in the <<<cecilia-${project.version}-tutorial>>> into your Eclipse workspace.
+ * Import the project found in the <<<cecilia-${project.version}-tutorial>>> into your Eclipse workspace.
- * Test the execution of the extension
+ * Test the execution of the extension
- * First execute the goal <<<process-test-resources>>> of the maven
- project. An execution target is already prepared for that purpose.
- To find it, open the dialog box
- <<<Run -> External Tools -> Open External Tools Dialog...>>>.
- You should find an execution target called
- <<<SimpleExtension process-test-resources>>> under the
- <<<Maven Build>>> tree. Select it,
- and then click on <<<Run>>>. This will unpack the test resources.
- This step has to be repeated each time the project is cleaned.
+ * First execute the goal <<<process-test-resources>>> of the maven
+ project. An execution target is already prepared for that purpose.
+ To find it, open the dialog box
+ <<<Run -> External Tools -> Open External Tools Dialog...>>>.
+ You should find an execution target called
+ <<<SimpleExtension process-test-resources>>> under the
+ <<<Maven Build>>> tree. Select it,
+ and then click on <<<Run>>>. This will unpack the test resources.
+ This step has to be repeated each time the project is cleaned.
- * Then, launch the unit tests that verify the execution of the extension.
- An execution target is already prepared for that purpose.
- To find it, open the dialog box '<<<Run->Open Run Dialog>>>'.
- You should find an execution target called <<<SimpleExtension>>>
- under the <<<JUnit>>> tree. Select it, and the click on <<<Run>>>.
+ * Then, launch the unit tests that verify the execution of the extension.
+ An execution target is already prepared for that purpose.
+ To find it, open the dialog box '<<<Run->Open Run Dialog>>>'.
+ You should find an execution target called <<<SimpleExtension>>>
+ under the <<<JUnit>>> tree. Select it, and the click on <<<Run>>>.
- * You should see the following output on the console window:
-
+ You should see the following output on the console window:
+
+
---------------------------------------------------
[step] [basic-factory] Load ADL 'test.extension.SimpleComponent'
[org.objectweb.fractal.cecilia.primitive.myLanguage.CodeLoader::loadImplementation()] Hello World
@@ -70,135 +71,136 @@
Overview
- As presented in the {{{toolchain.html}toolchain architecture}} document,
- the Cecilia ADL toolchain is composed of two main modules: the <loader module> and
- the <processing module>. Both of these modules will be implied in the extension
- of the toolchain for a new programming module support. The <loader module>
- should be extended to load the implementation files that are written in the new
- programming module and the <processing module> should be extended for implementing
- the new processing operations (e.g. code generation for new macros).
+ As presented in the {{{toolchain.html}toolchain architecture}} document,
+ the Cecilia ADL toolchain is composed of two main modules: the <loader module> and
+ the <processing module>. Both modules will be involved in the extension
+ of the toolchain for a new programming module support. The <loader module>
+ should be extended to load the implementation files that are written in the new
+ programming module, while the <processing module> should be extended for implementing
+ the new processing operations (e.g. code generation for new macros).
+
+ The following sections present the extension of both modules respectively.
+ Then, the unit test mechanism provided to test the extension is presented, followed
+ by a discussion about how to go further for turning this tutorial
+ project into a real extension.
- The following two sections present the extension of these two modules respectively.
- Then, the unit test mechanism that is provided to test the extension is presented.
- Finally, a discussion about how to go further for turning this tutorial
- project to a real extension is provided.
-
Extension of the Loader Module
- The <loader module> is designed for accepting extensions for supporting new programming
- models. That is, the support for loading a implementation files written in a new
- programming modules can be added as a plugin into the default loader component
- chain.
+ The <loader module> is designed for accepting extensions supporting new programming
+ models. That is, the support for loading an implementation files written in a new
+ programming module can be added as a plugin into the default loader component
+ chain.
+
+ Two plugin components must be provided for that purpose: a plugin component for loading
+ the implementation files written in <myLanguage>, and another plugin component for
+ adding the controllers to the components implemented in <myLanguage>.
- Two plugin components must be provided for that purpose: a plugin component for loading
- the implementation files written in <myLanguage>, and another plugin component for
- adding the controllers to the components implemented in <myLanguage>.
+ <<Implementation Code Loader>>
- <<Implementation Code Loader>>
-
- A plugin selector is already present in the <loader module> for loading plugins depending
- on the implementation language that is used for writing the wiriting the implementation
- of primitive components. This plugin selector looks for plugins in respect to the following
- naming convention :
+ A plugin selector is already present in the <loader module> for loading plugins
+ according to the implementation language used for writing the primitive
+ components. This plugin selector looks for plugins respecting the following
+ naming convention:
<<<org.objectweb.fractal.cecilia.primitive.<nameOfTheProgrammingModel>.ImplementationCodeLoader>>>.
- According to this convention, when a primitive component written in <myLanguage> will be
- found in the compiled architecture, the toolchains plugin selector will look for a plugin
- component called <<<org.objectweb.fractal.cecilia.primitive.<myLanguage>.ImplementationCodeLoader>>>
- within the class path. If such a plugin is found, it will be automatically loaded, and
- then the load operation for loading the corresponding implementation file will
- be delegated to this plugin.
+ According to this convention, when a primitive component written in <myLanguage> will be
+ found in the architecture being compiled, the toolchains plugin selector will look for a plugin
+ component called <<<org.objectweb.fractal.cecilia.primitive.<myLanguage>.ImplementationCodeLoader>>>
+ within the class path. If such a plugin is found, it will be automatically
+ loaded, and the load operation for loading the corresponding implementation
+ file will be delegated to this plugin.
- The architecture description of the implementation code loader plugin component for
- <myLanguage> is as follows. As depicted in the below snippet, an implementation code loader component implements
- the {{{${fractaladl.dependencies.site.url}fractal-adl/apidocs/org/objectweb/fractal/adl/implementations/ImplementationCodeLoader.java}ImplementationCodeLoader}}
- interface. This interface will be invoked by the
- plugin selector for delegating the load operation to the loaded plugin.
+ The architecture description of the <implementation code loader> plugin component for
+ <myLanguage> is as follows. As depicted in the below snippet, an <implementation code loader component> implements
+ the {{{${fractaladl.dependencies.site.url}fractal-adl/apidocs/org/objectweb/fractal/adl/implementations/ImplementationCodeLoader.java}ImplementationCodeLoader}}
+ interface. This interface will be invoked by the
+ plugin selector for delegating the load operation to the loaded plugin.
%{snippet|id=Content|url=""
- The implementation that we provide for that plugin within the context of this
- tutorial is very simple. It implements exactly the same behavior as
- the loader component that loads default <thinkMC> files and just prints
- <Hello World> to signal that it is correctly invoked. As depicted in
- the below snippet, the implementation <myLanguage.ImplementationCodeLoader> class
- just inherits from the default <CCodeLoader> class and prints its message
- before invoking the <<<loadImplementation()>>> method provided by its parent.
+ The implementation that we provide for that plugin within the context of this
+ tutorial is very simple. It implements exactly the same behavior as
+ the loader component that loads default <thinkMC> files and just prints
+ <Hello World> to signal that it is correctly invoked. As depicted in
+ the below snippet, the implementation <myLanguage.ImplementationCodeLoader> class
+ just inherits from the default <CCodeLoader> class and prints its message
+ before invoking the <<<loadImplementation()>>> method provided by its parent.
%{snippet|id=Content|url=""
- As an exercise, we propose developers to try changing the extensions of the
- implementation files that are written in <myLanguage> from <<<.c>>> to <<<.ml>>>.
- To do this exercise, <<<CCodeLoader>>> class should be a good source of inspiration.
+ As an exercise, we propose to developers to try changing the extensions of the
+ implementation files that are written in <myLanguage> from <<<.c>>> to <<<.ml>>>.
+ To do this exercise, <<<CCodeLoader>>> class should be a good source of inspiration.
- <<Controller loader>>
+ <<Controller loader>>
- The control behavior of a component and/or its implementation rules may depend
- the programming model that is used for implementing the component. For this reason,
- when the toolchain is extended for a new programming model, a default controller
- loader must be provided as well for adding at least the default control interfaces
- to the components that are implemented using this new programming model.
- A plugin selector is already present for that purpose.
- This plugin selector looks for plugins in respect the following naming convention:
+ The control behavior of a component and/or its implementation rules may depend on
+ the programming model used for implementing the component. For this reason,
+ when the toolchain is extended with a new programming model, a default controller
+ loader must be provided as well for adding at least the default control interfaces
+ to the components that are implemented using this new programming model.
+ A plugin selector is already present for that purpose.
+ This plugin selector looks for plugins respecting the following naming convention:
<<<org.objectweb.fractal.cecilia.primitive.<nameOfTheProgrammingModel>.C<nameOfTheMembrane>ControllerCodeLoader>>>.
- Another naming convention to keep in mind about the controller plugins is that
- the default membrane for primitive components is called <<<primitive>>>. The same way,
- the default membrane for composite components is called <<<composite>>>. In other words,
- if no membrane (i.e. controller tag) is specified for a primitive component,
- the membrane implementation called <<<primitive>>> is considered to be provided.
- Hence, when the toolchain is extended for supporting <myLanguage>, at least plugin called
+ Another naming convention to keep in mind about the controller plugins is that
+ the default membrane for primitive components is called <<<primitive>>>. The same way,
+ the default membrane for composite components is called <<<composite>>>. In other words,
+ if no membrane (i.e. controller tag) is specified for a primitive component,
+ the membrane implementation called <<<primitive>>> is considered to be provided.
+ Hence, when the toolchain is extended for supporting <myLanguage>, at least plugin called
<<<org.objectweb.fractal.cecilia.primitive.<myLanguage>.C<Primitive>ControllerCodeLoader>>>
- must be provided in the class path.
+ must be provided in the class path.
- The architecture description for this controller loader is as follows.
+ The architecture description for this <controller loader> is as follows.
%{snippet|id=Content|url=""
- The above plugin component implements the type ControllerLoaderPluginType.
- That is, as depicted below, it implements the
- {{{apicdocs/org/objectweb/fractal/cecilia/adl/components/PrimitiveChecker.java}PrimitiveChecker}}
- interface
- and may use the
- {{{${fractaladl.dependencies.site.url}fractal-adl/apidocs/org/objectweb/fractal/adl/xml/XMLNodeFactory}XMLNodeFactory.java}}
- and the
- {{{${fractaladl.dependencies.site.url}fractal-adl/apidocs/org/objectweb/fractal/adl/implementations/ImplementationCodeLoader.java}ImplementationCodeLoader}}
- interfaces.
- Within the context of a controller loader component, the
- {{{${fractaladl.dependencies.site.url}fractal-adl/apidocs/org/objectweb/fractal/adl/xml/XMLNodeFactory}XMLNodeFactory.java}}
- is
- typically used for enhancing the architecture of the loaded component with some
- control interfaces at the AST level, and the
+ The above plugin component implements the type ControllerLoaderPluginType.
+ That is, as depicted below, it implements the
+ {{{apicdocs/org/objectweb/fractal/cecilia/adl/components/PrimitiveChecker.java}PrimitiveChecker}}
+ interface
+ and may use the
+ {{{${fractaladl.dependencies.site.url}fractal-adl/apidocs/org/objectweb/fractal/adl/xml/XMLNodeFactory}XMLNodeFactory.java}}
+ and the
{{{${fractaladl.dependencies.site.url}fractal-adl/apidocs/org/objectweb/fractal/adl/implementations/ImplementationCodeLoader.java}ImplementationCodeLoader}}
- is used for
- loading the implementation files of some generic control interfaces, if required.
+ interfaces.
+ Within the context of a <controller loader> component, the
+ {{{${fractaladl.dependencies.site.url}fractal-adl/apidocs/org/objectweb/fractal/adl/xml/XMLNodeFactory}XMLNodeFactory.java}}
+ is
+ typically used for enhancing the architecture of the loaded component with some
+ control interfaces at the AST level, and the
+ {{{${fractaladl.dependencies.site.url}fractal-adl/apidocs/org/objectweb/fractal/adl/implementations/ImplementationCodeLoader.java}ImplementationCodeLoader}}
+ is used for
+ loading the implementation files of some generic control interfaces, if required.
+
%{snippet|id=Content|url=""
- As for the above implementation code loader plugin,
- the implementation of the controller loader plugin that we provide is
- very simple. It inherits from the default {{{}PrimitiveControllerLoader}} component
- that is provided for <thinkMC> components, and just prints <Hello World> before
- delegating the <<<checkComponent()>>> and <<<getControllerInterfaces()>>> methods
- of its parent.
+ As for the above <implementation code loader> plugin,
+ the implementation of the <controller loader> plugin that we provide is
+ very simple. It inherits from the default {{{}PrimitiveControllerLoader}} component
+ that is provided for <thinkMC> components, and just prints <Hello World> before
+ delegating the <<<checkComponent()>>> and <<<getControllerInterfaces()>>> methods
+ of its parent.
%{snippet|id=Content|url=""
- As an exercice, we propose to developers to modify the implementation of this controller
- loader plugin, and to add a new control interface to each primitive component. or
- instance, this new control interface that we call <<<MyLanguageController>>> can
- implement a method called <<<sayHello>>> that prints <<<Hello World>>> when it is
- invoked at runtime. For such an extension, the AST will have to be extended.
- For that purpose, reading the
- {{{${fractaladl.dependencies.site.url}/ast-core/ast-doc.html}AST documentation}}
- may be useful.
+ As an exercice, we propose to developers to modify the implementation of this controller
+ loader plugin, and to add a new control interface to each primitive component. This new
+ control interface that we call <<<MyLanguageController>>> can
+ implement a method called <<<sayHello>>> that prints <<<Hello World>>> when it is
+ invoked at runtime. For such an extension, the AST will have to be extended.
+ For that purpose, reading the
+ {{{${fractaladl.dependencies.site.url}/ast-core/ast-doc.html}AST documentation}}
+ may be useful.
- Another exercise may consist in implementing another plugin component for a new
- membrane behavior, say we call <<<MyMembraneBehavior>>>. Writing such a new controller
- loader plugin will contribute to the understanding of the above namin conventions
- to be respected. The same way, developers may try to provide a controller loader
- for primitive components that are written in <thinkMC>.
+ Another exercise may consist in implementing another plugin component for a new
+ membrane behavior, say we call <<<MyMembraneBehavior>>>. Writing such a new controller
+ loader plugin will contribute to the understanding of the above naming conventions
+ to be respected. The same way, developers may try to provide a controller loader
+ for primitive components that are written in <thinkMC>.
Extension of the Processing Module
@@ -216,8 +218,8 @@
will just add a simple <visitor> component that prints <<<Hello World>>> when it is
invoked.
- The plugin selector for loading <visitor> components for processing primitive components
- written in a given programming model look for plugins in respect to the following naming
+ The plugin selector for loading <visitor> components used to process primitive components
+ written in a given programming model looks for plugins in respect to the following naming
convention:
<<<org.objectweb.fractal.cecilia.primitive.<nameOfTheProgrammingModel>.Visitor>>>.
According to this naming convention, when a component written in <myLanguage> is
@@ -233,8 +235,8 @@
As depicted in the above snippet, the plugin extends the visitor plugin for <thinkMC> and
makes only two component declarations.
- The first <component> declaration, depicted above, overrides the <<<dispatcher>>> component
- that was declared in the <thinkMC> visitor in order to declare its own task grap
+ * The first <component> declaration, depicted above, overrides the <<<dispatcher>>> component
+ that was declared in the <thinkMC> visitor in order to declare its own task graph
composition rules file. This is done by overriding the corresponding attribute of the
parent <<<dispatcher>>> component. Note that, since this simple plugin doesn't
define any new processing tasks, the task graph composition descriptor that is set
@@ -242,7 +244,7 @@
overriding is indeed done only for illustrating how to define a new task composition
descriptor.
- The second <component> declaration defines a new <visitor> component that is bound to the
+ * The second <component> declaration defines a new <visitor> component that is bound to the
<<<dispatcher>>>. The implementation class of this <visitor> component is depicted below:
%{snippet|id=Content|url=""
@@ -263,7 +265,7 @@
{{{../task-component/tutorial.html}Task Framework Tutorial}}
may be useful. In addition, the
{{{apidocs/org/objectweb/fractal/cecilia/primitive/thinkMC/implementations/MacroDefinitionVisitor.java}MacroDefinitionVisitor}}
- can be an important source of inspiration for such an extension.
+ can be an important source of inspiration for such an extension.
Testing the extension
@@ -288,8 +290,8 @@
As depicted in the below snippet, the architecture definition called
<<<test.extension.SimpleComponent>>> specifies an architecture where the component
called <<<test>>> is implemented in <myLanguage>. The presence of such a component
- in the architecture triggers the plugins presented above, and this way, the allows
- for testing our extension.
+ in the architecture triggers the plugins presented above, therefore allowing
+ testing our extension.
%{snippet|id=Content|url=""
@@ -299,18 +301,20 @@
{{{http://junit.sourceforge.net/}JUnit}}
framework.
-How to go proceed for other types of extensions?
+How to proceed for other types of extensions?
- This tutorial only presented how to extend the Cecilia ADL toolchain for supporting
- a new programming model. Since the toolchain is designed to support such extensions,
- it is sufficient to provide some plugin components respecting some naming conventions,
- and it is done.
+ This tutorial only focused on how to extend the Cecilia ADL toolchain for supporting
+ a new programming model. Since the toolchain is designed to support such extensions, by mean of specifically identified extension points,
+ it was sufficient to provide plugin components respecting some naming conventions. Those extension points have been identified and designed for toolchain adaptation
+ serving the same class of objective than the current one, namely code generation.
+ This might be insufficient for advanced developpers pursuing different objectives than
+ code generation, requiring deeper adaptation of the chain.
- Note that, the Cecilia ADL toolchain can be extended as well, even if the toolchain
- is not designed for them. That is, one can modify the architecture description
- (ADL files) of the to manually add his extension components. This way, new plugin
- selectors can be inserted as well for easing further extensions that belongs somehow
- to the same character.
+ A more advanced way to modify the Cecilia ADL toolchain is possible, exploiting
+ the component based design of the tool and its related modularity: modify directly the architecture description
+ (ADL files) to explicitly add the extension components at strategic points of the
+ architecture. This way, new plugin
+ selectors can be inserted as well for easing further extensions.
For further support, please send an email to the {{{mailto:fractal@xxxxxxx}Fractal
- Mailing List}}.
\ No newline at end of file
+ Mailing List}}.
--- trunk/cecilia-framework/cecilia/toolchain/cecilia-adl/src/site/docbook/toolchain.dbk 2008-04-29 14:42:01 UTC (rev 7549)
+++ trunk/cecilia-framework/cecilia/toolchain/cecilia-adl/src/site/docbook/toolchain.dbk 2008-04-29 15:40:56 UTC (rev 7550)
@@ -55,7 +55,7 @@
building a task graph that models the operations
to be executed. Once the construction of the
task graph is completed, it is executed in a
- correct in a correct order for producing the
+ correct order for producing the
output of the toolchain.
</para>
</listitem>
@@ -79,7 +79,7 @@
<para>
As depicted in Figure
<xref linkend="fig:loader-module" />
- , the Loader Module is composed of fine-grain
+ , the Loader Module is composed of fine-grained
sub-components that are assembled using the "chain of
responsibility" design pattern. According to this
pattern,
@@ -161,9 +161,9 @@
interface, presented in the listing below, has a single
method called
<code>load</code>
- . This method accepts as input the name of a input
+ . This method accepts as input the name of an input
component description to be loaded, with a context for
- accessing additional information, and returns a
+ accessing additional information, and returns an
<ulink
url=""
Definition
@@ -227,7 +227,7 @@
<code>load</code>
method first forwards the request to the lower-level
component in the chain through its client interface.
- This returns a
+ This returns an
<ulink
url=""
Definition
@@ -476,7 +476,7 @@
where to integrate their extensions.
</para>
<para>
- In order to tackle with the above mentioned limitation,
+ In order to deal with the above mentioned limitation,
we extended the classical visitor pattern by dividing
its execution into two phases. During the first phase,
instead of executing their processing operations
@@ -484,7 +484,10 @@
model their processing operations and their dependencies
to other tasks. The result of the first phase is a
complete tasks graph that models the whole processing
- operation. During the second phase, this task graph is
+ operation.
+ </para>
+ <para>
+ During the second phase, this task graph is
executed in a correct order, i.e. an order satisfying
the dependencies of each task. This way, the order of
execution of the visitors, which is based on the place
@@ -553,13 +556,13 @@
the architecture of the Cecilia ADL Toolchain, task
factories are implemented as components, so that
they are accessed through their interfaces. A
- visitor class that need to access a task factory can
+ visitor class that needs to access a task factory can
extend the
<ulink
url=""
AbstractTaskFactoryUser
</ulink>
- . The latter abstract class implement all necessary
+ . The latter abstract class implements all necessary
fields and interfaces in order to get access to a
task factory component.
</para>
@@ -603,7 +606,7 @@
throws ADLException, TaskException {
// Preparation of the task parameters depending on the AST node
String componentName = node.getName() ;
- // Instation of the code generation task
+ // Instantiation of the code generation task
return taskFactoryItf.newPrimitiveTask(new SimpleCodeProviderTask(component),
component);
@@ -611,7 +614,7 @@
</programlisting>
<para>
In the same way, the following listing illustrates
- the implementation of the instantiates
+ the instantiation of the
<ulink
url=""
SimpleFileProviderTask
@@ -630,7 +633,7 @@
// Preparation of the task parameters depending on the AST node
String componentName = node.getName() ;
File outDir = (File)context.get("outdir") ;
- // Instation of the code generation task
+ // Instantiation of the code generation task
return taskFactoryItf.newPrimitiveTask(new SimpleFileProviderTask(component, outDir),
component);
@@ -649,9 +652,9 @@
ComponentVisitor
</ulink>
interface), and a collection of client interfaces of
- the same type for connecting lower-level visitor to
+ the same type for connecting a lower-level visitor to
which the visit invocations should be dispatched.
- Its role consists of dispatching a visit operation
+ Its role consists in dispatching a visit operation
to a set of visitors, and creating a composite task
that gathers the tasks resulting of these
invocations. While the dispatch operation is generic
@@ -733,7 +736,7 @@
, this description specifies how different tasks
that are created for generating code and dumping
them into files should be bound together in order to
- form a composite task
+ form a composite task.
</para>
<programlisting>
<![CDATA[
@@ -762,7 +765,7 @@
order to execute a specific processing operation.
The selection of the sub-visitor to which the
invocation should be forwarded is done depending on
- some properties that are found on the AST. For
+ some properties that are found in the AST. For
instance, a router visitor may be put between
sub-visitors depending on the implementation
language of the compiled component, etc.
--- trunk/cecilia-framework/cecilia/toolchain/src/site/apt/index.apt 2008-04-29 14:42:01 UTC (rev 7549)
+++ trunk/cecilia-framework/cecilia/toolchain/src/site/apt/index.apt 2008-04-29 15:40:56 UTC (rev 7550)
@@ -1,38 +1,38 @@
- -----
- Overview
- -----
-
-Overview
-
- The Cecilia toolchain is split in a set of modules:
-
- * <<<{{{cecilia-adl/index.html}cecilia-adl}}>>> is the Fractal ADL extension
- for the Cecilia framework.
-
- * <<<{{{idl-parser/index.html}idl-parser}}>>> is the parser of the Cecilia
- IDL language.
-
- * <<<{{{plugin-framework/index.html}plugin-framework}}>>> is a small
- framework that allows loading toolchain plugins dynamically.
-
- * <<<{{{task-component/index.html}task-component}}>>> is the task framework
- used by the cecilia-adl toolchain to create, organize and execute code
- generation and code compilation tasks.
-
-Reading for developers who want to extend the Cecilia ADL Toolchain
-
- A set of documents explaining the design and the extension mechanisms of the
- Cecilia ADL Toolchain are provided for helping the developers who want to
- implement their own extensions. The suggested order of reading is :
-
-*------------------------------------------------------------------------+-----+
-| {{{cecilia-adl/toolchain.html} Cecilia ADL Toolchain Design Patterns}} | A high level document explaining the architecture of the Cecilia ADL toolchain, and the design patterns that are implemented.
-*------------------------------------------------------------------------+-----+
-| {{{${fractaladl.dependencies.site.url}/ast-core/ast-doc.html} AST documentation}} | A document that presents the architecture of the Abstract Syntactic Tree that is used at the heart of the Cecilia ADL Toolchain. This document is useful for the developers who want to integrate a new input language, or to proceed to some archtiecture verifications, modifications or enhancements.
-*------------------------------------------------------------------------+-----+
-| {{{cecilia-adl/cecilia-adl/extension-tutorial.html} Cecilia ADL Toolchain Extension Tutorial}} | A tutorial that provides a simple extension module that explains how the support for a new programming model in addition to <thinkMC> can be implemented.
-*------------------------------------------------------------------------+-----+
-| {{{task-component/specification.html} Task Framework Specification}} | The specification of the Task Framework that is used within the Cecilia ADL toolchain. This document is useful for the developers who want to extend the code generation/compilation mechanisms, or implement new architecture processing features.
-*------------------------------------------------------------------------+-----+
-| {{{task-component/tutorial.html} Task Framework Tutorial}} | A tutorial that introduce developers to the task framework.
-*------------------------------------------------------------------------+-----+
+ -----
+ Overview
+ -----
+
+Overview
+
+ The Cecilia toolchain is split in a set of modules:
+
+ * <<<{{{cecilia-adl/index.html}cecilia-adl}}>>> is the Fractal ADL extension
+ for the Cecilia framework.
+
+ * <<<{{{idl-parser/index.html}idl-parser}}>>> is the parser of the Cecilia
+ IDL language.
+
+ * <<<{{{plugin-framework/index.html}plugin-framework}}>>> is a small
+ framework that allows loading toolchain plugins dynamically.
+
+ * <<<{{{task-component/index.html}task-component}}>>> is the task framework
+ used by the cecilia-adl toolchain to create, organize and execute code
+ generation and code compilation tasks.
+
+Reading for developers who want to extend the Cecilia ADL Toolchain
+
+ A set of documents explaining the design and the extension mechanisms of the
+ Cecilia ADL Toolchain are provided for helping the developers who want to
+ implement their own extensions. The suggested order of reading is :
+
+*------------------------------------------------------------------------+-----+
+| {{{cecilia-adl/toolchain.html} Cecilia ADL Toolchain Design Patterns}} | A high level document explaining the architecture of the Cecilia ADL toolchain, and the design patterns that are implemented.
+*------------------------------------------------------------------------+-----+
+| {{{${fractaladl.dependencies.site.url}/ast-core/ast-doc.html} AST documentation}} | A document that presents the architecture of the Abstract Syntactic Tree that is used at the heart of the Cecilia ADL Toolchain. This document is useful for the developers who want to integrate a new input language, or to proceed to some architecture verifications, modifications or enhancements.
+*------------------------------------------------------------------------+-----+
+| {{{cecilia-adl/extension-tutorial.html} Cecilia ADL Toolchain Extension Tutorial}} | A tutorial that provides a simple extension module that explains how the support for a new programming model in addition to <thinkMC> can be implemented.
+*------------------------------------------------------------------------+-----+
+| {{{task-component/specification.html} Task Framework Specification}} | The specification of the Task Framework that is used within the Cecilia ADL toolchain. This document is useful for the developers who want to extend the code generation/compilation mechanisms, or to implement new architecture processing features.
+*------------------------------------------------------------------------+-----+
+| {{{task-component/tutorial.html} Task Framework Tutorial}} | A tutorial that introduces developers to the task framework.
+*------------------------------------------------------------------------+-----+
| <-- Date Index --> | <-- Thread Index --> |
Powered by MHonArc.
Copyright © 2006-2007, OW2 Consortium | contact | webmaster.