karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: OSGi related PoC and Karaf
Date Thu, 15 Jun 2017 08:59:27 GMT
2017-06-15 10:38 GMT+02:00 Milen Dyankov <milendyankov@gmail.com>:

> 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.
>

That would be great. Looking forsward to see how it looks like.

Christian


>
> 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" <chris@die-schneider.net>
> 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 <milendyankov@gmail.com>:
> >
> > > 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 <
> > > chris@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 <milendyankov@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
> > >
> >
> >
> >
> > --
> > --
> > 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>
> >
>



-- 
-- 
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>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message