Shared library of reusable components, utilities, and resources developed in Progress OpenEdge ABL.
The purpose of this repository is to centralize generic functionality used by different applications, APIs, integrations, WebServices, and routines developed in OpenEdge, reducing code duplication and promoting standardization across projects.
openedge-common was created to centralize reusable code that does not belong to a specific business rule.
The library should act as a common foundation for multiple OpenEdge projects.
Main goals:
- Reduce code duplication.
- Standardize common implementations.
- Simplify maintenance and evolution.
- Share components across applications.
- Improve project organization.
- Reduce coupling with business rules.
- Allow independent versioning.
- Simplify distribution of compiled code.
- Provide a common foundation for new ABL projects.
During development, the src directory must be available in the consumer application's PROPATH.
Example:
C:\dev\openedge-common\src
Structure:
C:\dev\
│
├── openedge-common\
│ └── src\
│ └── common\
│
└── my-application\
Add the following directory to the PROPATH:
C:\dev\openedge-common\src
The classes can then be used normally.
Example:
USING common.json.JsonUtils.
USING common.string.StringUtils.
USING common.validation.Validator.The repository name is:
openedge-common
However, internal namespaces use only:
common.*
Examples:
USING common.json.JsonUtils.
USING common.string.StringUtils.
USING common.logging.Logger.Avoid:
USING openedge.common.json.JsonUtils.The name openedge-common identifies the repository, while common identifies the library within the source code.
It is recommended to use the source files directly:
C:\dev\openedge-common\src
This simplifies:
- Development.
- Debugging.
- Source code navigation.
- Compilation.
- Testing.
It is recommended to use compiled code only.
Example:
/app/libs/openedge-common.pl
or:
/app/libs/openedge-common/
containing the corresponding .r files.
Initial minimum supported version:
OpenEdge 12.2+
If a component requires a newer OpenEdge version, that dependency must be explicitly documented.
Internal use.
If the project is made public in the future, an appropriate open-source license should be defined.
The evolution of openedge-common should prioritize:
- Compatibility.
- Simplicity.
- Low coupling.
- Reusability.
- Performance.
- Testability.
- Documentation.
- Public API stability.
Every new feature should be evaluated considering its impact on consumer projects.