I didn't just refactor—I built something legendary this week.
In a new project, I vibe-coded a converter that's pure magic:
Takes OSGi MANIFEST.MF files and transforms them into clean JPMS module-info.java, Exports become exports, imports become requires, Transitive visibility gets the proper requires transitive treatment,
Then it injects all those dependencies right into the pom.xml.
It's not just a tool—it's a time machine that brings our bundles into 2026.
Meanwhile in core, I was playing architectural surgeon:
Split packages were the tumor I had to remove, All test bundles reorganized, dependencies untangled,
ch.ivyteam.ivy.server scattered across bundles? GONE.
Each package now owns its namespace—no duplicates, no chaos, no pain.
I split engine from server like separating conjoined twins—finally they can breathe.
The end goal? A clean runway for migration.
When we're ready to flip the switch from OSGi to JPMS, the codebase will be pristine. No split packages blocking the way, no hidden dependencies lurking, Just pure, modular, Java-native goodness.
Hundreds of commits. One vision. Future-proof code. 🚀
📚 JPMS Explained: Java's Module System
What is JPMS?
JPMS = Java Platform Module System
It's Java's native way of organizing code into modules. Think of it as a more powerful, built-in alternative to OSGi that arrived with Java 9 in 2017.
How It Works: module-info.java
Every module has a module-info.java file at the root of its source:
module com.example.myapp {
requires java.base; // I need this module
requires transitive com.example.api; // I need this, AND you'll need it too
exports com.example.service; // I'm exposing this package
exports com.example.model;
}
This declares:
- ✅ What modules this module depends on
- ✅ What packages are public API
- ✅ What stays internal/hidden
Why We're Moving to JPMS
🎯 Clarity
OSGi is powerful but confusing. JPMS is simple and Java-native.
âš¡ Performance
The JVM understands modules natively. Better optimization, faster startup.
🚀 Industry Standard
Spring Boot, Quarkus, Jakarta EE—everyone's on JPMS now.
📦 Less Magic
No complex version negotiation, no split packages nightmares.
My Converter Tool
What I built takes OSGi bundles and translates them:
OSGi MANIFEST.MF → JPMS module-info.java
├─ Bundle-Name → module name
├─ Export-Package → exports
└─ Require-Bundle → requires (transitive)
PLUS: Injects Maven dependencies into pom.xml
It's like a translator between two languages of modularity.
The Future
Once we complete the JPMS migration:
✅ Smaller bundle sizes
✅ Faster startup times
✅ Clearer dependencies
✅ Easier to maintain and extend
✅ Ready for Java 25, and beyond
