Overview of extending the platform
Options for extending the platform
There are three major approaches to extend or override Elastic Path Commerce functionality with different capabilities and advantages or disadvantages:
Extension modules
Use extension modules to modify any part of the Elastic Path Commerce platform. Developers have complete access to the Core Commerce source code to customize and extend all aspects to meet their needs. However, modifying the source code makes maintaining your customizations difficult as the application evolves over time. Once you upgrade to a new version of Core Commerce, your customized code may conflict with upgraded source code and cause problems with your platform. Therefore, we recommend following an extension modules development process for customizations in the projects that are separate from the default Elastic Path source code projects.
Elastic Path provides extension projects to support customizations to Elastic Path Commerce. Adding customizations in the extension projects makes upgrading your Elastic Path source code easier.
The extensions
module consists of multiple sub-modules. Each module extends a different component of Core Commerce. These modules depend on their equivalent default Elastic Path component.
For example, the ext-core
module depends on ep-core
, and ext-search
depends on ep-search
. By depending on the equivalent defaults Elastic Path component, any customizations you make in these modules can import or inherit from that component’s default classes, and you can add or change any behavior.
core/ext-core
)
Core extensions (The extension ext-core
module depends on the default Core Engine library and contains the classes and resources that customize core functionality.
All other extension modules have a dependency on the extension core module, so any changes you make in extension core are available to these modules. Commerce Manager plug-ins also are dependent on extensions core and inherit changes made here.
For information on the structure of the extension core module, see Extension Core Module Structure.
Webapp extensions
Each web application has two components, a JAR and a WAR. When you build the extension web application module, both the JAR and WAR components combine in to a single web application that can be deployed to a server.
For more information on the structure of the extension webapp modules, see Extension Webapp Module Structure.
Other extensions
Type of Extension | Module | Note |
---|---|---|
Assets | assets | See Managing Assets |
Database schema and catalog data | database/ext-data | See Modifying Schema and Catalog Data |
Import/Export functionality | importexport/ext-importexport | Extends ep-importexport |
Data Sync Tool functionality | sync/ext-sync | Extends ep-sync |
Data Population functionality | data-population/ext-data-population-core | Extends ep-data-population-core . For more information, see Extending Data Population Tool in Elastic Path Production Tools. |
External plugins
In this approach, developers can create extension classes that implement pre-defined extension point interfaces using the Extension Point Framework.
The main advantages of the Extension Point Framework external plugins approach are:
- Simpler development process for extending the platform.
- Clear documentation describing how to build common customizations.
- Faster compilation by avoiding building the platform source.
- Easy upgrades to future Elastic Path Commerce versions.
- Separate classloader to avoid dependency conflicts and OSGi complexities.
- Ability to load and unload external plugins at runtime without restarts.
Extensions in external plugins are developed against intentional, well-documented interfaces that are designed to be easy to use. The source code exists in a repository that is completely separate from the Elastic Path Commerce platform source code, and the compiled JAR can be loaded by the Elastic Path Commerce platform at startup. Each external plugin has its own classloader that is separate from the rest of the platform.
You can compile external plugins quickly without any OSGi classloader restrictions or complexity. However, external plugin extensions have the following limitations:
- Cannot access platform services.
- Cannot participate in the Spring context.
- Cannot access the database directly.
- Can only use information that the framework passes to plugin.
For more information about developing External Plugins, see the Extension Point Framework documentation.
Embedded extensions
This approach is a hybrid of the Extension Module and the External Plugin methods.
Define extension classes in the ext-core
module of the Elastic Path Commerce platform source. Developers still create extension classes that implement the Extension Point Service Provider Interfaces. These extensions are automatically detected by the framework and assigned to the appropriate extension points.
Unlike external plugins, these extensions are part of the platform classloader and can load service classes using Spring, and can access the database through these services. However, embedded extension classes are not guaranteed to work seamlessly after an upgrade, since they can access service classes that may change between versions. The extension point interfaces they implement will be backwards compatible. Upgrade issues should be less significant than if the Extension Modules approach is used.
For more information about developing Embedded Extensions, see the Extension Point Framework documentation.