How can we help you? What are you interested in? What do you wanted to try?
"Everything!" :)
I'll backstory a bit to tell where I'm coming from.
Long time Java person, mostly back end EE stuff. As a general rule, I know my way around a classloader.
We have a current project that I've been part time trying to convert wholesale to OSGI. Ostensibly, we just wanted a bit of a plugin functionality, but "nice to have" was things like incremental updates, and such like that. So, rather than just making the plugins OSGI, I felt I'd just try the whole thing. It's a CLI server application.
My first goal was simply to use OSGI as a fancy classloader. Instead of one large Maven shaded Jar file, it would be a cluster of modules. But no higher level OSGI concepts (i.e. services and such). I don't know if that's the best way to go about this or not, but it seemed a reasonable path. I'd have to resolve all of these dependencies anyway, and this way I wouldn't have to rewrite any real code (in theory).
After several months, I finally managed to get all of the modules loaded into Felix, resolved, and started. That was a "IT WORKS!" moment, to a point. At this point, it has 170 modules >.<. It's been a crash course in dependencies, using BND to convert existing jars, hacking ad hoc tooling (i.e. some shell scripts) to make this process at all reasonable, even if brute force. (e.g. erasing my Felix install is a key part of my workflow) I even wrote some dependency tracing code, parsing manifests, to see if I could make getting everything resolved easier, but in the end I found it was easier to just dump everything into Felix, and just try to start modules one by one to see what they complained about. I found that a better way to eat the elephant.
Once everything Installed, I made a simple activator that basically called my static main(), just to see if it starts, just to see what stack traces I may get.
Well, the system is using a lot of SLF4J, and SLF4J out of the box does nothing, so the app "starts", logs a nice "SLF4J isn't doing anything" message, waits for a few seconds, and then calls System.exit(), which just shuts it all down. So, it could be pouring out heaps of stack traces to the logger that SLF4J defaults to /dev/null with none the wiser. So, now I've been trying to get SLF4J to work.
So, that's my OSGI background. This is what you get when you rely on Google and ChatGPT and old OSGI PDFs from 2002.
But that's not what brought me here.
I wanted to start a greenfield project. Another small CLI project, that's mostly a proof of concept of "if we were to use OSGI for this, what would it look like".
Since it's a greenfield, I wanted to "do it right", or at least better. I was looking around for Maven prototypes to help create a project. I use NetBeans, which is more or less a Maven IDE. So, if Maven can do it, I can use NB to work with it. Right now, with the other project, it's all been just getting stuff into Felix to start. I've give no thought to the actual dev lifecycle, or packaging, or anything. It's just been building the project, running a bunch of BND commands, shuffling jars around. Then I delete Felix, unzip a fresh copy, copy everything into 'bundle', and fire it up.
I'd like a better workflow for this. Right-click -> Run kind of experience. I don't even know how OSGI projects are typically bundled. Apparently there's all sorts of ways.
But, anyway, I went and tried the enRoute project archetype, and it immediately fails:
[ERROR] Error : The runbundles have changed. Failing the build!
Was: null
Is: \
com.example.impl;version='[1.0.0,1.0.1)',\
org.apache.felix.scr;version='[2.1.10,2.1.11)'
Not a great "out of box" experience.
The good and the bad of OSGI is that it's been around a long time, which makes the Interwebs fraught it old and new information. It's clearly "not dead", there's activity in the space. But it's also widely applied so you run into it in all sorts of use cases (like the Adobe/LifeRay example).
Also, it seems well entrenched in the Eclipse community, but I'm trying to avoid Eclipse (the IDE, not the organization) since I don't use it, and those folks I work with don't use it. Maven is our common core.
I get the feeling for the 80-90% use cases, OSGI is "simple enough", but all of the variety sure makes it hard to approach. "Which is right for me?"
So, put it simply, I guess I'm, for now, looking for an onramp to a Maven project structure that will let me readily run and debug some OSGI modules, not so worried about packaging at this point. Just want to get started knitting some services together.
And, most importantly, just finding folks to "talk about OSGI" with to better explore the space. This is where the SO "Question/Answer" format is lousy. You can't just "talk" and followup questions and express understanding (or not!).
Thanks for the quick response.
Regards,
Will Hartung
