A couple of weeks ago I sent a form to OSGi dev mailing list. I have started to share the summary of answers with the community. As there were many questions, I decided to split the content and publicize it as several posts. If you are interested, the previous part is here.
I was curious what platforms people use. We use only nature OSGi containers at the moment with self-selected modules. We set up the Dev, Test and Production server with a self-written maven plugin. However, this maven plugin could setup an environment based on a complex project, too (e.g.: bundling glassfish). It is time to check what others use, what we should support next:
Must note that the third answer is Apache Sling / Adobe AEM and the 6th answer is Nature OSGi container.
List of other answers:
- Equinox standalone
- JBoss AS OSGi
- Eclipse Equinox/E4
- Apache Felix
I must say that I am a bit surprised. A percent of the OSGi related job advertisements look for Adobe AEM developers based on my research. Where were you Sling / AEM programmers?
I had the hypothesis that Declarative Services is the most preferred component model in the OSGi world. Seems that I was right:
Other answers were:
- Eclipse e4
- Apache Felix Dependency Manager (2x)
- Plain Old OSGi Servicetrackers
- Currently migrating from SpringDM to DS
- Domino (Scala DSL)
- Native OSGI
- plain osgi
- Everit Component Model
I must say, we have a winner :). And that is no surprise; Declarative Services has far the greatest concept from all I have seen (I used to develop Java EE and Spring and Blueprint based applications). I disagree with only one part of the concept, how it handles multi-cardinality references.
There might be a bit of misunderstanding here. I was interested if anyone uses a Java EE server below OSGi. Nowadays most of the Java EE Application Servers are built on top of OSGi somehow (E.g.: Glassfish beginning version 3.0). Here are the answers:
Other section contained Karaf and Tomcat several times.
Preferred persistence technology
Persistence is a fascinating question in the OSGi world. As former Java EE and Spring developers, we new JPA. After switching to OSGi, we tried to push JPA into our new projects, too. I re-implemented the JPA chapter of the OSGi Enterprise specification from ground to get the best support. It seems that many other developers are in a similar situation that we were:
Other mentioned persistence technologies:
- Jackrabbit Oak
- Our own solution: Information Grid
- Straight JDBC and JdbcTemplate
- Plain JDBC
- Hibernate (through a custom framework called ServiceBuilder)
After a year of struggling, we decided to look around. I analyzed all of the persistence related technologies I could find. I came up with the idea to use Liquibase with Querydsl. Since that, I feel that I came out from the sea of unexpected issues.
To all JPA users: I honestly suggest that you should look around! JPA and OSGi just do not fit together in concept, no matter how much of free time is sacrificed by enthusiastic geeks.
I was interested what others use to generate web user interfaces. I saw so many trends in the last two decades but saw almost no satisfied developer. When OSGi comes into the picture, the question is even more interesting as many of the concepts will fail on top of it. As I said, there are many technology stacks. I wrote a couple of examples but expected to have more other answers than anything else. Here are the answers:
The Other answers in details:
- Vaadin (5x)
- JSP., Sightly
- react.js, scala.js
- Angular (4x)
- Our web UI is not written in OSGi and is mainly HTML/CSS/JS
- JQuery, Knockout
- Web Components
- JSPs, Portlets, Freemarker, Velocity, Soy, XSLT, and many others
- JSP, Metal.js, AlloyUI ,jQuery
- Liferay’s MVCPortlet
- Alloy UI
- liferay mvc portlet (2x)
- Custom (2x)
Wow! I must say this is fragmented. Probably there are more AngularJS + Rest users than others. One reason can be that enRoute gives samples for this solution.
For applications that have many static contents and forms, but not rich-client like behavior, I found server side templating a better choice. I had an idea how to do server-side templating. I did a search and found the project Thymeleaf that had very similar syntax that I had in mind. The issue is that Thymeleaf has other features that do not fit into a modular concept, and the developers did not want to put the OSGi Manifest headers into their JAR files. Therefore, I reimplemented what I need in a very simple project: https://github.com/everit-org/templating-html.
Since we use this concept, the learning curve was greatly shortened and the code keeps simple. It is only about templating and rendering the HTML output. As for navigation, we only have project specific solutions yet.
Are there other useful technologies?
I do a lot of searching on the internet. I was interested if I missed something. Here is the list of answers:
- bnd-maven-plugin, karaf-maven-plugin
- Bnd & Bndtools
- We’re already doing a little OSGi development tooling as part of https://sling.apache.org/documentation/development/ide-tooling.html . Maybe it would be interesting to collaborate in an open source environment at Apache.
- bnd, Scala, Apache Felix dependencymanager.lambda
- bnd command line
- EventAdmin, HttpService, ECF Remote Services
- gradle-karaf-plugin, gradle-bundle-plugin
- just bndtools
- Gson and Jackson, Flyway, Docker, …
- The current Apache Karaf Maven Plugin which checks possible runtime requirement problems right at compile time for given Apache Karaf Features
- Clirr reports
- DS Annotation Builder
- Bnd tools / enRoute
- CM, Metatype, Baseline, bnd
- Sublime Text, node
- SSH/SCP, ConfigAdmin + FileInstall in Karaf
- BND command line to introspect bundles
- bnd tools, blade tools
- The ones we implemented 😉
Part 4 will be the last in this series. The questions of bundle deployment, how to find the best solution, and the question of complaints are left. Stay tuned!