You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Milen Dyankov <mi...@gmail.com> on 2017/06/14 11:46:12 UTC
OSGi related PoC and Karaf
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
Re: OSGi related PoC and Karaf
Posted by Milen Dyankov <mi...@gmail.com>.
Thanks JB,
no I don't use Karaf right now. But I'd love to make it work with Karaf
once I have the time. What I envision is something where I can have
`<_.eccentric.modularity.executable.karaf
/>` in my POM and it will assemble a runtime with Karaf and all the
bundles/features resolved from my POM.
On Wed, Jun 14, 2017 at 3:44 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi,
>
> it sounds interesting but I don't really get the relationship. You don't
> use Karaf now right ?
>
> I would love to chat with you about this.
> Regards
> JB
>
> On 06/14/2017 01:46 PM, Milen Dyankov wrote:
>
>> 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-con
>> tracts-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
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
http://about.me/milen
Re: OSGi related PoC and Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
it sounds interesting but I don't really get the relationship. You don't use
Karaf now right ?
I would love to chat with you about this.
Regards
JB
On 06/14/2017 01:46 PM, Milen Dyankov wrote:
> 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
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: OSGi related PoC and Karaf
Posted by Christian Schneider <ch...@die-schneider.net>.
There is a big overlap between the jax-rs whiteboard and the jax-rs
providers for RSA.
We also discussed about this on the aries list.
In practice you can use any of the alternatives with different drawbacks.
Christian
2017-06-15 20:39 GMT+02:00 Milen Dyankov <mi...@gmail.com>:
> Hmm ok I'm confused. I was thinking about the JAX-RS Services whiteboard
> spec that is now being implemented in Apache Aries. I'm aware of the the
> remote services spec but not sure how it relates to jax-rs connector .
>
>
>
> 15 cze 2017 20:11 "Scott Lewis" <sl...@composent.com> napisał(a):
>
> On 6/15/2017 1:24 AM, Milen Dyankov wrote:
>
> > Thanks Scott,
> >
> > I was looking into that some time ago but AFAIK it comes in R7. Not sure
> if
> > thete is anything released at this point that would work with R6.
> >
>
> Were you saying 'there'? The OSGi remote services and RSA specs have been
> quite stable since R5 (chap 100 and 122 in compendium).
>
> The Jax-RS distribution provider impls that I'm aware of are ECF's [1].
> It supports Jersey's or CXF's Jax-RS impls.
>
> I will attempt to work on a reworking of your POC remote service metadata
> for a pull request, after the upcoming ECF release (June 28 I think).
>
> Scott
>
> [1] https://github.com/ECF/JaxRSProviders
>
>
> So for
> > now I just decided to go with what I know works. But if you have
> practical
> > experience with this spec, pull request would be more than welcome.
> >
> > Best,
> > Milen
> >
> >
> >
> >
> > 14 cze 2017 18:59 "Scott Lewis" <sl...@composent.com> napisał(a):
> >
> > On 6/14/2017 4:46 AM, Milen Dyankov wrote:
> >
> > 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
> >>
> >> FWIW: I think your example would be improved by using OSGi remote
> > services specs for the remote service metadata (e.g. provide/require
> > capability, standardized remote service properties, etc) rather than the
> > jax-rs connector specifically. It would also then allow for supporting
> > osgi remote service dynamics, service versioning, rs discovery, etc.
> >
> > Scott
> >
> >
>
--
--
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>
Re: OSGi related PoC and Karaf
Posted by Milen Dyankov <mi...@gmail.com>.
Hmm ok I'm confused. I was thinking about the JAX-RS Services whiteboard
spec that is now being implemented in Apache Aries. I'm aware of the the
remote services spec but not sure how it relates to jax-rs connector .
15 cze 2017 20:11 "Scott Lewis" <sl...@composent.com> napisał(a):
On 6/15/2017 1:24 AM, Milen Dyankov wrote:
> Thanks Scott,
>
> I was looking into that some time ago but AFAIK it comes in R7. Not sure if
> thete is anything released at this point that would work with R6.
>
Were you saying 'there'? The OSGi remote services and RSA specs have been
quite stable since R5 (chap 100 and 122 in compendium).
The Jax-RS distribution provider impls that I'm aware of are ECF's [1].
It supports Jersey's or CXF's Jax-RS impls.
I will attempt to work on a reworking of your POC remote service metadata
for a pull request, after the upcoming ECF release (June 28 I think).
Scott
[1] https://github.com/ECF/JaxRSProviders
So for
> now I just decided to go with what I know works. But if you have practical
> experience with this spec, pull request would be more than welcome.
>
> Best,
> Milen
>
>
>
>
> 14 cze 2017 18:59 "Scott Lewis" <sl...@composent.com> napisał(a):
>
> On 6/14/2017 4:46 AM, Milen Dyankov wrote:
>
> 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
>>
>> FWIW: I think your example would be improved by using OSGi remote
> services specs for the remote service metadata (e.g. provide/require
> capability, standardized remote service properties, etc) rather than the
> jax-rs connector specifically. It would also then allow for supporting
> osgi remote service dynamics, service versioning, rs discovery, etc.
>
> Scott
>
>
Re: OSGi related PoC and Karaf
Posted by Scott Lewis <sl...@composent.com>.
On 6/15/2017 1:24 AM, Milen Dyankov wrote:
> Thanks Scott,
>
> I was looking into that some time ago but AFAIK it comes in R7. Not sure if
> thete is anything released at this point that would work with R6.
Were you saying 'there'? The OSGi remote services and RSA specs have
been quite stable since R5 (chap 100 and 122 in compendium).
The Jax-RS distribution provider impls that I'm aware of are ECF's
[1]. It supports Jersey's or CXF's Jax-RS impls.
I will attempt to work on a reworking of your POC remote service
metadata for a pull request, after the upcoming ECF release (June 28 I
think).
Scott
[1] https://github.com/ECF/JaxRSProviders
> So for
> now I just decided to go with what I know works. But if you have practical
> experience with this spec, pull request would be more than welcome.
>
> Best,
> Milen
>
>
>
>
> 14 cze 2017 18:59 "Scott Lewis" <sl...@composent.com> napisał(a):
>
> On 6/14/2017 4:46 AM, Milen Dyankov wrote:
>
>> 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
>>
> FWIW: I think your example would be improved by using OSGi remote
> services specs for the remote service metadata (e.g. provide/require
> capability, standardized remote service properties, etc) rather than the
> jax-rs connector specifically. It would also then allow for supporting
> osgi remote service dynamics, service versioning, rs discovery, etc.
>
> Scott
>
Re: OSGi related PoC and Karaf
Posted by Milen Dyankov <mi...@gmail.com>.
Thanks Scott,
I was looking into that some time ago but AFAIK it comes in R7. Not sure if
thete is anything released at this point that would work with R6. So for
now I just decided to go with what I know works. But if you have practical
experience with this spec, pull request would be more than welcome.
Best,
Milen
14 cze 2017 18:59 "Scott Lewis" <sl...@composent.com> napisał(a):
On 6/14/2017 4:46 AM, Milen Dyankov wrote:
> 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
>
FWIW: I think your example would be improved by using OSGi remote
services specs for the remote service metadata (e.g. provide/require
capability, standardized remote service properties, etc) rather than the
jax-rs connector specifically. It would also then allow for supporting
osgi remote service dynamics, service versioning, rs discovery, etc.
Scott
Re: OSGi related PoC and Karaf
Posted by Scott Lewis <sl...@composent.com>.
On 6/14/2017 4:46 AM, Milen Dyankov wrote:
> 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
FWIW: I think your example would be improved by using OSGi remote
services specs for the remote service metadata (e.g. provide/require
capability, standardized remote service properties, etc) rather than the
jax-rs connector specifically. It would also then allow for supporting
osgi remote service dynamics, service versioning, rs discovery, etc.
Scott
Re: OSGi related PoC and Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I agree with Christian. Karaf Boot doesn't aim to be as simple as Spring Boot,
it just tries to facilitate the first steps with OSGi/Karaf.
Regards
JB
On 06/14/2017 10:19 PM, Christian Schneider wrote:
> 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 <mi...@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 <mi...@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
>>
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: OSGi related PoC and Karaf
Posted by Christian Schneider <ch...@die-schneider.net>.
2017-06-15 10:38 GMT+02:00 Milen Dyankov <mi...@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" <ch...@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 <mi...@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 <mi...@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>
Re: OSGi related PoC and Karaf
Posted by Milen Dyankov <mi...@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.
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" <ch...@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 <mi...@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 <mi...@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>
>
Re: OSGi related PoC and Karaf
Posted by Christian Schneider <ch...@die-schneider.net>.
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 <mi...@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 <mi...@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=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>
Re: OSGi related PoC and Karaf
Posted by Milen Dyankov <mi...@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 <mi...@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
Re: OSGi related PoC and Karaf
Posted by Christian Schneider <ch...@die-schneider.net>.
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 <mi...@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>