Thanks for your comments Christian, I understand this goes too far into making things simple to be useful for OSGi veterans. And that's OK. I don't aim to make OSGi or BND better for those who master them, but to lower the entry barrier. I think (especially with JPMS promise for simple modularity around the corner) we need to show to developers the benefits in the simplest possible way. I already presented this concept to a couple of conferences. I haven't mentioned OSGi not even once during the talks - just presented it as new concept for dependency management. From my experience the moment you mention OSGi to an average 20+ years old java developer you'll see his ironic smile and then his back. After this talk some people who never thought of modular apps before were quite interested. Some of them mentioned they never understand the point of modularity this way (for them it was simply putting code is separate jar files).
The reason I though of Karaf is because I know JB and other have been discussing KarafBoot and I think it has a similar goal (but different approach). I alway wanted a ModularityBoot kind of thing that will be simple and at the same time flexible as far as choosing a runtime is concerned. So I thought I'll share this with you here in case we can somehow combine the ideas. As for the parent POM, I'm aware of that possibility but I didn't used on purpose. In fact you'll see the demo.* projects don't actually have a parent, they are just aggregated in the demo project. The reason is, I use this in my talk and I want to point out those are completely free to use any corporate parent pom they need to. Best, Milen On Wed, Jun 14, 2017 at 8:59 PM, Christian Schneider < ch...@die-schneider.net> wrote: > Hi Milen, > > the concept is interesting when you are outside of OSGi but in that case I > doubt people will use OSGi requirements and tools even if it woud make > sense. > > When inside OSGi I do not see a big benefit compared to using plain > bnd-maven-plugin, bnd-index-plugin and bnd-export-plugin like I use in > https://github.com/cschneider/osgi-chat . > Merging all this functionality into one plugin is not a good idea imho. I > prefer the unix like idea of small single purpose projects. > > As a general improvement for the bnd toolset I could imagine that the > bnd-export-maven-plugin uses the current pom as a basis for an OBR index by > default. So if you just need one packaging you could omit the separate > index pom that I use right now. Another possible improvement would be that > it can be put in the parent and auto exports all bndrun files it finds. > > I agree that a bndrun file is a bit difficult to write from scratch. I > wonder if we could provide parts of it from bundles that form kind of > profiles. These could then contribute to the system package exports or > other settings for specific technologies by using special Manifest headers. > Such information could then be used by bnd as well as karaf to setup the > runtime correctly. > > One thing you could improve in your code is to define > the em-maven-extension in the parent. So the individual projects do not > need it. > I did this for the bnd-maven-plugin so each project just needs a bnd.bnd > file if it wants to override defaults. > > Christian > > 2017-06-14 13:46 GMT+02:00 Milen Dyankov <milendyan...@gmail.com>: > > > Hi Karaf developers, > > > > I'd like to ask you to have a look at something I've been working on. > It's > > a PoC called Eccentric Modularity (EM) and it's available here > > https://github.com/azzazzel/EM > > > > The basic idea is to provide a jump start into modularity (particularly > in > > the scope of resolving dependencies and assembling applications from > > modules) for people not familiar with OSGi. In fact it tries to hide OSGi > > from the developer as much as possible. There is not much documentation > but > > hopefully the demo projects > > <https://github.com/azzazzel/EM/tree/master/demo> (and the slides > > <https://www.slideshare.net/MilenDyankov1/fantastic-java- > > contracts-and-where-to-define-them> > > from the relevant talk) would help you understand the intention. > > > > From code perspective it's just a (somewhat ugly) hack dynamically adding > > bnd maven plugins to a Maven project based on properties. So please > ignore > > the actual implementation (it's just a PoC) and focus on the > idea/concept. > > > > > > Why I am sending this to karaf's dev mailing list? To see if Karaf and EM > > can help each other in any way. For example > > - adding Karaf as target runtime (next to liferay </>) should be very > easy > > - perhaps EM can extended to also generate executable jar (spring-boot > > like) powered by Karaf (it now uses BND's launcher) > > - perhaps Karaf features can be special dependencies (like indexes > > <https://github.com/azzazzel/EM/blob/master/demo/rest/pom.xml#L61>) that > > the resolver can use > > - perhaps EM can generate a feature based on the resolver results > > > > Those are just a few ideas I'd like to share with you and see what do you > > think? If the concepts EM present turn out to be something developers are > > interested in, it can evolve into real project. Perhaps one that Karaf > can > > also benefit from. > > > > > > Regards, > > Milen > > > > -- > > http://about.me/milen > > > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e > 46&URL=http%3a%2f%2fwww.liquid-reality.de> > > Open Source Architect > http://www.talend.com > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e > 46&URL=http%3a%2f%2fwww.talend.com> > -- http://about.me/milen
