With 5.0.0, NEBA introduces a flyweight core and becomes independent of the Spring Framework. The Spring integration, albeit optional, is now available as a dedicated module and is upgraded to Spring 5. At the same time, the API has been partially restructured and simplified.
The recent versions of AEM have seen a growing ecosystem of production-quality open source solutions, e.g. ACS commons or Sling models which form a solid foundation for many projects. Likewise, the trade-of between the footprint of the Spring integration and the features gained by the integration became smaller.
Here, we choose to provide NEBA's core functionality with two lightweight bundles and make the Spring integration optional. Without using Spring, all it takes is a model annotated with @ResourceModel and the OSGi bundle header
Neba-Packages to point to the respective package.
If you want to continue using the Spring Framework, rest easy: You can still deploy NEBA and the Spring integration with one simple CRX package or delivery bundle.
NEBA's API is now even more consise: A dedicated SPI (Service Provider Interface) package contains all extensions points in the form of service interfaces.
The services package, on the other hand, contains interfaces of services published by NEBA. The annotations package remains largely unchanged and continues
to provide NEBA's core functionality via semantic annotations. The notable exception is the
@PostMapping annotation, which has been renamed to @AfterMapping - both for clarity and to
avoid using the same name as Spring's REST annotation for HTTP POST MVC mappings.
Release 5.0.0 also introduces the @Filter annotation, which allows filtering OSGi services injected into resource models.
Performance and scalability have always been a key design goal of NEBA, as it is used in many large-scale Content Management deployments. With 5.0.0, NEBA ships a lightning-fast factory for models not managed in a Spring Application Context.
The NEBA Spring integration is upgraded to Spring 5, the current GA version of the Spring Framework (release notes). This includes an upgrade to Gemini Blueprint 3.0.0 (release notes).
NEBA follows a simple rule:
@Inject is for OSGi services, NEBA annotations are for content mapping. Of course, users of NEBA's Spring module can continue leveraging all
capabilities of the Application context to inject their models.
Along with the 5.0.0 release, NEBA also release a new website that adheres to the same principles as NEBA: Simplicity and performance. For this release, the Documentation has been restructured, revised and extensively updated.
NEBA 5.0.0 supports AEM 6.2, 6.3 and 6.4 as well as the Sling versions packaged as Sling App 9 and 10 and runs on both Oracle and OpenJDK 8.
Users of 4.3.x need to follow the following steps to upgrade their application.
NEBA 5.0.0 now offers a choice between just using the flyweight neba core or using the neba core along with the neba spring integration. If you are heavily relying on NEBA's Spring MVC integration, you might want to continue using NEBA with Spring. In this case, simply use the NEBA delivery package containing the Spring integration and continue using NEBA with minor adaptations. Most prominently, the annotation @ResourceModel is no longer annotated with @Component. This means that in order to detect your @ResourceModel classes as Spring beans, you must annotate them with @Component and @Scope (see A Spring-Bean based Resource Model" below).
If you are exclusively using resource models or only a few MVC features, consider switching to just using NEBA core. In this case, Spring @Service beans should become OSGi Services (e.g. using the
@Component annotation) and
resource models should use @Inject and, if necessary, the @Filter annotation to wire these service dependencies.
NEBA 5.0.0 ships with Spring 5.0.x. If you choose to continue using Spring, you must update the Spring dependencies accordingly.
In 5.0.0, the
@PreMapping annotation has been removed. If you require this rare use case, consider introducing a Custom annotation instead.
@PostMapping annotation has been renamed to @AfterMapping, usages must be updated accordingly.
In 5.0.0, NEBA's deprecated
Optional interface for lazy-loading 1:1 relationships has been removed. Users of NEBA's
Optional interface must use Lazy instead.
NEBA extension points are now situated in the dedicated io.neba.api.spi package.
The @ResourceParam annotation has been moved to the neba-spring bundle and has thus been moved from
io.neba.api.annotations to the