Hi Chris, I somehow didn’t see this mail together with the earlier one. For some reason it didn’t show up in my Gmail inbox, and I only noticed it after checking lists.apache.org directly.
As I mentioned in my reply to the other thread, embedding BifroMQ into another application as an MQTT broker runtime is indeed a new and interesting angle for us. Architecturally, BifroMQ can already run as a standalone single-node instance — after all, even a cluster always starts from the first node 🙂 The reason we’ve so far kept the current distribution model is largely historical and practical. BifroMQ originated from a cloud-native, distributed system deployment scenario, and many of the early design choices were driven by that context. Internally, the codebase is still evolving quite actively as we continue to optimize architecture and performance. Because of that, we’ve been cautious about publishing more than well-defined, stable modules to Maven Central, to avoid creating unnecessary friction or breakage for downstream users, especially plugin developers who integrate against those artifacts. The industrial automation use case you described is very valuable input. I can see how a more “embedded” consumption model would make adoption much easier in those environments. Personally, I’m not opposed to exploring this direction in future versions. From a technical perspective, I think this is something we can discuss further — for example, whether it makes more sense to provide an OSGi-compliant bundle(an area that’s relatively new to me), or a single fat-jar maven artifact that can be embedded more easily. Thanks again for sharing your experience and perspective. Best, On Fri, Dec 19, 2025 at 2:15 AM Christofer Dutz <[email protected]> wrote: > Hi all, > > As this came up recently, I just wanted to bring in another angle and > possibly ask for insights, as I might be on a completely wrong track and > there’s a chance for me to learn something. > > I’m really interested in learning, as I stepped up for becoming your > Mentor, as an enterprise-level MQTT broker is something I have been hoping > for a long time to come to Apache as for me it’s an important missing piece > in my vision of a pure-Apache IIoT toolchain. > > That being said: Just because you say: our software is distributed via > binary archive downloads or docker containers, doesn’t necessarily mean > that’s the only way it’s being used. > > Just as an example: Apache IoTDB is generally also used as a downloadable > binary distribution or docker containers. However, I have also seen that > the automation industry is usually unable to consume things distributed > that way. Configuring a system by editing config files is just something > they don’t do. Also do they in most cases not even require a clustered > installation in 90% of the cases. > > So I personally like to include IoTDB in applications or ship it as > plugins to run inside other systems and provide the bells and whistles to > integrate it with bigger systems and to configure and monitor them via some > tools they know how to use. > > I could imagine a similar approach for BifroMQ … If a customer wants to > start with it, he can simply bring up a single node instance to get started > … if he needs/wants more, that’s the second step. > > So what would prevent us from distributing also the other jars via maven > central? > (I mean for me it doesn’t matter … build it locally and I have them > locally … I’m just thinking of other potential users) > > Chris > > -- Yonny(Yu) Hao
