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.
Contents
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
Improvements
Fixed bugs
Upgrading from 4.3.x
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
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
@Filter("(some=filter)")
private Service service;
}
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.
Upgrading from previous versions
Please use the below form to see the upgrade path from one version of NEBA to another.
Upgrading from 4.3.x
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;
}
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
@Filter("(some=filter)")
private Service service;
}
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.
Upgrading from previous versions
Please use the below form to see the upgrade path from one version of NEBA to another.