Apache Sling 6 Released

Bringing Back the Fun

Apache Sling brings back the fun to Java developers and makes the life of a web developer much easier. It combines current state of the art technologies and methods like OSGi, REST, scripting, and JCR.

The main focus of Sling deals with the important task of bringing your content into the web and providing a platform to manage/update the content in a REST style.

Sling is built as OSGi bundles and therefore benefits from all advantages of OSGi. On the development side a scripting layer (leveraging the Java Scripting API) allows to use any scripting language with Sling (of course you can use plain old Java, too). And on top of this, Sling helps in developing an application in a RESTful way.

As the first web framework dedicated to JSR-283 Java Content Repositories, Sling makes it very simple to implement simple applications, while providing an enterprise-level framework for more complex applications. Underneath the covers Apache Jackrabbit is used for the repository implementation.

Download the new release, Apache Sling 6, today and give it a try!

Apache Sling currently comes in four flavors:
  • A standalone Java application (a jar containing everything to get started with Sling)
  • A web application (just drop this into your favorite web container)
  • The full source package (interested in reading the source?)
  • Maven Artifacts (available from the Central Maven Repository)
For more information, please visit the Apache Sling web site or go directly to the download site.

For those interested in numbers: Since the Apache Sling 5 announcement ...
  • 22 months have passed
  • 7 committers have been added to Apache Sling
  • 3 members have been added to the Apache Sling PMC
  • 158 releases have been cut and voted on
  • ~2800 commits have been sent to the SVN repository
I would like to thank every user, contributor, committer and member of the PMC for their hard work and sometimes patience for making Apache Sling 6 a reality.

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Ready to serve requests ...

In the Apache Sling project we have an interesting problem : Knowing when the application has finished its startup. Coming from a background of a traditional application, you know when the system has finished its startup. For example, a servlet container knows it has finished the startup, when all web applications have been started. In Apache Sling, the situation is a bit different: Apache Sling is an extensible system, where extensions may simply be added by adding more bundles. "Easy", you say, "just wait for all bundles to have been started and you know when the application is ready". True, but there is a catch. To extend Apache Sling, you register services with the OSGi registry. "Still easy", you might say. Right, if the services are all started by bundle activators, we still can depend on having all bundles started for the system to be ready. Again, this is only part of the story: Some services depend on other services. So the dependent services may
Mehr anzeigen

LinkedHashMap's hidden (?) features

Recently I discovered two very nice features of the java.util.LinkedHashMap : accessOrder and removeEldestEntry(Entry) . These features combined let you implement simple LRU caches in under two minutes. accessOrder The accessOrder flag is set when creating the LinkedHashMap instance using the LinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder) constructor. This boolean flag specifies how the entries in the map are ordered: accessOrder=true The elements are ordered according to their access: When iterating over the map the most recently accessed entry is returned first and the least recently accessed element is returned last. Only the get , put , and putAll methods influence this ordering. accessOrder=false The elements are ordered according to their insertion. This is the default if any of the other LinkedHashMap constructors is used. In this ordering read access to the map has no influence on element ordering. removeEdlestEntry(Entry) The second feature of
Mehr anzeigen

OSGi Framework Extension as a Maven Project

In a previous post I explained how to extend an OSGi framework such that more classes are visible inside the framework from the outside world. This posting provided a very simple example to generate Framework Extension Bundle using a single file and calling the JAR tool from the command line. Here I will expand on this example by creating a Maven 2 project, which may be used in environments where Maven 2 is used for project builds. As a first step, we need a Maven 2 project descriptor. To create this beast, we have to decide, how we build the project. I generally use the Apache Felix Maven Bundle Plugin to build my projects as OSGi bundles. This great plugin comes with support for Maven 2 packaging but also provides goals to call if the packaging functionality should not be used. Before talking too much, let me just present a project descriptor, which I know works. After that I will explain why I did it, like I did it. <project xmlns="http://maven.apache.org/POM/4.0.0"
Mehr anzeigen