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=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
