<extension point="org.eclipse.ui.newWizards"> <wizard id="com.example.flex.mvpWizard" name="MVP Pattern Component" class="com.example.flex.wizards.MVPWizard" category="com.adobe.flexbuilder.wizards.category"/> </extension> (Java) The wizard would ask for component name, whether to generate a model, view, and presenter, and a target package.
( plugin.xml )
(Using Eclipse IFile API) The plugin would write three MXML/ActionScript files, pre-filled with bindings and event metadata. Crucially, it would also modify the project’s .flexProperties file and update the .actionScriptProperties to include the new sources in the build path. flex builder plugin
Introduction: A Glimpse into the Late 2000s To speak of a "Flex Builder Plugin" is to invoke a specific, pivotal era in web development history—roughly 2006 to 2013. This was the age of the Rich Internet Application (RIA), a time before the dominance of HTML5, React, and Angular. In this world, Adobe Flex reigned supreme for enterprise-grade, data-driven web applications. But Flex itself was a framework; it needed a home. That home was Adobe Flash Builder (originally named Flex Builder), an Eclipse-based Integrated Development Environment (IDE). And at the heart of extending this environment lay the powerful, albeit niche, concept of the Flex Builder Plugin . <extension point="org
By calling IFlexProject.build(IncrementalProjectBuilder.INCREMENTAL_BUILD, null) , the plugin could trigger the Flex compiler to recognize the new classes immediately. Introduction: A Glimpse into the Late 2000s To
Today, the binaries of those plugins linger on forgotten hard drives, in old SVN repositories, and in the memories of developers who once wrestled with Eclipse’s BundleContext and Adobe’s Embed metadata. But the concept —that an IDE should be infinitely extensible down to the compiler’s AST—is as relevant as ever. The next time you use a VS Code extension that generates a React component from a TypeScript interface, or an IntelliJ plugin that refactors a Spring Data repository, tip your hat to the ghost of the Flex Builder plugin. It walked so that modern tooling could run. If you are a developer tasked with maintaining a legacy Flex application today (and yes, some still exist in banking and aviation), understanding the role of custom plugins may be the key to either migrating that application or squeezing a few more years of productivity out of Flash Builder. The eclipse.org archives and the Apache Flex wiki remain the best places to find documentation for these long-obsolete but fascinating tools.
This process, while straightforward in concept, required navigating a labyrinth of Eclipse internal APIs that were poorly documented and frequently changed with each Flash Builder update (e.g., from Flex Builder 3 to Flash Builder 4, the entire project model shifted). By 2013, Adobe had begun to sunset Flex in favor of HTML5. In 2015, Adobe donated the Flex SDK to the Apache Foundation (Apache Royale). Flash Builder itself saw its last major release (4.7) and was eventually discontinued. Consequently, the Flex Builder plugin ecosystem collapsed.