I'm actually thinking of taking your chat demo and reimplementing it with EM just to see if it will make it easier to understand for non-OSGi folks and perhaps better demonstrate the purpose of EM.
The examples I have now are very simple and from the perspective of large OSGI projects do not seem to add any value. That's why I was hoping to get some ideas/help to move towards more "real life" examples. Best, Milen 14 cze 2017 22:19 "Christian Schneider" <[email protected]> napisał(a): > Actually I hope we can make OSGi so easy to use that you do not need to be > an expert to start using it. > With a coarse grained modular approach where you just need to enumerate > some technologies to combine I think we can achieve a lot in this regard. > > Still I have doubts that we can make it as simple as spring boot. Spring > boot emphasizes easy setup at the cost of higher coupling. The problem is > that people only realize this when they bought into the technology as the > coupling only becomes a problem once your project grows. > > So I think we need to not try to be as simple as spring boot and instead > sell the better modularity combined with reasonable simplicity. > > Christian > > 2017-06-14 21:52 GMT+02:00 Milen Dyankov <[email protected]>: > > > 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 < > > [email protected]> 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 <[email protected]>: > > > > > > > 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 > > > > > > -- > -- > 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> >
