[GitHub] karaf pull request #318: A fix to KARAF-5104 karaf:run should support a feat...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/karaf/pull/318


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: OSGi related PoC and Karaf

[Jean-Baptiste Onofré]

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 :


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 :


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
 (and the slides

from the relevant talk) would help you understand the intention.

 From code perspective it's jus

Re: OSGi related PoC and Karaf

[Christian Schneider]

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 :

> 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 :
> >
> > > 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
> > >  (and the slides
> > >  > > contracts-and-where-to-define-them>
> > > from the relevan

Re: OSGi related PoC and Karaf

[Milen Dyankov]

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 :
>
> > 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
> >  (and the slides
> >  > 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
> > ) that
> > the resolver can use
> >  - perhaps EM can generate a feature based on the resolver results
> >
> > Those are ju

Re: OSGi related PoC and Karaf

[Christian Schneider]

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 :

> 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
>  (and the slides
>  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
> ) 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


Open Source Architect
http://www.talend.com

Re: OSGi related PoC and Karaf

[Scott Lewis]

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

[Milen Dyankov]

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é 
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
>>  (and the slides
>> > 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
>> ) 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é
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
http://about.me/milen

Re: OSGi related PoC and Karaf

[Jean-Baptiste Onofré]

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
 (and the slides

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
) 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é
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

OSGi related PoC and Karaf

[Milen Dyankov]

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
 (and the slides

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