Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Date: Sat, 29 Dec 2012 18:42:13 +0000 (UTC)
From: "Roland Zwaga (JIRA)" <jira@apache.org>
To: flex-dev@incubator.apache.org
Message-ID: <JIRA.12625497.1356806533168.62713.1356806533538@arcas>
In-Reply-To: <JIRA.12625497.1356806533168@arcas>
References: <JIRA.12625497.1356806533168@arcas>
Subject: [jira] [Created] (FLEX-33333) Create a plugin architecture for
 Falcon
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Roland Zwaga created FLEX-33333:
-----------------------------------

             Summary: Create a plugin architecture for Falcon
                 Key: FLEX-33333
                 URL: https://issues.apache.org/jira/browse/FLEX-33333
             Project: Apache Flex
          Issue Type: New Feature
          Components: Compiler API
            Reporter: Roland Zwaga
            Priority: Minor


Falcon should support a clean plugin architecture which should enable developers to extend or modify the compiler's behavior in an easy manner.

A set of hooks ought to be defined that make sense to plug into. Suggestions for these hooks are:

- An AST postprocessing hook which enables a plugin to modify the AST
- An emitter postprocessing hook which enables a plugin to modify the emitter's output

Perhaps the emitters ought to be seen as a form of plugin as well? ABC output and JS output could then simply be configured as plugins. (This way its even possible to output SWF and JS output in one run)

Besides defining interfaces for these hooks there ought to be a simple discovery mechanism for the compiler to locate plugins.

Simplest solution would be a specific directory (or directories) that the compiler watches. Any jar added to such a directory will be scanned for implementations of the known plugin interfaces and registered with the compiler.

For more verbose configuration probably an XML dialect will be needed. In this XML the plugin locations might be defined, but also things like enabling a plugin to run only in debug or release mode could be defined here. The location of the plugin could even be a URL, that way plugins could, for example, be downloaded directly from a Maven repository. (Flexmojos could play an interesting role here)

This ticket is meant to start a discussion, so please feel free to throw in your 2 cents. Designing this plugin architecture as cleanly as possible is very important. So please discuss.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira