Two weeks ago I sent a form to OSGi dev mailing list. My goal was to have an idea how others use OSGi in their projects. In the last couple of years, we developed 100+ OpenSource modules, Maven plugins and released them on Maven Central. We found these libraries very useful in our projects, but I was wondering how others solve the same goals.
As there were several questions, I share the summary of the responses in series of blog posts. I will also add the following information to each questions:
- Why I asked it?
- What conclusion did I draw from the answers?
Number of answers
41 answers arrived, including mine. I guess only geeks are subscribed to the OSGi dev mailing list, and the opinion of those geeks represent the view of their close colleagues, too.
I asked if I can share their answer anonymously. Here is the summary of responses:
I do not think I have to comment on this one :).
Build tool fragmentation
There are several build tools for Java (ANT, Maven, Gradle, …), and all of them has some support for OSGi. I was interested if the community has already chosen the best one for OSGi development.
The following tools appeared in the other section:
- PDE
- Tycho
- Bndtools
- Liferay Gradle plugin
I am pretty happy with these answers as they showed the same what my hypothesis was. There is no preferred build tool that would get 90% of the votes. Maven is more popular than Gradle at the moment despite the fact that Gradle is advertised by several core members of OSGi.
Missing features in Build tools
11 people answered the question about the missing features of build tools. Here is a list of answers:
- P2 repo. support
- nothing really (we mostly implement ourselves what we miss)
- A simple/lightweight method for packaging and running automated tests in OSGi; existing solutions involve a lot of ‘useless magic’. I usually use a home made launcher.
- Simplicity
- More granular compilation and hot deployments (using Karaf)
- I think they do everything but they are hard to use and don’t cooperate very well. An example is I have a bnd build configured for bndrun and resolution but that doesnt work with my maven build terribly well as I still have to have a workspace. I also like to use eclipse but some others don’t so it would be nice if they were ide agnostic.
- we use maven with maven-bundle-plugin and not bnd (reasons: bnd being too OSGi centric, bad IntelliJ support, lacking extra maven features); we miss: proper packaging (maven assemblies vs OSGi resolved distributions); maven’s lack of flexibility ; maven’s lack of automated semantic versioning at releases.
- Easy unit tests with DS/SCR w/o container
- none
- Fast deployment, hot code replacement
- Ant based Plugin SDK which we has till 6.2 though we have gradle based liferay workspace but it has not fullfledged features.
Build tool plugins of Everit?
We have a Maven plugin, too, that solves the following issues (other developers mentioned some of them):
- Generating OSGi environments and adding all maven dependencies to them
- The OSGi environments are described in ZIP files, and they are also maven artifacts. Therefore, any company can make a custom environment (e.g.: packaging a Glassfish or Liferay as an environment)
- Starting the environments during the integration-test phase of maven to run tests that are implemented in one or more of the dependencies (or in the project that specifies the environment)
- Hot replacement of the modules with a maven build if the environment is already started
If you have not used it till now, do not start using it now. Version 4.0.0 will come within weeks and besides that it will lots of new features, and it will be incompatible with the 3.x branch. I will write a detailed blog post about the new version and its usage when it released.
Development Environments
The next chapter about the questions of Development Environments will come within a couple of days. Stay tuned!
Balazs Zsoldos is the co-founder of Everit. He is the leader of the development of Everit OpenSource Components. Developing Java based solutions is not only his job but also his passion. He believes in simplicity. That is why he decided to design and build as many simple, but useful goal-oriented modules as he can. As the base of the stack, he chose OSGi. Balazs does not believe in monoholitic frameworks, therefore all of the solutions that was designed by him can be used separately. In the beginning of his career, Balazs was a big fan of JEE and Spring. After a while, he changed his mind and started to try replacing everything with non-magical solutions that do not contain interceptors, weaving, etc.
[…] 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 first part is here. […]