Nibiru just released a Java, server-side development, framework. As you can see, Nibiru isn't just a mobile development company :)

The framework objective is to facilitate the building of modular applications. The following goals are established in order to meet such objective:

• Providing an abstraction layer over different technologies in order to avoid coupling.
• Providing services which are common to business applications, such as CRUDs, reports, work ow, transaction management, security and internationalization.
• Providing dynamic update mechanisms for the system in order to allow hot swapping.
• Implementing patterns which facilitate solving problems in a structured way. But avoiding to force the user to implement a given solution.
• Facilitate decoupled communication among modules.
• Avoiding reinvent the wheel. Creating layers of abstraction but using existing technologies when possible.

The implementations are based on many technologies, such as OSGi, Vaadin, Spring and Hibernate.

More info at:

• http://nibiru.googlecode.com/
• http://blog.oxen.com.ar/2011/10/nibiru-framework-released.html

Just a correction: the name of our company is Oxen, Nibiru is the name of the framework :)

• Providing an abstraction layer over different technologies in order to avoid coupling.

Argh, yet another one! But then, aren't you tied to this non-standardized "abstraction layer".

In some way yes, but the idea is providing simlpe interfaces for accessing just the functionality you need. For example, instead of acessing the full HTTP session, we use a simpler "Session" interface which provides methods for storing data. Another example (that we faced with Android, not with Nibiru :) ). We have a simple bean wrapper interface over Spring bean wrapper.... when we started developing for Android, we weren't able to use Spring, but we changed the implementation for a simpler, android compatible, one. Some simliar happens with the MVP pattern (implemented by Nibiru): you have interfaces such as HasValue, HasClickHandlers. Just what you need.

Nibiru is mostly an skeleton of interfaces. For building typical enterprise applications it provides you some patterns and common services pre "designed". The fact is, if your business is building many different enterprise apps, Nibiru can help you to build the architectural skeleton, however at the cost of depending on its interfaces. If this is not your business, however, I think Nibiru wouldn't help too much.

I wrote a brief motivation section. I hope it helps.

http://code.google.com/p/nibiru/wiki/motivation

They have a document with "Crazy ideas..." about the future of the framework, this really got me interested: "Make a non-OSGi version".

In fact, I think that it wouldn't be too complicated to make it non-OSGi. Almost all the components dont't depend on OSGi (they are injected using Spring DM). You would loose the dynamic module update fucntionality, but the application wouldn't require an OSGi container (which can be a customer restriction, for example).

The idea behind using OSGi was providing the framework with modularity. Everithing is dynamic. For example, you can add on runtime a module and the framework and the application menus are updated. Or the actions on the CRUD engine. However, we "hide" OSGi behind an "ExtensionPointManager" interface (that's another example of the usefulness of adding an abstraction layer).

Actually seeing it was OSGi from day one got me interested (my comment wasn't clear). Most frameworks are kind of painful to use in OSGi (due to classloading and dynamic behavior), it's great to see a full-blown framework with all the bells and whistles using OSGi, it's good to dispel some myths about OSGi's complexity.

Oh, ok. I didn't understand :)

After working with OSGi, I have the same feeling. There is some extra complexity, but it is manageable. For example, putting JPA to work under OSGi required us some effort, but not too much. Once we were able of exposing EntityManagerFactory as a service, using JPA became really easy.

I think service dependencies problems were the kind of issue which made us spend more time. But it is inevitable due to dynamic nature of OSGi. Sometimes we needed to reduce the Spring DM timeout, but with many active services, it can be hard to detect where is the problem.

Well, that is inherent to another OSGi advantage: the architecture promotes using fine grained services :)

great thats its not for mobile only..gives us a lot of options

monroe dimaggio

what great news

sell sheet design