NEBA 5.0.0 released

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.


Highlights of this release

NEBA 5.0.0 becomes independent of the Spring Framework

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.

Cleaner, simpler API

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.

Even Faster

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.

Update to Spring 5

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).

Simple rules for dependency injection and content mapping

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.

Revised documentation

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.

Supported AEM and Java Versions

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.

Release notes


    Fixed bugs

      Upgrading from 4.3.x

      Users of 4.3.x need to follow the following steps to upgrade their application.

      Neba core and Neba Spring

      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.

      A Spring-Bean based Resource Model

      import io.neba.api.annotations.ResourceModel;
      import org.springframework.stereotype.Component;
      import org.springframework.context.annotation.Scope;
      import org.eclipse.gemini.blueprint.extensions.annotation.ServiceReference;
      @Component //Required for Spring's class path scanning
      @Scope("prototype") //Resource models must have prototype scope
      @ResourceModel(types = "myproject/components/myComponent")
      public class MyModel {
          @ServiceReference(filter="(some=filter)") //Provided by the gemini-blueprint-extensions bundle.
          private Service service;
      A Spring-based Resource Model

      The bundle containing this model must of course contain a Blueprint application context definition to create the respective Spring Application Context.

      A Resource model without Spring

      package my.bundle.namespace;
      import io.neba.api.annotations.ResourceModel;
      @ResourceModel(types = "myproject/components/myComponent")
      public class MyModel {
          @Inject // @Inject is for OSGi Services
          private Service service;
      A NEBA resource model without Spring

      Here, the package my.bundle.namespace would need to be in the Neba-Packages bundle header.

      Upgrade to Spring 5

      NEBA 5.0.0 ships with Spring 5.0.x. If you choose to continue using Spring, you must update the Spring dependencies accordingly.

      Remove usages of @PreMapping, change usages of @PostMapping to @AfterMapping

      In 5.0.0, the @PreMapping annotation has been removed. If you require this rare use case, consider introducing a Custom annotation instead. The @PostMapping annotation has been renamed to @AfterMapping, usages must be updated accordingly.

      io.neba.api.resourcemodels.Optional is removed and replaced with io.neba.api.resourcemodels.Lazy

      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.

      Package change for Service Provider Interfaces such as AnnotatedFieldMapper or ResourceModelPostProcessor

      NEBA extension points are now situated in the dedicated io.neba.api.spi package.

      Package change for Spring-specific @ResourceParam annotation

      The @ResourceParam annotation has been moved to the neba-spring bundle and has thus been moved from io.neba.api.annotations to the io.neba.spring.api package.