Embedded Cave?

[Milen Dyankov]

Hi,

I have this usecase that I need something to which I can throw a bunch of
bundles and then say "give me ALL bundles that fulfill this requirement". I
need that thing embedded in my code but able to persist and update the
information (index) between executions.

I was thinking of embedding Cave (or parts of it). Can Cave give me ALL
bundles that meet a requirement? If so, is it possible to embed Cave? Is
yes, is that a good idea? One way or another, is there anything else
(apache-felix-osgi-bundle-repository ?) that better fits the usecase?

Best,
Milen

Re: Import-Export property files between modules

[Milen Dyankov]

Do you want this to happen at runtime or build time? Can you be more
specific about what exactly the terms "export" and "import" mean in your
particular case?

On Tue, Jul 25, 2017 at 11:32 AM, Dominik Marciniszyn <
marciniszyn.domi...@gmail.com> wrote:

> Hi,
>
> I have a few modules and each of them have its own property file in
> src/main/resources. I would like to export these files from each bundle and
> import them in one module. The module should create one file from this
> files. (Each file has the same name). Can I do it by ,
>  in maven-bundle-plugin? I have problem with import these
> files into one bundle.
>
> Thanks for any help or advice,
> Dominik Marciniszyn
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Import-Export-property-files-between-modules-tp4051092.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>



-- 
http://about.me/milen

Re: OSGi related PoC and Karaf

[Milen Dyankov]

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" <sle...@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" <sle...@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

[Milen Dyankov]

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

Re: OSGi related PoC and Karaf

[Milen Dyankov]

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" <sle...@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

[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 <milendyan...@gmail.com>:
>
> > Hi Karaf developers,
> >
> > I'd like to ask you to have a look at something I've been working on.
> It's
> > a PoC called Eccentric Modularity (EM) and it's available here
> > https://github.com/azzazzel/EM
> >
> > The basic idea is to provide a jump start into modularity (particularly
> in
> > the scope of resolving dependencies and assembling applications from
> > modules) for people not familiar with OSGi. In fact it tries to hide OSGi
> > from the developer as much as possible. There is not much documentation
> but
> > hopefully the demo projects
> > <https://github.com/azzazzel/EM/tree/master/demo> (and the slides
> > <https://www.slideshare.net/MilenDyankov1/fantastic-java-
> > contracts-and-where-to-define-them>
> > from the relevant talk) would help you understand the intention.
> >
> > From code perspective it's just a (somewhat ugly) hack dynamically adding
> > bnd maven plugins to a Maven project based on properties. So please
> ignore
> > the actual implementation (it's just a PoC) and focus on the
> idea/concept.
> >
> >
> > Why I am sending this to karaf's dev mailing list? To see if Karaf and EM
> > can help each other in any way.  For example
> >  - adding Karaf as target runtime (next to liferay ) should be very
> easy
> >  - perhaps EM can extended to also generate executable jar (spring-

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



-- 
http://about.me/milen

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

Re: Karaf starting slow on new mac

[Milen Dyankov]

See https://thoeni.io/post/macos-sierra-java/

On Wed, Apr 19, 2017 at 9:01 PM, Achim Nierbeck 
wrote:

> Hi,
>
> first you should post your question on the users list, issues is actually
> for the issue tracker :)
> second, I'm using macOS Sierra, and everything is running fine so I can not
> reproduce this.
>
> regards, Achim
>
> 2017-04-19 20:35 GMT+02:00 Aaron Jones :
>
> > I have tried using several different versions including 3.0.3 and 4.1.1.
> > My operating system is macOS Sierra Version 10.12.4 and I am using the
> Java
> > JVM 1.8. I do not have a stack trace because nothing is technically
> erring
> > out but just running extremely slow. I first noticed a problem when
> > integration tests weren’t passing on my new laptop but the exact same
> code
> > was passing on a coworkers laptop. He is running an older version macOS.
> We
> > think it has something to do with macOS Sierra because we had another
> > developer test on his box and got the same behavior I was getting. It
> seems
> > like it is taking longer than normal on the RMI steps of the startup
> > process. Even when downloading a clean version of Kara and starting it,
> the
> > process takes 15+ secs on a new Mac and less than 3 secs on the older
> > version of macOS. The is nothing that I can find of people having the
> same
> > problem so this was the only other place I thought to come. Thank you for
> > any help in advance.
> > --
> > This e-mail, any and all files transmitted with it, and all corresponding
> > e-mail messages are confidential and intended solely for the use of the
> > individual or entity to whom they are addressed. If you have received
> this
> > email in error, please notify the sender immediately by return e-mail. If
> > you are not the named addressee, you should not disseminate, distribute
> or
> > copy this e-mail. Disclosing, copying, distributing or taking any action
> in
> > reliance on the contents of this information is strictly prohibited.
> >
>
>
>
> --
>
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
>
> Software Architect / Project Manager / Scrum Master
>



-- 
http://about.me/milen

Cave

[Milen Dyankov]

Hi folks,

what is the plan for Karaf Cave? Don see it in the Releases schedule JB
sent some time ago. Quick look at Github shows last commit was 9 moths ago?
Do you plan to release 4.1 compatible version?

Or let me ask differently, Is it good idea to build something on top of it?
Or should I simply use parts of the code and build my own thing?

Best,
Milen

-- 
http://about.me/milen

Re: [DISCUSS] & in feature (KARAF-4829)

[Milen Dyankov]

>
> regarding features, yeah why not. It could be a real improvement to have a
> spec for this and it being a ref-implementation.

But wasn't there some sort of spec for a similar thing? AFAIK there had
> been some talks about this


Perhaps you mean subsystems? If so, than I see that more of a kar
alternative. I think features are great thing to be a spec. You can then
make kar or subsystem or whatever you want




On Fri, Dec 9, 2016 at 11:30 AM, Achim Nierbeck <bcanh...@googlemail.com>
wrote:

> The re-naming is ok for me, only the embedded config I don't think to be
> suited well with Karaf.
>
> regarding features, yeah why not. It could be a real improvement to have a
> spec for this and it being a ref-implementation.
> But wasn't there some sort of spec for a similar thing? AFAIK there had
> been some talks about this
> in the past.
>
> regards, Achim
>
> 2016-12-09 11:20 GMT+01:00 Milen Dyankov <milendyan...@gmail.com>:
>
> > I support Christian's idea regarding  > url="mvn:..."/> and 
> > I'm not so sure about the configurator - I find it a bit confusing on
> first
> > read but I haven't paid too much attention to it.
> >
> > However I like the direction. In fact I was about to ask in this list if
> > making "features" an independent (from Karaf) OSGi project is something
> you
> > would consider. I recently installed it into Liferay and why playing with
> > it I realize it makes some assumptions about Karaf specific structure but
> > those are rather easy to fix. I for one would love to have this as
> > independent project and I believe this way more people would be
> interested
> > in it and perhaps contribute to it.
> >
> > Best,
> > Milen
> >
> > On Fri, Dec 9, 2016 at 11:05 AM, Guillaume Nodet <gno...@apache.org>
> > wrote:
> >
> > > Here's the RFC:
> > >
> > > https://github.com/osgi/design/blob/master/rfcs/
> > > rfc0218/rfc-0218-Configurator.pdf
> > > and the impl
> > >   https://github.com/apache/felix/tree/trunk/configurator
> > >
> > > I'm reading it.
> > >
> > > 2016-12-09 10:45 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
> > >
> > > > Hi Christian,
> > > >
> > > > I like your idea ! However, definitely, it means it's for Karaf 4.1.x
> > at
> > > > least (not 4.0.x) as it's kind of breaking change.
> > > >
> > > > For the enroute configurer, does it mean that the config file is part
> > of
> > > > the bundle ? How the user is changing/updating the configuration ?
> > > > Can you point where does it live at Felix (I didn't see it) ?
> > > > Thanks !
> > > >
> > > > Regards
> > > > JB
> > > >
> > > >
> > > > On 12/09/2016 10:25 AM, Christian Schneider wrote:
> > > >
> > > >> I would ike to make a different proposal.
> > > >>
> > > >> We could add a url to config. So people could use this:
> > > >> 
> > > >>
> > > >> In this case the config would be deployed to the etc dir and config
> > > >> admin would be updated immediately.
> > > >>
> > > >>  would then be used exclusively to deploy files that are
> > not
> > > >> related to config admin. I think we could then even rename the
> element
> > > >> to  so the purpose is more clear. We could do this whenever we
> > > >> need a new feature xsd.
> > > >>
> > > >> Apart from this I really like the approach of the enroute configurer
> > > >> which seems to be a spec now with impl at felix. There default
> configs
> > > >> are deployed inside bundles in a special directory. I think this
> > > >> approach is even better than refering to config files in the
> feature.
> > > >> 1. It is easier to do in the build as you just put the config into
> > > >> src/main/resources. No need to change the pom.
> > > >> 2. The approach also works outside karaf as it does not rely on the
> > > >> karaf features. We could even enhance this by optionally copying the
> > > >> config files into etc to achieve the current karaf behaviour.
> > > >>
> > > >> So in the long run I could imagine to rely on configurer for config
> > > >> admin configs and only use an element  to deploy arbitrary
> > files.
> > > >>
> > > >> Christian//

Re: [DISCUSS] & in feature (KARAF-4829)

[Milen Dyankov]

I support Christian's idea regarding  and 
I'm not so sure about the configurator - I find it a bit confusing on first
read but I haven't paid too much attention to it.

However I like the direction. In fact I was about to ask in this list if
making "features" an independent (from Karaf) OSGi project is something you
would consider. I recently installed it into Liferay and why playing with
it I realize it makes some assumptions about Karaf specific structure but
those are rather easy to fix. I for one would love to have this as
independent project and I believe this way more people would be interested
in it and perhaps contribute to it.

Best,
Milen

On Fri, Dec 9, 2016 at 11:05 AM, Guillaume Nodet  wrote:

> Here's the RFC:
>
> https://github.com/osgi/design/blob/master/rfcs/
> rfc0218/rfc-0218-Configurator.pdf
> and the impl
>   https://github.com/apache/felix/tree/trunk/configurator
>
> I'm reading it.
>
> 2016-12-09 10:45 GMT+01:00 Jean-Baptiste Onofré :
>
> > Hi Christian,
> >
> > I like your idea ! However, definitely, it means it's for Karaf 4.1.x at
> > least (not 4.0.x) as it's kind of breaking change.
> >
> > For the enroute configurer, does it mean that the config file is part of
> > the bundle ? How the user is changing/updating the configuration ?
> > Can you point where does it live at Felix (I didn't see it) ?
> > Thanks !
> >
> > Regards
> > JB
> >
> >
> > On 12/09/2016 10:25 AM, Christian Schneider wrote:
> >
> >> I would ike to make a different proposal.
> >>
> >> We could add a url to config. So people could use this:
> >> 
> >>
> >> In this case the config would be deployed to the etc dir and config
> >> admin would be updated immediately.
> >>
> >>  would then be used exclusively to deploy files that are not
> >> related to config admin. I think we could then even rename the element
> >> to  so the purpose is more clear. We could do this whenever we
> >> need a new feature xsd.
> >>
> >> Apart from this I really like the approach of the enroute configurer
> >> which seems to be a spec now with impl at felix. There default configs
> >> are deployed inside bundles in a special directory. I think this
> >> approach is even better than refering to config files in the feature.
> >> 1. It is easier to do in the build as you just put the config into
> >> src/main/resources. No need to change the pom.
> >> 2. The approach also works outside karaf as it does not rely on the
> >> karaf features. We could even enhance this by optionally copying the
> >> config files into etc to achieve the current karaf behaviour.
> >>
> >> So in the long run I could imagine to rely on configurer for config
> >> admin configs and only use an element  to deploy arbitrary files.
> >>
> >> Christian//
> >>
> >> On 08.12.2016 15:42, Jean-Baptiste Onofré wrote:
> >>
> >>> It means that we have to check on the final name (not the URL). And on
> >>> the final name we have to check the target subfolder (cfg goes in etc
> >>> but we can put something in bar folder using configfile for instance)
> >>> and the extension of the final name (.cfg).
> >>>
> >>> Regards
> >>> JB⁣​
> >>>
> >>> On Dec 8, 2016, 15:35, at 15:35, Guillaume Nodet 
> >>> wrote:
> >>>
>  Instead of trying to guess the format of the config file, we could
>  simpy
>  use the extension I think.
>  The  element has both the file name and the url.  So if
> the
>  file name ends with ".cfg", we assume we can write the content to
>  configadmin directly.  I'm not sure I see a real problem here.
> 
>  2016-12-08 15:28 GMT+01:00 Guillaume Nodet :
> 
> 
> > 2016-12-08 15:27 GMT+01:00 Jean-Baptiste Onofré :
> >
> > Yes, Achim already replied and I fully agree.
> >>
> >> So, I wonder if it makes sense to do ConfigAdmin configuration
> >>
> > creation
> 
> > for  as it would require to detect file format.
> >>
> >> Can we document that way:
> >> 1. for cfg file, we recommend to use  in feature XML
> >> 2. for any other file format, we recommend to use  in
> >> feature XML
> >> ?
> >>
> >> That sounds to me the exact reason why we create those two elements
> >
>  in the
> 
> > first place. ;-)
> >
> >
> > Regards
> >> JB
> >>
> >>
> >> On 12/08/2016 03:24 PM, Guillaume Nodet wrote:
> >>
> >> The  element supports  any kind of configuration file,
> >>>
> >> not
> 
> > only
> >>> properties file.  For example we use it for the xml configuration
> >>>
> >> of
> 
> > jetty
> >>> in pax-web.
> >>>
> >>> 2016-12-08 15:08 GMT+01:00 Jean-Baptiste Onofré :
> >>>
> >>> Hi guys,
> >>>
>  Some weeks ago we discussed on the mailing list about the fact
> 
> >>> that a
> 
> > feature using  just creates the cfg file in the 

Re: [DISCUSS] Trim down the number of config files in etc/ in the distributions

[Milen Dyankov]

>
> I was able to modify above files, because I saw them being present.


That was exactly my point regarding documentation. I'd imagine a lot of
people would not be even aware something is configurable and can waste time
digging or what's worse, reinvent the wheel. For someone who is been
playing with Karaf (or OSGi in general) for a while - configuration is
fairly familiar and straightforward concept. But for people just starting
their journey it may be hard to figure out.

Best,
Milen

On Fri, Nov 25, 2016 at 12:50 PM, Fabian Lange 
wrote:

> Hi Guillaume,
>
> We are building a distribution, and we modify these files:
>
> -rw-r--r--   1 fabian  staff 0 Sep  6 16:13 blacklisted.properties
> -rw-r--r--   1 fabian  staff   977 Dec 11  2015 branding.properties
> -rw-r--r--   1 fabian  staff  2414 Oct 28 17:35 custom.properties
> -rw-r--r--   1 fabian  staff  2867 Nov 11 14:10
> org.apache.karaf.features.cfg
> -rw-r--r--@  1 fabian  staff  1935 Dec 21  2015 org.apache.karaf.log.cfg
> -rw-r--r--   1 fabian  staff  3317 Dec 11  2015 org.apache.karaf.shell.cfg
> -rw-r--r--   1 fabian  staff  2818 Nov 21 08:08 org.ops4j.pax.logging.cfg
> -rw-r--r--@  1 fabian  staff  3889 Oct  6 09:07 org.ops4j.pax.url.mvn.cfg
> -rw-r--r--   1 fabian  staff 0 Sep  6 16:13 overrides.properties
> -rw-r--r--@  1 fabian  staff  5430 Oct  5 10:02 system.properties
> -rw-r--r--   1 fabian  staff  1701 Apr  2  2016 users.properties
>
> the 0 byte properties are just to avoid the file not found exception
>
> And we have the following excludes
>
>   
> bin/**
> deploy/README
> system/README
> lib/**/README
> etc/org.apache.karaf.jaas.cfg
> etc/org.apache.karaf.management.cfg
> etc/org.apache.karaf.features.repos.cfg
> etc/org.apache.karaf.command.acl*
> etc/jmx.acl*
>   
>
>
> I am very much in favor of removing the files. The only issue i see is that
> I was able to modify above files, because I saw them being present.
>
> Fabian
> --
> Fabian Lange | Performance Expert
> mobil: +49 (0) 160.3673393
>
> codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland
>
> Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
> Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
> Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz
>
> On Fri, Nov 25, 2016 at 8:19 AM, Guillaume Nodet 
> wrote:
>
> > I'd like to trim down a bit the number of files in the etc/ directory.
> > The distribution contains a bunch of config files for the ACLs, but I'm
> not
> > sure people usually modify those.  I think this may be the same for
> various
> > configuration.
> > What I'm proposing is the following:
> >   * make sure all those configurations are moved into their respective
> > feature
> >   * remove them from the assemblies/base maven module which is embedded
> by
> > the framework and static kars
> >   * add a flag on the AssemblyMojo so that we can choose using glob
> > patterns which config pids should be extracted as files at build time
> >   * the other ones are extracted automatically by the FeaturesService
> > anyway during boot features installation
> >
> > The idea would be that distributions only contains configurations that
> are
> > actually used.
> >
> > Also, I'm going to removing some additional files from the static
> framework
> > (bin/contrib/, bin/instance(.sh|.bat), deploy/).
> >
> > Thoughts ?
> > Guillaume
> >
> >
> > --
> > 
> > Guillaume Nodet
> > 
> > Red Hat, Open Source Integration
> >
> > Email: gno...@redhat.com
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
> >
>



-- 
http://about.me/milen

Re: [DISCUSS] Trim down the number of config files in etc/ in the distributions

[Milen Dyankov]

I like the idea of reducing the number of files in etc folder.
However I would vote against it until there is a good documentation of how
to configure everything that's in those removed files. That is what can be
configured, where, how it differs in clustered env, ...
Once that is place that is easy to find and use I'd love to get rid of
those.

Side note: I don't know how configuration from features works but we need
to be careful with location bindings. We at Liferay used to have some
issues with bundles providing own default configuration which was not
possible to change later on because of location bindings. I'm not saying
this will be a problem with Karaf, but just to keep an eye on it while
changing things.

Best,
Milen

On Fri, Nov 25, 2016 at 8:19 AM, Guillaume Nodet  wrote:

> I'd like to trim down a bit the number of files in the etc/ directory.
> The distribution contains a bunch of config files for the ACLs, but I'm not
> sure people usually modify those.  I think this may be the same for various
> configuration.
> What I'm proposing is the following:
>   * make sure all those configurations are moved into their respective
> feature
>   * remove them from the assemblies/base maven module which is embedded by
> the framework and static kars
>   * add a flag on the AssemblyMojo so that we can choose using glob
> patterns which config pids should be extracted as files at build time
>   * the other ones are extracted automatically by the FeaturesService
> anyway during boot features installation
>
> The idea would be that distributions only contains configurations that are
> actually used.
>
> Also, I'm going to removing some additional files from the static framework
> (bin/contrib/, bin/instance(.sh|.bat), deploy/).
>
> Thoughts ?
> Guillaume
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>



-- 
http://about.me/milen

Re: [DISCUSS] Feature package, feature generation and validation

[Milen Dyankov]

I have 2 things to say to that
- I agree with all the pain points you've identified (experienced them
myself)
- I'd prefer to fix things instead of claim them useless due to
malfunctioning

Perhaps a middle ground would be a good starting point? Something like how
bndrun resolution works. I mean:
 - developer says - this is what I care to run (perhaps a prototype feature
or something ...)
 - feature-generate-descriptor takes it from there and fills in the gaps
 - developer can change/fix things by tweaking the prototype if not happy
with what feature-generate-descriptor did

This is just my first thought and I'm pretty sure reality is not that
simple. Just wanted to vote against removing it and suggest to start
looking for better solution instead.

Best,
Milen

On Thu, Oct 13, 2016 at 11:07 AM, Guillaume Nodet  wrote:

> The feature packaging is a nice thing, as it allows automatic attachment of
> the feature file.
> However, it always use the feature-generate-descriptor, which produces a
> lot of weird results.
> Afaik, the feature packaging is not much used and all projects i've seen,
> such as pax projects, camel, cxf, and even karaf itself (including
> decanter, cellar, karaf container...).
>
> I think part of the problem comes from the feature descriptor generation,
> which is difficult to control.  I have always found much easier to simply
> write the feature manually.
> Although the generation process rewrites the xml entirely, so that any xml
> comments or license header is lost.
>
> Overall, I'm not sure that it makes our users life really easier.
>
> So I'd like to propose to get rid of the feature-generate-descriptor from
> inside the feature packaging and replace it with the verify goal to
> validate the hand-written features instead.
>
> Thoughts ?
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>



-- 
http://about.me/milen

Karaf boot status

[Milen Dyankov]

Hi guys,

what is the current status of Karaf boot?
Is it something that average developer can play with? Any usage samples?
Any docs / notes?

I looked at https://github.com/jbonofre/karaf-boot but this looks very
simple and it does not give a starting point if I want to build something
on my own and not just compile and run the samples.


Regards,
Milen

Re: Discuss: Use DS for karaf bundles

[Milen Dyankov]

+1
17 mar 2016 16:44 "Christian Schneider" 
napisał(a):

> We currently use some custom Activator base classes to wire the karaf
> bundles. The goal of this was to avoid depending on blueprint
> as it is a quite heavy dependency and makes it harder to use a different
> blueprint impl or version.
>
> There are some problems with this approach though:
> - It makes it harder for new people to understand what we are doing
> - The custom code is more error prone than a proven framework
>
> So I propose to switch our own bundles to use DS to expose and wire
> services.
>
> There are some advantages:
> - The DS annotation approach is easier to understand and more self
> documenting than the custom code
> - We get rid of the classes in util for the custom code
> - The scr commands help diagnose problems
>
> The main cost is that we need to always install the felix scr bundle.
>
> To prove that it can work I switched bundle core in a branch
> https://github.com/apache/karaf/tree/EXPERIMENTAL_DS .
> The DS based code works quite nicely.
>
> Btw. I found a small problem with our shell command extender. It only
> seems to work on all commands or none. If there is any required service
> missing then none of the commands is installed.
> This made it hard for me to diagnose problems as I was missing all bundle
> commands ;-)
> So while working on the switch I thought about two improvements to the
> extender:
> 1. Work on each command individually. So each command can activate as soon
> as the deps are met
> 2. Provide a service and commands to diagnose problems like the scr
> commands
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Re: Discuss: Use DS for karaf bundles

[Milen Dyankov]

Oh, got it now. Thanks for clearing this up. Btw, how do I get the minimal
distribution?

On Fri, Mar 18, 2016 at 7:33 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> The shell core headers don't import blueprint, and the shell feature
> doesn't depend to the blueprint feature.
>
> What you see comes from the shell-compat feature which brings the "old"
> blueprint command extender (you are right, for backward compatibility, this
> feature is installed by default in the Karaf standard distribution).
>
> What I meant is that if you remove the aries-blueprint and shell-compat
> features, Karaf is still running without these dependencies.
>
> Regards
> JB
>
>
> On 03/18/2016 07:24 PM, Milen Dyankov wrote:
>
>> This is what I mean:
>>
>> karaf@root()> bundle:info 44
>>
>> Apache Karaf :: Shell :: Core (44)
>>
>> ...
>>
>>
>> karaf@root()> bundle:requirements 44 | grep blueprint
>> osgi.wiring.package;
>>
>> (&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0)))
>> resolved by:
>> osgi.wiring.package; org.apache.aries.blueprint 1.5.0 from
>> org.apache.aries.blueprint.core [13]
>> osgi.wiring.package;
>>
>> (&(osgi.wiring.package=org.apache.aries.blueprint.mutable)(version>=1.2.0)(!(version>=2.0.0)))
>> resolved by:
>> osgi.wiring.package; org.apache.aries.blueprint.mutable 1.2.0 from
>> org.apache.aries.blueprint.core [13]
>> osgi.wiring.package;
>>
>> (&(osgi.wiring.package=org.osgi.service.blueprint)(version>=1.0.0)(!(version>=2.0.0)))
>> resolved by:
>> osgi.wiring.package; org.osgi.service.blueprint 1.0.0 from
>> org.apache.aries.blueprint.core [13]
>> osgi.wiring.package;
>>
>> (&(osgi.wiring.package=org.osgi.service.blueprint.container)(version>=1.0.0)(!(version>=2.0.0)))
>> resolved by:
>> osgi.wiring.package; org.osgi.service.blueprint.container 1.0.1 from
>> org.apache.aries.blueprint.api [11]
>> osgi.wiring.package;
>>
>> (&(osgi.wiring.package=org.osgi.service.blueprint.reflect)(version>=1.0.0)(!(version>=2.0.0)))
>> resolved by:
>> osgi.wiring.package; org.osgi.service.blueprint.reflect 1.0.1 from
>> org.apache.aries.blueprint.api [11]
>>
>>
>>
>> On Fri, Mar 18, 2016 at 7:20 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
>> wrote:
>>
>> Hi Milen,
>>>
>>> Karaf Shell Core (if you mean this bundle) doesn't depend on blueprint
>>> (blueprint is not defined as a  and so not in the manifest,
>>> even for the command extender).
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 03/18/2016 07:14 PM, Milen Dyankov wrote:
>>>
>>> I personally think DS is pretty much what OSGi Alliance is going to
>>>> promote
>>>> (together with the enRoute project) and from that perspective if any
>>>> component framework's user base is going to grow that would be DS. But
>>>> if
>>>> you guys want to still do it the "hard way" that's fine too. It just
>>>> means
>>>> less people will be able to contribute.
>>>>
>>>> As for things that can not be done with DS, I don't think Christian
>>>> meant
>>>> to say everything must be rewritten! If something needs to be done
>>>> differently (activators/tackers/...) than it can/should be. It's not all
>>>> or
>>>> nothing scenario IMHO.
>>>>
>>>> Finally about Blueprint. I keep reading in posts that Karaf got rid of
>>>> Blueprint. Meanwhile in 4.0.4 the "Apache Karaf :: Shell :: Core" still
>>>> depends on Blueprint. So when you say "the bundles in Karaf are
>>>> independent"
>>>> what exactly do you mean?
>>>>
>>>> Best,
>>>> Milen
>>>>
>>>>
>>>>
>>>> On Fri, Mar 18, 2016 at 1:38 PM, Guillaume Nodet <gno...@apache.org>
>>>> wrote:
>>>>
>>>> I agree with Achim and Lukasz.
>>>>
>>>>>
>>>>> Here are the advantages of the current solution:
>>>>>
>>>>> 1/ No additional dependency.  One thing that I really care about is
>>>>> that
>>>>> the bundles in Karaf are independent.  I.e. they do not rely on an
>>>>> extender.   The benefit is that you can upgrade the bundles
>>>>> independently
>>>>> and you do

Re: Discuss: Use DS for karaf bundles

[Milen Dyankov]

This is what I mean:

karaf@root()> bundle:info 44

Apache Karaf :: Shell :: Core (44)

...


karaf@root()> bundle:requirements 44 | grep blueprint
osgi.wiring.package;
(&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0)))
resolved by:
   osgi.wiring.package; org.apache.aries.blueprint 1.5.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;
(&(osgi.wiring.package=org.apache.aries.blueprint.mutable)(version>=1.2.0)(!(version>=2.0.0)))
resolved by:
   osgi.wiring.package; org.apache.aries.blueprint.mutable 1.2.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.blueprint)(version>=1.0.0)(!(version>=2.0.0)))
resolved by:
   osgi.wiring.package; org.osgi.service.blueprint 1.0.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.blueprint.container)(version>=1.0.0)(!(version>=2.0.0)))
resolved by:
   osgi.wiring.package; org.osgi.service.blueprint.container 1.0.1 from
org.apache.aries.blueprint.api [11]
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.blueprint.reflect)(version>=1.0.0)(!(version>=2.0.0)))
resolved by:
   osgi.wiring.package; org.osgi.service.blueprint.reflect 1.0.1 from
org.apache.aries.blueprint.api [11]



On Fri, Mar 18, 2016 at 7:20 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> Hi Milen,
>
> Karaf Shell Core (if you mean this bundle) doesn't depend on blueprint
> (blueprint is not defined as a  and so not in the manifest,
> even for the command extender).
>
> Regards
> JB
>
>
> On 03/18/2016 07:14 PM, Milen Dyankov wrote:
>
>> I personally think DS is pretty much what OSGi Alliance is going to
>> promote
>> (together with the enRoute project) and from that perspective if any
>> component framework's user base is going to grow that would be DS. But if
>> you guys want to still do it the "hard way" that's fine too. It just means
>> less people will be able to contribute.
>>
>> As for things that can not be done with DS, I don't think Christian meant
>> to say everything must be rewritten! If something needs to be done
>> differently (activators/tackers/...) than it can/should be. It's not all
>> or
>> nothing scenario IMHO.
>>
>> Finally about Blueprint. I keep reading in posts that Karaf got rid of
>> Blueprint. Meanwhile in 4.0.4 the "Apache Karaf :: Shell :: Core" still
>> depends on Blueprint. So when you say "the bundles in Karaf are
>> independent"
>> what exactly do you mean?
>>
>> Best,
>> Milen
>>
>>
>>
>> On Fri, Mar 18, 2016 at 1:38 PM, Guillaume Nodet <gno...@apache.org>
>> wrote:
>>
>> I agree with Achim and Lukasz.
>>>
>>> Here are the advantages of the current solution:
>>>
>>> 1/ No additional dependency.  One thing that I really care about is that
>>> the bundles in Karaf are independent.  I.e. they do not rely on an
>>> extender.   The benefit is that you can upgrade the bundles independently
>>> and you don't have an additional bundle which cause all the bundles to be
>>> refreshed / restarted.
>>>
>>> 2/ Very lightweight. The current framework only consist in 3 classes :
>>> BaseActivator, SingleServiceTracker,
>>> SingleServiceTracker$SingleServiceListener.
>>>   Even the annotations are not included at runtime.
>>>
>>> 3/ Very fast. No xml parsing, no reflection.  Just the
>>> OSGI-INF/karaf-tracker/ property file which is loaded by the activator.
>>> So
>>> it's really fast at startup.
>>>
>>> 4/ Very robust. Quite the contrary to what you say, I think this very
>>> small
>>> framework is way more robust than blueprint or DS.  I spent quite some
>>> time
>>> load-testing karaf 4 before the release, using the bundle:load-test
>>> command.
>>>
>>> 5/ DS exclusively uses the OSGi registry for wiring.  There's no notion
>>> of
>>> "internal" wiring, everything is exposed.  So by default, the
>>> capabilities
>>> / requirements contain much more than what is needed, with the additional
>>> semantical change where the bundle could be wired to components coming
>>> from
>>> different bundles (check the bundle manifest in your branch).
>>>
>>> So yes, the main drawback are : limited scope and not documented, but
>>> given
>>> is has never been written to be used outside karaf, I don't see those as
>>> real problems.   If the concern is users, I'm all fo

Re: Discuss: Use DS for karaf bundles

[Milen Dyankov]

I personally think DS is pretty much what OSGi Alliance is going to promote
(together with the enRoute project) and from that perspective if any
component framework's user base is going to grow that would be DS. But if
you guys want to still do it the "hard way" that's fine too. It just means
less people will be able to contribute.

As for things that can not be done with DS, I don't think Christian meant
to say everything must be rewritten! If something needs to be done
differently (activators/tackers/...) than it can/should be. It's not all or
nothing scenario IMHO.

Finally about Blueprint. I keep reading in posts that Karaf got rid of
Blueprint. Meanwhile in 4.0.4 the "Apache Karaf :: Shell :: Core" still
depends on Blueprint. So when you say "the bundles in Karaf are independent"
what exactly do you mean?

Best,
Milen



On Fri, Mar 18, 2016 at 1:38 PM, Guillaume Nodet  wrote:

> I agree with Achim and Lukasz.
>
> Here are the advantages of the current solution:
>
> 1/ No additional dependency.  One thing that I really care about is that
> the bundles in Karaf are independent.  I.e. they do not rely on an
> extender.   The benefit is that you can upgrade the bundles independently
> and you don't have an additional bundle which cause all the bundles to be
> refreshed / restarted.
>
> 2/ Very lightweight. The current framework only consist in 3 classes :
> BaseActivator, SingleServiceTracker,
> SingleServiceTracker$SingleServiceListener.
>  Even the annotations are not included at runtime.
>
> 3/ Very fast. No xml parsing, no reflection.  Just the
> OSGI-INF/karaf-tracker/ property file which is loaded by the activator.  So
> it's really fast at startup.
>
> 4/ Very robust. Quite the contrary to what you say, I think this very small
> framework is way more robust than blueprint or DS.  I spent quite some time
> load-testing karaf 4 before the release, using the bundle:load-test
> command.
>
> 5/ DS exclusively uses the OSGi registry for wiring.  There's no notion of
> "internal" wiring, everything is exposed.  So by default, the capabilities
> / requirements contain much more than what is needed, with the additional
> semantical change where the bundle could be wired to components coming from
> different bundles (check the bundle manifest in your branch).
>
> So yes, the main drawback are : limited scope and not documented, but given
> is has never been written to be used outside karaf, I don't see those as
> real problems.   If the concern is users, I'm all for advertising the use
> of DS or Blueprint for our users, I don't think they should use our
> internal framework which is much more low level.
>
>
> 2016-03-17 16:43 GMT+01:00 Christian Schneider :
>
> > We currently use some custom Activator base classes to wire the karaf
> > bundles. The goal of this was to avoid depending on blueprint
> > as it is a quite heavy dependency and makes it harder to use a different
> > blueprint impl or version.
> >
> > There are some problems with this approach though:
> > - It makes it harder for new people to understand what we are doing
> > - The custom code is more error prone than a proven framework
> >
> > So I propose to switch our own bundles to use DS to expose and wire
> > services.
> >
> > There are some advantages:
> > - The DS annotation approach is easier to understand and more self
> > documenting than the custom code
> > - We get rid of the classes in util for the custom code
> > - The scr commands help diagnose problems
> >
> > The main cost is that we need to always install the felix scr bundle.
> >
> > To prove that it can work I switched bundle core in a branch
> > https://github.com/apache/karaf/tree/EXPERIMENTAL_DS .
> > The DS based code works quite nicely.
> >
> > Btw. I found a small problem with our shell command extender. It only
> > seems to work on all commands or none. If there is any required service
> > missing then none of the commands is installed.
> > This made it hard for me to diagnose problems as I was missing all bundle
> > commands ;-)
> > So while working on the switch I thought about two improvements to the
> > extender:
> > 1. Work on each command individually. So each command can activate as
> soon
> > as the deps are met
> > 2. Provide a service and commands to diagnose problems like the scr
> > commands
> >
> > Christian
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
> >
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>



-- 
http://about.me/milen

Re: bnd files in Decanter Project

[Milen Dyankov]

*358 additions* and *57 deletions*.

I feel your pain :)


On Tue, Feb 16, 2016 at 5:42 PM, Christian Schneider <
ch...@die-schneider.net> wrote:

> According to the discussion and the votes JB summarized we decided to roll
> back my change to use bnd files.
> I removed all bnd files and put the same configs in the poms.
>
> Believe me that I shed a lot of DRY tears when adding 300 lines that do
> absolutely nothing ... but it was a community decision so this is fine with
> me.
>
> https://github.com/apache/karaf-decanter/commit/009aef25d5b61f71648e58637bb8fb83ed7ca0bf
>
> Christian
>
> On 11.02.2016 09:55, Achim Nierbeck wrote:
>
>> Hi,
>>
>> the other day I added another module to the decanter project (cassandra
>> appender).
>> And I've got to say I was quite astonished to see all those bnd files in
>> there, but what
>> really got me stirred. It is mandatory to have those now.
>>
>> I can't remember seeing a vote for such a change in development!
>>
>> So here is my
>>
>> -1
>>
>> on this not communicated and breaking functionality change that sneaked in
>> there.
>>
>> So whoever changed that needs to revoke this, NOW.
>> It hasn't been discussed up-front and actually I just can't stand such
>> sneaky moves.
>>
>> regards, Achim
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>


-- 
http://about.me/milen

Re: bnd files in Decanter Project

[Milen Dyankov]

For me personally IDE support is irrelevant. BND is a command like tool and
while support for it in IDEs is different at the end of the day all you
need is a properties file editor. You don't get code competition for POMs
neither so there is absolutely no difference (in terms of amount of work
needed) where you put your instructions. But on the Pro side I would put

 - standard: bnd.bnd is the standard way to configure BND. I just like to
use the right tool for the job. For example, consider if you were using
some "next generation" build tool that runs Maven under the hood, would you
like to have maven configuration in that other fancy tool's config files or
rather stick with maven poms?
 - learning curve: The BND docs have examples how to configure things in
bnd.bnd file and it's not always immediately obvious how to transfer those
to maven plugin configuration.
 - plugin independent configuration - obviously bnd-maven-plugin comes to
mind first but in general if someone comes with better (in whatever sense)
plugin in the future the configuration does not need to change

For the record (in case you find some public evidence of me arguing the
opposite) some time ago I was totally against using bnd.bnd files. After
being kind of forced to do it for a while, I realized it doesn't really
make any difference in the effort that it takes to maintain those and at
the same time provides clearer separation of concerns. So I changed my mind
:) !

Best,
Milen


On Fri, Feb 12, 2016 at 11:05 AM, Christian Schneider <
ch...@die-schneider.net> wrote:

> From my point of view the arguments for and against the bnd file
> extraction.
>
> Pro:
> - You typically do not need a plugin definition at all in each module pom.
> So the definition just in the bnd file is much more concise.
> - If you use bndtools you get a nice view and editor for the bnd file.
> This is not so important for me though.
>
> Con:
> - If you use intellij then most probably you will have some completion
> support for the configurations in the pom but not for the bnd.bnd file
>
> So I think the extraction is best for users of eclipse and bndtools and
> less valuable for other IDEs. To be honest though editing the bnd files is
> not really a big deal.
> I typically only use Import-Package, Export-Package, Private-Package and
> Bundle-Activator and these four I can type without completion. The maven
> bundle plugin also nicely
> complains if you have any errors in the file. So I think editing with a
> simple text editor is no big deal.
>
> Christan
>
>
> On 12.02.2016 10:54, Markus Rathgeb wrote:
>
>> Hi Christian,
>> thank you for your answer.
>>
>> I want to state, that there are no feelings from my side what is better.
>> I want to collect the technical details for further decisions on the
>> projects I maintain.
>>
>> So, let's assume I do not use the configuration in a parent project
>> (just add maven-bundle-plugin to the used plugins and set
>> extensions=true) and also not use properties, the bnd.bnd file will
>> result in less lines in the pom if I want to change the default
>> configuration of the plugin.
>>
>> Are there other pros?
>>
>> Best regards,
>> Markus
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>


-- 
http://about.me/milen

Re: bnd files in Decanter Project

[Milen Dyankov]

Guys,

Allow me to provide my 2 cents in this discussion.

One - I think we have more than enough arogancie and blame games in the
OSGi community. We really don't need more of those. It would be nice if
everyone could remain calm and watch their language even if they have a
point as far as the facts are concern. Let's not assume bad intentions just
because of frustration with something. People make mistakes and wrong
decisions. And we are all people! Luckily it's only software in this case,
no one gets hurt (physically) and things are easy to fix. Let us be nice to
each other. Please!

Two - for me personally it doesn't make huge difference if the information
is in the POM or in the bnd file. You, the guys working on the project the
most, should decide on that. However here are few things to consider:
 - It is true that using bnd files reduces the size of the POMs which is
particularly important if you have complex multi-module projects
 - Both maven plugins available up to date are using bnd (not to be
confused with bnd-tools) under the hood and bnd.bnd files are the default
way to provide instructions to bnd. Personally I don't understand why
someone decided to have this in POM in first place while creating the
maven-bundle-plugin.
 - The new bnd-maven-plugin (which I see people using more and more often)
requires you to have all the instructions in bnd.bnd file. Moreover it is
able to process bnd.bnd from parent projects which allows you to completely
skip those in child projects if you don't need to.

Don't get me wrong, I'm not suggesting yet another approach. Just pointing
out there are options out there that could be discussed in civilized and
polite way!

Best,
Milen





On Thu, Feb 11, 2016 at 9:43 PM, Achim Nierbeck 
wrote:

> Hi Christian,
>
> I don't think you seem to follow an evil plot, it's just you don't seem to
> think ahead and take yourself to important.
> This discussion about bnd.file or not bnd.file should have been done before
> you provided evidence.
> A discussion on IRC is as you should be aware of not a valid discussion. So
> if it didn't happen on the mailinglist, it didn't happen.
>
> At this point I don't get why you now try to turn your "jumping the gun"
> into me being at fault.
>
> The only change I'm arguing about is the extra bnd.file all other build
> improvements are regular changes, which I'm not arguing about.
> Again for me an extra configuration file isn't of any value compared to the
> configuration contained in the pom.
>
> So this isn't about me insisting you to change everything back, the issue
> here is that you impose what you think is best on everybody else.
>
> Achim
>
>
>
> 2016-02-11 20:19 GMT+01:00 Christian Schneider :
>
> > Hi Achim,
> >
> > thanks for your detailed description. I can assure you that I do not
> > follow any evil plot like you seem to think. I will for sure not use
> gradle
> > any time soon. I am quite happy with maven and am just trying to make our
> > project better and the code more efficient. I also was not really sneaky
> by
> > creating an issue up front and describing what I want to do. I just did
> not
> > to also spawn a discussion on the list to make this more obvious. Please
> be
> > assured that the only reason for this was my inherent impatience and good
> > faith that JB would not have supported my change if he thought it would
> be
> > a bad thing for the karaf community. So I was not really aware of doing
> > something wrong at this time.
> >
> > Please also take into account that your build problem only happened on a
> > new module you wanted to add and could be fixed by just adding the empty
> > bnd.bnd file. So I think a -1 while possible was not really necessary. I
> > think the better option would have been to bring the issue on the list
> and
> > try to reach a consensus. I think in my whole apache history I never did
> a
> > -1 on a commit.
> >
> > Do you insist on me taking back the commit now or would it be ok to first
> > try to reach a consensus or if not possible do a vote? I will happily
> undo
> > my commit if the outcome is to not do the change. On the other hand if we
> > agree to do the change it would save me to shuffle the code back and
> forth.
> >
> > If you insist on this I will undo the changes now. It is probably not
> > possible to just undo the commit as there are quite a few commits in
> > between. So it will be quite some manual work for me.
> > I also hope that if you insist on me taking back the change now you are
> ok
> > if I only undo the bnd file part of the commit and leave other changes
> like
> > moving some common deps into the parent in place.
> >
> > Christian
> >
> >
> >
> > On 11.02.2016 17:06, Achim Nierbeck wrote:
> >
> >> Hi there,
> >>
> >> I'll stick to my
> >>
> >> -1
> >>
> >> Now the reasons for this:
> >>
> >> Even though the opposite has been proclaimed on the list, it did break
> the
> >> build for me. As without a 

Re: [VOTE] Promote the new website look'n feel

[Milen Dyankov]

+1

Looks much better now! Thank you for fixing it!

I only noticed one minor and easy to fix issue - all links to the projects
on home page go to the top of the projects page. Please add "#boot",
"#cellar", ... to them. It's especially important for mobile devices since
now the menu on product page is gone and it's not immediately obvious you
need to scroll down to the actual project.

Best,
Milen


On Thu, Jan 21, 2016 at 2:53 PM, Jean-Baptiste Onofré 
wrote:

> Hi all,
>
> Morgan helped me to fix the mobile rendering issue.
>
> I updated the website proposal on the same URL:
>
> http://maven.nanthrax.net/goodies/karaf/site/
>
> (NB: don't forget to refresh your browser cache with CTRL-SHIFT-R)
>
> I gonna add couple of missing links, but you can consider this mockup as
> the one to vote on.
>
> @Milen: as you voted -1 due to the mobile rendering, can you take a new
> look and see if it's OK for you now ?
>
> For the others, don't hesitate to vote (if it's not already done).
>
> Thanks !
> Regards
> JB
>
>
> On 01/19/2016 10:24 AM, Jean-Baptiste Onofré wrote:
>
>> Hi all,
>>
>> I extending this vote to 72 more hours in order for me to fix the
>> rendering on mobile, and add the release schedule information.
>>
>> Thanks,
>> Regards
>> JB
>>
>> On 01/13/2016 06:58 PM, Jean-Baptiste Onofré wrote:
>>
>>> Hi all,
>>>
>>> As already discussed on the mailing list, I would like to promote the
>>> new website.
>>>
>>> As reminder, the new website proposal is there:
>>>
>>> http://maven.nanthrax.net/goodies/karaf/site/
>>>
>>> Please vote to approve the new website:
>>>
>>> [ ] +1 Approve the new website promotion
>>> [ ] -1 Don't approve the new website (please provide specific comments)
>>>
>>> This vote will be open for at least 72 hours.
>>>
>>> Thanks,
>>> Regards
>>> JB
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
http://about.me/milen

Re: [VOTE] Promote the new website look'n feel

[Milen Dyankov]

I only checked it my Galaxy Note so it would be good if others can report
about other devices.

Both the old and the new site work. In that sense the that all the
information is displayed. The difference is the old one allows to zoom in
and out and scroll. The new one seem to have fixed size. It displays the
menu on the left and small part of the actual content on the right and
there seem to be no way to scroll or zoom.

Best,
Milen
13 sty 2016 21:53 "Jean-Baptiste Onofré" <j...@nanthrax.net> napisał(a):

> By mobile, you mean on a phone right ?
>
> Let me try it and fix that.
>
> By the way, does the current website work fine on mobile ?
>
> Thanks
> Regards
> JB
>
> On 01/13/2016 09:16 PM, Milen Dyankov wrote:
>
>> Hi,
>>
>> I'm not sure if this qualifies for -1 but it seams everything except home
>> page is not mobile device friendly. I really like the home page but the
>> rest is kind of cut in half if you browse it with mobile device. The only
>> fully visible part is the menu. IMHO this needs to be fixed. May be it's
>> just me but as someone who is doing fair amount of travelling I tend to
>> visit web sites on my phone more often then on my laptop.
>>
>> Best,
>> Milen
>> 13 sty 2016 20:57 "Giuseppe Gerla" <giuseppe.ge...@gmail.com> napisał(a):
>>
>> +1 (non binding)
>>>
>>> BR
>>> Giuseppe
>>> Il 13/gen/2016 20:56, "Morgan Hautman" <morgan.haut...@gmail.com> ha
>>> scritto:
>>>
>>> +1 non-binding
>>>>
>>>> On 01/13/2016 06:58 PM, Jean-Baptiste Onofré wrote:
>>>>
>>>> Hi all,
>>>>>
>>>>> As already discussed on the mailing list, I would like to promote the
>>>>>
>>>> new
>>>
>>>> website.
>>>>>
>>>>> As reminder, the new website proposal is there:
>>>>>
>>>>> http://maven.nanthrax.net/goodies/karaf/site/
>>>>>
>>>>> Please vote to approve the new website:
>>>>>
>>>>> [ ] +1 Approve the new website promotion
>>>>> [ ] -1 Don't approve the new website (please provide specific comments)
>>>>>
>>>>> This vote will be open for at least 72 hours.
>>>>>
>>>>> Thanks,
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [PROPOSAL/DISCUSSION] Apache Karaf new website

[Milen Dyankov]

Hi Morgan,
I just tried it on my phone and it seems ... how to say ... less readable
then the current site. Also the navigation does not seem to work at all on
my phone. I'll try to check it out on my laptop soon and provide more
feedback.

Best,
Milen
4 paź 2015 13:18 "Morgan Hautman"  napisał(a):

> Hi JB, Achim,
>
> Thank you both.
> Yes it is indeed by intention.
> If you have better colors or anything , just let me know. I can try-out
> your way and share to see if it looks better.
>
> Regards,
> Morgan
>
> On 10/04/2015 12:40 PM, Achim Nierbeck wrote:
>
>> Hi Morgan,
>>
>> thanks for the input. I like the look and feel,
>> Just one question: Is it by intention that the menu section and the Image
>> section below do have different "shades" of blue?
>>
>> regards, Achim
>>
>>
>> 2015-10-04 12:15 GMT+02:00 Jean-Baptiste Onofré :
>>
>>
>>> Hi Morgan
>>> Interesting job.
>>> For all, please, don't focus on the content, just the look'n feel. I'm
>>> working on the content for both website and documentation.
>>> RegardsJB
>>>
>>>
>>> Sent from my Samsung device
>>>
>>>  Original message 
>>> From: Morgan Hautman 
>>> Date: 04/10/2015  11:57  (GMT+01:00)
>>> To: dev@karaf.apache.org
>>> Subject: [PROPOSAL/DISCUSSION] Apache Karaf new website
>>>
>>> Hello,
>>>
>>> Some of you might be knowing it, some of you might not but I have been
>>> working on a new look for the Karaf website.
>>> I'm not a web developer so I have done my best to craft a new website
>>> proposal.
>>> I have used HTML, CSS and the Bootstrap 3 framework.
>>>
>>> Here is the magic link: http://mhautman.com/karaf-site/
>>>
>>> I have also tried to incorporate the new asciidoc manual(html) in the
>>> website but honestly this is a real pain, if someone got a easy solution
>>> for this. Please let me know otherwise I will just make it open in a new
>>> tab.
>>> Here is what I mean with incorporate:
>>> http://mhautman.com/karaf-site/manual.html
>>>
>>> Any comments, hints, tips is more then welcome, so please shoot!
>>>
>>> Regards,
>>> Morgan
>>>
>>>
>>
>>
>

Re: [DISCUSSION] Introduction to OSGi powered by Apache Karaf

[Milen Dyankov]

You have 2 steps presentation then ;)

*what OSGi is *

Bundle resolving lifecycle, requirements and capabilities, service
registry, whiteboard pattern, config admin, ... Basically those things that
make OSGi unique. If you wish to compare with microservices you may have a
look at
http://www.slideshare.net/MilenDyankov1/liferay7-microservices4enterprise
It's not state of the art deck but may give some ideas.


*how Karaf can simplify the life  *

Definitely features. Both form "easy to install applications with complex
dependency graphs" and "easy to create your own features" perspective. I
would also mention instances and perhaps clustering with cellar. Obviously
the console and the fact that you can ssh directly inside you application
(even though you can do that with plain Felix/Equinox too) and script
things.


Best,
Milen



On Sun, Sep 13, 2015 at 9:44 PM, Christian Schneider <
ch...@die-schneider.net> wrote:

> I think the main arguments for karaf are the console, the maven
> integration and the support for a wide range of Apache and other projects
> out of the box like
> ActiveMQ, CXF, Camel, Aries, Hibernate, Eclipselink, OpenJPA, pax exam,
> pax cdi, pax jdbc. Of course you can not look into these in detail in an
> hour but you can
> show how easy it is to install some of these especially with the repo-add
> aliases.
>
> Something that might work well is to prepare a very small application that
> shows how to combine some of the above projects. For all OSGi projects
> outside karaf integrating all these project is a really big challenge.
>
> For example I showed a little karaf application with a web UI, rest
> service (CXF) and twitter integration (Camel) some time ago:
> https://github.com/cschneider/Karaf-Tutorial/tree/master/voting
>
> https://docs.google.com/presentation/d/1990fWP3I0-WN2ZRiOJQY2o_HdAkIWmArPRDc_122dF0/
>
> Christian
>
> On 13.09.2015 21:15, Krzysztof Sobkowiak wrote:
>
>> Hi
>>
>> Assume you have 1 hour for a talk and you would like to show the Java
>> developers what OSGi is and how Karaf can simplify the life while
>> developing the OSGi application. Which topics would you include in this
>> talk?
>>
>> Kindly regards
>> Krzysztof
>>
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>


-- 
http://about.me/milen

Re: [DISCUSSION] Karaf Boot

[Milen Dyankov]

Thanks for your examples Jean-Baptiste! I was tinning more about practical
business use cases, but let me comment on those.

First though a little disclaimer. Even though I'm familiar with how
Blueprint works in general, I have not used it for anything serious. For me
it has always been too Spring'ish and the amount of "magic" it uses is a
little bit too much. I moved from iPojo to DS and this is what I have been
using for the last couple of years. So I would leave aside the native OSGi
(I fully agree with Christian on that one) and Blueprint (I don't feel I'm
in a position to comment in a prejudice free way).

Now about the examples.  I don't think I need to comment on the first one
at all. Assuming you are right in your estimations I don't think 5% is
worth learning yet another approach. Especially one that tries to hide from
you how things actually work. And as the project grows I think those 5%
will quickly go down to 0 (if not in the negative range) because one can
hardly do anything serious in OSGi without good understanding of how
service registry (including filters, ratings, patterns, configadmin, ...)
works .

As for the second example - I think there is a huge difference between
remote services (REST, SOAP, ...) and persistence / transactions and we
should not consider those equal to automate / simplify. Remote services are
straightforward. You request a resource, something builds it for you (how,
is totally out of scope for the use case) and sends it back to you in the
form requested. This is very very easy to automate. In fact in one of my
demos (which btw I will present at ApacheCon) I do exactly that. It's
bundle with a single class using standard JAX-RS annotations. I don't see
how can you make it any easier than that.

JPA and JTA is a whole different story. It is complex. Not because of the
standard, framework or the implementation but because of the domain it
operates on. Developer need to know the model, relationships, constraints,
isolation levels, limitation of the underlying storage, ... thousands of
things. Honestly speaking I don't see
@jpa(provider="openjpa",dataSource="my") useful for anything but a very
simple use case (tempted to write a "hello world" equivalent). I still
remember the CMP EJB that was supposed to make this so simple and how it
died naturally because simple equals limited. Then Hibernate made ORM
useful. But let's be honest here, it was far from simple. And still people
were moving from EJB to Hibernete to get the job done. We (the Java
community) have walked a long way to bring ORM to what it is today and it's
still far from simple. That is because the problem it targets is complex
and flexibility is far more important for any real use case.

With all the respect, I don't believe a few high level annotations will
make anyone switch to Karaf for some serious projects. For personal
projects and initial attraction - may be. But if you want to introduce this
as a technology to be used in a real project - "it's easy" is not enough
argument  to convince your senior architects. In fact I would argue that if
the SpringBoot didn't have the word "Spring" in it (and all the trust and
marketing that goes with that) it could have existed for a number of years
and none of us would have heard about it.

On the other hand in the OSGi landscape we already have a bunch of projects
which goal is to make it easier for Java EE folks to move to OSGi world.
But even they have realized you can't completely ignore and hide OSGi. You
are probably familiar with Amdatu's projects. I must admit I find their web
services and DOSGi approach a lot easier than CXF. Also more flexible. But
it's not only that. Out of curiosity, I just had a look at Pax CDI and
surprise surprise there is a @OsgiService annotation there. There is also
an explanation of requirements and capabilities which one need to
understand. Sure those can be generated for you by the build tool and you
can completely ignore @OsgiService annotation and only wire your beans. But
in such case my question would be: why are you using OSGi ? There is also
bnd and bndtools that in many cases simplify development a lot (and you can
use them with ant, maven, gradle, whatever the build system of tomorrow
will be).

My point is, I wish we (OSGi community) were more united and more
collaborating. I think there is too much internal competition in the space
and efforts are focused in promoting particular projects (often by
attempting to compete with a well established JEE product) and not so much
the technology itself. I think OSGi (as of release 6) is simple enough. I
think there are plenty (IMHO too many) of choices for developing OSGi
applications to choose from to be as close as possible to what you already
know. I think it will never be the case that someone would develop
something serious with OSGi without investing in knowing how it works! I
think what is hard is hard because it has to be hard. When it is "hard" it
make you think 

Re: [DISCUSSION] Karaf Boot

[Milen Dyankov]

Can someone please point me to an example use case that is "easy" to do
with SpringBoot but "hard" with Karaf? Some of you mentioned you know
people that have concidered Karaf but went with SpringBoot because it's
easier. Is there anything more concrete than the subjective "easy" vs.
"hard" judgment?
12 wrz 2015 20:52 "Jean-Baptiste Onofré"  napisał(a):

Documentation is always good, but more than reading the documentation,
people may want something ready to go with minimal documentation.

I'm working on huge refactoring of Karaf developer guide, providing
documentation about scr/ds, cdi, jpa, jta, etc. It's time consuming but a
must have. So it means users will spend so much time just to
mimic/duplication what's describe in the documentation, ready a long long
one.

The goal is to simplify the artifact with minimal documentation.

For me, it's different approach: something easy and quick, on the other
hand detailed documentation for advanced users.

Regards
JB


On 09/12/2015 07:51 PM, garyhodgson wrote:

> Hi JB,
>
> A set of BoMs and archetypes, together with the corresponding
> documentation, would certainly be a great benefit to the project.
> Particularly if, in the process, it helps resolve outstanding issues such
> as missing profile documentation, the karaf:run functionality, the
> developer documentation, etc.  My fear is that the talk of mimicking
> spring-boot, with @jpa annotations and such, would turn into a time and
> resource black hole.
>
> To your statement: "I bet your spent lot of time and efforts on choosing
> the right programming model, setup your modules, etc." - this is correct to
> some extent, but largely due to incomplete documentation about the plethora
> of options available.  The Enterprise sections of the user guide is
> woefully inadequate in this regard.  In these cases a Bom or Archetype
> would give another useful example, but it wouldn't take the place of some
> well written, and well-maintained documentation about the various
> technologies available.  Case in point, it was Christian's blog posts that
> mainly got me up to speed with JPA etc.
>
> Regards,
> Gary
>
> On 12 September 2015 at 18:22, jbonofre [via Karaf] <
> ml-node+s922171n4042537...@n3.nabble.com> wrote:
>
> Hi Gary,
>>
>> Your point about the Jira is fair, but this remark applies to any
>> project. My point is that unfortunately, all our efforts are nothing if
>> we don't provide tooling for developer users. It's really frustrating to
>> get feedback like "Karaf is awesome, but I prefer other (like
>> spring-boot) just because is simpler to start with".
>>
>> My goal is not the Karaf starter/bootstrapper first (by the way, I
>> already have karaf:run ready on one of my branches), it's first a set of
>> BoM, samples and documentation to quickly start "key turn" artifacts.
>> Actually, part of karaf-boot came when I work (and still working ;)) on
>> the Karaf developer guide.
>>
>> I bet your spent lot of time and efforts on choosing the right
>> programming model, setup your modules, etc. That's my concern: it can be
>> long and sometime complex.
>>
>> Regards
>> JB
>>
>> On 09/12/2015 02:23 PM, garyhodgson wrote:
>>
>> Hi,
>>>
>>> I thought I would add briefly to the discussion my opinion as a relative
>>> newcomer to OSGi and Karaf, who is evaluating introducing it as part of
>>>
>> our
>>
>>> architecture at $WORK.
>>>
>>> Whilst I can see the attraction of working on some kind of karaf-boot
>>> offering, my concern is that it would take resources away from other
>>>
>> less
>>
>>> exciting, yet more important, tasks such as documentation, ensuring
>>> stability and bug fixing.
>>>
>>> Although it's probably not a popular opinion, I would say that working
>>> through some of the (currently) 559 unresolved issues in Jira should
>>>
>> take
>>
>>> priority over any new endeavour.
>>>
>>> The flexible nature of OSGi and Karaf means that any karaf-boot solution
>>> would have to be either (a) very opinionated as to what technologies to
>>>
>> use
>>
>>> (DS, BP, etc), and therefore have a narrow target audience; or (b)
>>>
>> highly
>>
>>> configurable and consequently almost as complex as implementing a
>>>
>> solution
>>
>>> from scratch (I think OSGiliath exhibits this trend to some extent).
>>>
>>> To introduce Karaf, et al at $WORK, I have ended up creating a
>>>
>> multi-module
>>
>>> Maven project with a features module, a custom Karaf module, a business
>>> module with CDI/JPA etc. All of which can be made running quite easily
>>>
>> (and
>>
>>> could be further enhanced by creating a "karaf:run" type command,which
>>> sounds like what "karaf-boot-starter" is expected to do.).  Having a
>>>
>> "quick
>>
>>> start" archetype which sets this up would of course be useful,
>>>
>> particularly
>>
>>> for those beginning with Karaf, but any realistic project will soon have
>>>
>> to
>>
>>> change or replace parts to suit their own requirements.  In my opinion,
>>> having more 

Re: [DISCUSSION] Karaf Boot

[Milen Dyankov]

gt;>>>>> different BOMs that can be used to add certain functionalities to
> the
> >>>>>> project, aka spring-boot-*-starter.
> >>>>>> To start a karaf-boot I think we should first try to have a
> karaf:run
> >>>>>> available as maven plugin.
> >>>>>>
> >>>>>>
> >>>>>> I already have karaf:run on one of my branches, but the purpose is
> >>>>> different. Let's keep the starter out of the picture for now.
> >>>>>
> >>>>> A BoM can be materialize as a parent-pom, it's the purpose of the
> >>>>> karaf-boot-parent.
> >>>>>
> >>>>> Maven archetype is good, but it's require to execute the archetype,
> >>>>> update
> >>>>> the project definition before being able to build. Of course, it
> makes
> >>>>> sense to provide it.
> >>>>>
> >>>>> But, the big advantage of karaf-boot-parent, it's again easy and key
> >>>>> turn:
> >>>>> I'm a new developer, I just inherit from karaf-boot-parent, I just
> >>>>> define
> >>>>> groupId, artifactId, version, I'm ready to go.
> >>>>>
> >>>>>
> >>>>
> >>>> I'm sorry but this is a too big cannon you use to shoot on sparrows.
> >>>> Think minimalistic and modular. With the karaf-boot-*-starter boms we
> >>>> would
> >>>> achieve something far more modular and closer to what people actually
> >>>> need.
> >>>> And forgive me for comparing it with spring-boot again, the big
> benefit
> >>>> of
> >>>> it is actually those *starter boms.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> The microservice dance
> >>>>>>
> >>>>>> actually it's just add a rest-service on top of a OSGi service,
> that's
> >>>>>> all
> >>>>>> that is needed in Karaf.
> >>>>>> Right now I'm not in favor of any certain framework. CXF seems a bit
> >>>>>> bloated but is known to work, but requires blueprint.
> >>>>>> Jersey, I've seen that to be working with "plain" OSGi. A bit of
> >>>>>> polishing
> >>>>>> and it should be quite easy to use, especially with CDI at hand.
> >>>>>>
> >>>>>> But it needs more to dance the microservice dance, you need "small"
> >>>>>> containers ... which is quite contrary to the way Karaf and OSGi in
> >>>>>> general
> >>>>>> is working with services.
> >>>>>> But this is the point I think the karaf profiles come in handy. You
> >>>>>> don't
> >>>>>> need a full blown Karaf, just a basic infrastructure with your own
> >>>>>> Bundle,
> >>>>>> might as well ignore the shell. In the end dump that into a docker
> >>>>>> container and if you need to do a bugfix do it the "docker" - way.
> >>>>>>
> >>>>>>
> >>>>>> It's another point, but @rest and karaf-boot-starter address this,
> >>>>> using
> >>>>> profiles and karaf minimal distribution.
> >>>>>
> >>>>>
> >>>>
> >>>> here we are inline, a minimalistic distribution based on profiles
> should
> >>>> do.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> spring-boot brings it all in one go
> >>>>>>
> >>>>>> karaf-boot should do the same, but actually I fear we do more then
> >>>>>> needed.
> >>>>>> For a new Project setup I'd rather would like to see different
> >>>>>> karaf-starter-* BOMs and a karaf:run maven plugin
> >>>>>> Some more docuementation for the profiles of Karaf could also be
> >>>>>> helpful
> >>>>>> :D
> >>>>>> to build minimalistic karaf instances runnable in docker containers.
> >>>>>> Regarding the karaf:run it might be interesting to "re-activat

Re: [DISCUSSION] Karaf Boot

[Milen Dyankov]

Guys,

I'm following this discussion and jumping back and forth between "I'm
totally lost" and "oh I get it"!

I get all the tech part, all the maven, annotations, 3rd party
technologies, Blueprint vs. DS vs.  ... and all other tech concerns.
What I don't get is the business / purpose part. Who is the target group of
Karaf Boot ? Is it Karaf users/developers? Is it OSGI developers? Is it
Java developers in general?
Is it just a coincidence/buzzword/..., or there is an attempt to compete
with SpringBoot? If so, what I think we need is rather "OSGIBoot" if you
know what I mean.

Regardless of how it will work I would be more interested how you envision
the usage of it! In another words, consider the 3 cases:
 (a) experienced with Karaf
 (b) experienced with OSGI but not Karaf
 (c) experienced Java SE / EE developer with no OGSi knowledge

How would you try to convince a typical representative of those that they
should try Karaf Boot ?

Best,
Milen




On Thu, Sep 10, 2015 at 5:40 PM, Christian Schneider <
ch...@die-schneider.net> wrote:

> I am not really enthusiastic about duplicating functionality of cxf or
> aries. Aries supports a very nice approach for injections, jpa and jta. Why
> should it make sense to recreate that?
> Aries blueprint also has annoation support even in two flavors (CDI,
> custom). How does the new approach interact with this?
>
> Instead I propose we create support for such annotations in the respective
> projects (where they are missing) and concentrate on karaf as a container
> not an application development framework.
> By leveraging the existing frameworks we profit from their own development
> teams. Whatever we recreate will have to be developed by the very few
> resources of the karaf team.
>
> Christian
>
>
> Am 10.09.2015 um 16:53 schrieb Jean-Baptiste Onofré:
>
>> Hi Guillaume,
>>
>> thanks for your feedback.
>>
>> I fully agree about providing more high level annotations (it's what I do
>> with @jpa, @rest, @soap, @jta annotations).
>>
>> I agree that the current annotations are too low level, and blueprint
>> "oriented". I just move forward a bit with the current codebase, just to
>> illustrate karaf-boot usage in the samples.
>>
>> But again, you are right, and I will create a new annotations set.
>>
>> One of the purpose of karaf-boot annotations is to "abstract" the actual
>> code/artifact that we generate. So, if now we generate blueprint, without
>> changing the karaf-boot annotations, we will be able to generate something
>> else (why not SCR, etc).
>>
>> I agree with a BOM, but I think it's interesting to provide both:
>> - providing a ready to use parent pom allows developers to create a very
>> simple pom.xml where all plugins and dependencies are already defined
>> - for more advanced devs, they can create their own pom.xml starting from
>> the BOM or archetype.
>>
>> Thanks again for your feedback !
>>
>> Regards
>> JB
>>
>> On 09/10/2015 04:44 PM, Guillaume Nodet wrote:
>>
>>> I like the idea.
>>>
>>> For the annotations, we need to keep really high level.  The annotations
>>> in
>>> the code base right now are much too close to blueprint.
>>> I think we need to grab a small enough subset so that the annotations are
>>> easy to understand for beginners and without any ambiguities, even at the
>>> cost of features.
>>> For example, I think we should restrict to constructor injection, so that
>>> we don't have any bind / rebind / init methods.  We simply need an
>>> optional
>>> @Destroy.  In case the dependencies change at runtime, simply destroy the
>>> bean / service and recreate it the dependencies are still met after the
>>> change.
>>>
>>> If blueprint is to be hidden completely, we may find a better alternative
>>> in SCR or even Felix Dependency Manager, but it does not matter too much
>>> for now.
>>>
>>> I agree with the idea of using a BOM instead of a parent if possible.
>>> I'm
>>> not very familiar, but this is less invasive.
>>>
>>> The real problems will come with the support of higher level annotations
>>> for JAXRS, JPA, etc...
>>> Not really sure how to handle those yet...
>>>
>>>
>>> 2015-09-09 16:32 GMT+02:00 Jean-Baptiste Onofré :
>>>
>>> Hi all,

 I worked on a prototype about Karaf Boot.

 Let me give you some backgrounds and discuss about that all together.

   Why Karaf Boot ?
   
 When you develop artifacts (bundles) to be deployed in Karaf, you can
 see
 that the actual time that you spend on your business code is finally
 largely less important that all the plumbing effort that you have to do
 (writing OSGi Activator, or blueprint/scr descriptor, etc).

 It means that your "go to market" is longer, and we should provide
 something that allows you to focus on your code.

 Even if SCR annotations is a very good step forward, some use cases are
 not so easy to do (JPA, JTA for instance).

 And anyway, you have to prepare 

Re: [DISCUSSION] Karaf Boot

[Milen Dyankov]

I might be wrong but I think the whole success of SpringBoot (apart from
having the "Spring" in it) is the microservices hype!
it's quick and easy but most usecases follow the "create one (or very few)
service(s), pack them as single executable and access them via REST"
pattern. We can obviously do the same with OSGi and Karaf in particular but
personally I think this makes absolutely no sense. In such approach one in
not benefiting form OSGi almost at all. Honestly speaking I would argue
that if one does not understand how OSGi service layer works (regardless of
the framework used to register/access services) it makes no sense to use
OSGi at all.

Just my 2 cents!

Regards,
Milen

On Thu, Sep 10, 2015 at 6:08 PM, Christian Schneider <
ch...@die-schneider.net> wrote:

> I already created such a maven plugin in aries. The user can use standard
> CDI and JEE annotations and the result is blueprint xml.
> How is the new approach different / better?
>
> Why should it be good for the developer to move away from well defined
> standard annotations and use custom annotations that bind him to karaf?
> I mean if this is created by the spring guys I know they want to catch
> people by perceived simplicity and then make sure to make it difficult to
> switch. As an open source comminity I do not know why we should do
> something like this.
> Abstracting away from frameworks just means you create another layer that
> people then also have to learn. There were some cases in the past where
> this make sense because the underlying frameworks sucked (like JEE 2). This
> is not the case today though I think.
>
> What kind of use case do you have in mind? Every project starts small but
> it needs to be able to grow then. You can not start with custom annoations
> and then tell people to later switch to something else when the
> project grows. I think it makes more sense to make it easier for people to
> use the standard annoations and use the right dependencies.
>
> If we simply provide a tooling that makes it easy to start with SCR or
> blueprint we provide much more value for people as thery can then grow
> without any breaking changes.
>
> Christian
>
>
> Am 10.09.2015 um 17:46 schrieb Jean-Baptiste Onofré:
>
>> Because all these annotations are runtime: here we talk about tooling at
>> build time.
>>
>> More over, the purpose is to provide more high level annotations, which
>> abstract actual annotations/frameworks that we can use under hood.
>>
>> The purpose of centralizing all in karaf-boot is to have a central
>> project: the developer just use karaf-boot, it doesn't really know what
>> technologies are involved behind the scene.
>>
>> For instance, in spring-boot, they use activemq, jersey, etc, but all
>> from spring-boot. The developers don't know a rest service use jersey for
>> instance, it's completely abstracted.
>>
>> Again the purpose is to simplify life for developers: splitting the
>> annotations in different projects introduces complexity (at least to find
>> the dependencies and core import packages).
>>
>> If an advanced developer wants to use CDI, SCR, etc, he can of course.
>>
>> Regards
>> JB
>>
>> On 09/10/2015 05:40 PM, Christian Schneider wrote:
>>
>>> I am not really enthusiastic about duplicating functionality of cxf or
>>> aries. Aries supports a very nice approach for injections, jpa and jta.
>>> Why should it make sense to recreate that?
>>> Aries blueprint also has annoation support even in two flavors (CDI,
>>> custom). How does the new approach interact with this?
>>>
>>> Instead I propose we create support for such annotations in the
>>> respective projects (where they are missing) and concentrate on karaf as
>>> a container not an application development framework.
>>> By leveraging the existing frameworks we profit from their own
>>> development teams. Whatever we recreate will have to be developed by the
>>> very few resources of the karaf team.
>>>
>>> Christian
>>>
>>> Am 10.09.2015 um 16:53 schrieb Jean-Baptiste Onofré:
>>>
 Hi Guillaume,

 thanks for your feedback.

 I fully agree about providing more high level annotations (it's what I
 do with @jpa, @rest, @soap, @jta annotations).

 I agree that the current annotations are too low level, and blueprint
 "oriented". I just move forward a bit with the current codebase, just
 to illustrate karaf-boot usage in the samples.

 But again, you are right, and I will create a new annotations set.

 One of the purpose of karaf-boot annotations is to "abstract" the
 actual code/artifact that we generate. So, if now we generate
 blueprint, without changing the karaf-boot annotations, we will be
 able to generate something else (why not SCR, etc).

 I agree with a BOM, but I think it's interesting to provide both:
 - providing a ready to use parent pom allows developers to create a
 very simple pom.xml where all plugins and dependencies are already
 

Re: [DISCUSSION] Karaf Boot

[Milen Dyankov]

So correct me if I'm wrong but if I get the sample you provided in the
first mail and replace:
 - the parent pom with "maven-bundle-plugin"
 - @Bean with @Component
 - @Init with @Activate

wouldn't that have the exact same end result? I mean it obviously differ in
terms of what gets generated (Blueprint vs DS) but form end user
perspective there is no difference, right?




On Thu, Sep 10, 2015 at 6:55 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> Hey Milen,
>
> Actually, there's too part:
> 1/ karaf-boot-starter will do the ready to start artifact, embedding
> karaf, but it's another point
> 2/ the value of karaf-boot annotations and plugin is first to simplify the
> bundle/artifact ready to be deploy-able into Karaf (generate the "plumbing"
> easily for developers).
>
> Regards
> JB
>
>
> On 09/10/2015 06:50 PM, Milen Dyankov wrote:
>
>> " ... that you deploy in Karaf ..."
>>
>> OK may be I misunderstood the concept. I thought the result is standalone
>> executable JAR, thus my comments above. If on the other hand I need to
>> install Karaf and then deploy my services into it I really don't see how
>> it
>> differs form what people are doing now?
>>
>> I'm sorry if I'm not making much sense. I didn't have the time to
>> experiment with your code and samples so may be I'm missing an important
>> peace here.
>>
>> Best,
>> Milen
>>
>>
>> On Thu, Sep 10, 2015 at 6:27 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
>> wrote:
>>
>> Allow me to disagree: Karaf is a perfect container for microservices.
>>>
>>> Image to create a microservice (using karaf-boot) that you deploy in
>>> Karaf
>>> and use such service in another microservice, all wired with OSGi service
>>> and Karaf: we leverage OSGi/Karaf as a microservices container.
>>>
>>> But even without talking of microservices, new developers to Karaf (and
>>> OSGi generally speaking) are frustrated by the effort on non business
>>> code
>>> to do (I have to write an Activator, or a descriptor, etc, etc).
>>> So, a tooling to simplify this is still a valid addition IMHO.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 09/10/2015 06:23 PM, Milen Dyankov wrote:
>>>
>>> I might be wrong but I think the whole success of SpringBoot (apart from
>>>> having the "Spring" in it) is the microservices hype!
>>>> it's quick and easy but most usecases follow the "create one (or very
>>>> few)
>>>> service(s), pack them as single executable and access them via REST"
>>>> pattern. We can obviously do the same with OSGi and Karaf in particular
>>>> but
>>>> personally I think this makes absolutely no sense. In such approach one
>>>> in
>>>> not benefiting form OSGi almost at all. Honestly speaking I would argue
>>>> that if one does not understand how OSGi service layer works (regardless
>>>> of
>>>> the framework used to register/access services) it makes no sense to use
>>>> OSGi at all.
>>>>
>>>> Just my 2 cents!
>>>>
>>>> Regards,
>>>> Milen
>>>>
>>>> On Thu, Sep 10, 2015 at 6:08 PM, Christian Schneider <
>>>> ch...@die-schneider.net> wrote:
>>>>
>>>> I already created such a maven plugin in aries. The user can use
>>>> standard
>>>>
>>>>> CDI and JEE annotations and the result is blueprint xml.
>>>>> How is the new approach different / better?
>>>>>
>>>>> Why should it be good for the developer to move away from well defined
>>>>> standard annotations and use custom annotations that bind him to karaf?
>>>>> I mean if this is created by the spring guys I know they want to catch
>>>>> people by perceived simplicity and then make sure to make it difficult
>>>>> to
>>>>> switch. As an open source comminity I do not know why we should do
>>>>> something like this.
>>>>> Abstracting away from frameworks just means you create another layer
>>>>> that
>>>>> people then also have to learn. There were some cases in the past where
>>>>> this make sense because the underlying frameworks sucked (like JEE 2).
>>>>> This
>>>>> is not the case today though I think.
>>>>>
>>>>> What kind of use case do you have in mind? Ever

Re: [DISCUSSION] Karaf Boot

[Milen Dyankov]

" ... that you deploy in Karaf ..."

OK may be I misunderstood the concept. I thought the result is standalone
executable JAR, thus my comments above. If on the other hand I need to
install Karaf and then deploy my services into it I really don't see how it
differs form what people are doing now?

I'm sorry if I'm not making much sense. I didn't have the time to
experiment with your code and samples so may be I'm missing an important
peace here.

Best,
Milen


On Thu, Sep 10, 2015 at 6:27 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> Allow me to disagree: Karaf is a perfect container for microservices.
>
> Image to create a microservice (using karaf-boot) that you deploy in Karaf
> and use such service in another microservice, all wired with OSGi service
> and Karaf: we leverage OSGi/Karaf as a microservices container.
>
> But even without talking of microservices, new developers to Karaf (and
> OSGi generally speaking) are frustrated by the effort on non business code
> to do (I have to write an Activator, or a descriptor, etc, etc).
> So, a tooling to simplify this is still a valid addition IMHO.
>
> Regards
> JB
>
>
> On 09/10/2015 06:23 PM, Milen Dyankov wrote:
>
>> I might be wrong but I think the whole success of SpringBoot (apart from
>> having the "Spring" in it) is the microservices hype!
>> it's quick and easy but most usecases follow the "create one (or very few)
>> service(s), pack them as single executable and access them via REST"
>> pattern. We can obviously do the same with OSGi and Karaf in particular
>> but
>> personally I think this makes absolutely no sense. In such approach one in
>> not benefiting form OSGi almost at all. Honestly speaking I would argue
>> that if one does not understand how OSGi service layer works (regardless
>> of
>> the framework used to register/access services) it makes no sense to use
>> OSGi at all.
>>
>> Just my 2 cents!
>>
>> Regards,
>> Milen
>>
>> On Thu, Sep 10, 2015 at 6:08 PM, Christian Schneider <
>> ch...@die-schneider.net> wrote:
>>
>> I already created such a maven plugin in aries. The user can use standard
>>> CDI and JEE annotations and the result is blueprint xml.
>>> How is the new approach different / better?
>>>
>>> Why should it be good for the developer to move away from well defined
>>> standard annotations and use custom annotations that bind him to karaf?
>>> I mean if this is created by the spring guys I know they want to catch
>>> people by perceived simplicity and then make sure to make it difficult to
>>> switch. As an open source comminity I do not know why we should do
>>> something like this.
>>> Abstracting away from frameworks just means you create another layer that
>>> people then also have to learn. There were some cases in the past where
>>> this make sense because the underlying frameworks sucked (like JEE 2).
>>> This
>>> is not the case today though I think.
>>>
>>> What kind of use case do you have in mind? Every project starts small but
>>> it needs to be able to grow then. You can not start with custom
>>> annoations
>>> and then tell people to later switch to something else when the
>>> project grows. I think it makes more sense to make it easier for people
>>> to
>>> use the standard annoations and use the right dependencies.
>>>
>>> If we simply provide a tooling that makes it easy to start with SCR or
>>> blueprint we provide much more value for people as thery can then grow
>>> without any breaking changes.
>>>
>>> Christian
>>>
>>>
>>> Am 10.09.2015 um 17:46 schrieb Jean-Baptiste Onofré:
>>>
>>> Because all these annotations are runtime: here we talk about tooling at
>>>> build time.
>>>>
>>>> More over, the purpose is to provide more high level annotations, which
>>>> abstract actual annotations/frameworks that we can use under hood.
>>>>
>>>> The purpose of centralizing all in karaf-boot is to have a central
>>>> project: the developer just use karaf-boot, it doesn't really know what
>>>> technologies are involved behind the scene.
>>>>
>>>> For instance, in spring-boot, they use activemq, jersey, etc, but all
>>>> from spring-boot. The developers don't know a rest service use jersey
>>>> for
>>>> instance, it's completely abstracted.
>>>>
>>>> Again the purpose is to simplify life for developers: spli

Re: [DISCUSSION] Karaf Boot

[Milen Dyankov]

Well I was just referring to your example but I get your point. Which
reminds me of EnRoute <http://enroute.osgi.org/> project which despite the
big names and the most popular OSGI build tool behind it, doesn't seem to
get as much traction as I expected!

That said, I really admire your enthusiasm and wish KarafBoot can be more
successful that that. I'm not trying to discourage you! Just it seams what
you are after is something that other people have tried already with
questionable success.

Best,
Milen



On Thu, Sep 10, 2015 at 7:22 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> And how to you deal with jpa, jta, rest, etc with SCR annotations ?
>
> Regards
> JB
>
>
> On 09/10/2015 07:16 PM, Milen Dyankov wrote:
>
>> So correct me if I'm wrong but if I get the sample you provided in the
>> first mail and replace:
>>   - the parent pom with "maven-bundle-plugin"
>>   - @Bean with @Component
>>   - @Init with @Activate
>>
>> wouldn't that have the exact same end result? I mean it obviously differ
>> in
>> terms of what gets generated (Blueprint vs DS) but form end user
>> perspective there is no difference, right?
>>
>>
>>
>>
>> On Thu, Sep 10, 2015 at 6:55 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
>> wrote:
>>
>> Hey Milen,
>>>
>>> Actually, there's too part:
>>> 1/ karaf-boot-starter will do the ready to start artifact, embedding
>>> karaf, but it's another point
>>> 2/ the value of karaf-boot annotations and plugin is first to simplify
>>> the
>>> bundle/artifact ready to be deploy-able into Karaf (generate the
>>> "plumbing"
>>> easily for developers).
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 09/10/2015 06:50 PM, Milen Dyankov wrote:
>>>
>>> " ... that you deploy in Karaf ..."
>>>>
>>>> OK may be I misunderstood the concept. I thought the result is
>>>> standalone
>>>> executable JAR, thus my comments above. If on the other hand I need to
>>>> install Karaf and then deploy my services into it I really don't see how
>>>> it
>>>> differs form what people are doing now?
>>>>
>>>> I'm sorry if I'm not making much sense. I didn't have the time to
>>>> experiment with your code and samples so may be I'm missing an important
>>>> peace here.
>>>>
>>>> Best,
>>>> Milen
>>>>
>>>>
>>>> On Thu, Sep 10, 2015 at 6:27 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
>>>> wrote:
>>>>
>>>> Allow me to disagree: Karaf is a perfect container for microservices.
>>>>
>>>>>
>>>>> Image to create a microservice (using karaf-boot) that you deploy in
>>>>> Karaf
>>>>> and use such service in another microservice, all wired with OSGi
>>>>> service
>>>>> and Karaf: we leverage OSGi/Karaf as a microservices container.
>>>>>
>>>>> But even without talking of microservices, new developers to Karaf (and
>>>>> OSGi generally speaking) are frustrated by the effort on non business
>>>>> code
>>>>> to do (I have to write an Activator, or a descriptor, etc, etc).
>>>>> So, a tooling to simplify this is still a valid addition IMHO.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 09/10/2015 06:23 PM, Milen Dyankov wrote:
>>>>>
>>>>> I might be wrong but I think the whole success of SpringBoot (apart
>>>>> from
>>>>>
>>>>>> having the "Spring" in it) is the microservices hype!
>>>>>> it's quick and easy but most usecases follow the "create one (or very
>>>>>> few)
>>>>>> service(s), pack them as single executable and access them via REST"
>>>>>> pattern. We can obviously do the same with OSGi and Karaf in
>>>>>> particular
>>>>>> but
>>>>>> personally I think this makes absolutely no sense. In such approach
>>>>>> one
>>>>>> in
>>>>>> not benefiting form OSGi almost at all. Honestly speaking I would
>>>>>> argue
>>>>>> that if one does not understand how OSGi service layer works
>>>>>> (regardless
>>>>>> of
>>>>>>

Re: Install list of jar files in Karaf 4.0.1

[Milen Dyankov]

Not sure if I understand everything correctly but as Achim pointed out -
the order of deployment should have nothing to do with your dependency
graph.

Once you deploy your bundles (in whatever order) they need to be resolved
and then started. If they can not be resolved (due to missing dependencies
for example) they would not be started. Typically the framework will try to
resolve them again once something changes (like another bundle is
deployed). So the moment those dependencies are provided (or more generally
speaking bundle's requirements match the available capabilities) those
should be started. Only after bundle is started it attempts to register
service(s). Here more or less the same concept apply. Services will be
started only after their dependencies are satisfied (how that happens
depend on whether a framework is used and if so, how it is
designed/configured) but at the end of the day it shouldn't matter in what
order those are started. They may not be available for a while but
eventually when everything is in place they should be started and wired
properly.

Now all that is true, assuming that all bundles/services take into account
the very basic principle of OSGI - things can come and go at any time. If
that is not the case then perhaps your application is not benefiting much
from OSGi on first place. May be you should fix that or may be give up on
OSGi (at least until you fix it). Personally I think the fact that a
deployment order is significant, 99% of the time means something really
poorly designed or overlooked.

Best,
Milen




On Wed, Sep 9, 2015 at 1:28 PM, rcbandit  wrote:

> Yes, it's because of rushing to complete the project with very little time
> -
> this is the result, poor quality.
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Install-list-of-jar-files-in-Karaf-4-0-1-tp4042400p4042427.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>



-- 
http://about.me/milen

Re: [PROPOSAL] Create and provide karaf-boot plugin

[Milen Dyankov]

Comparing to SpringBoot is exactly what I wanted to write about.

But from psychological point of view, it has to be able to put everything
in a single executable jar to be able to convince people.

I recently used both SpringBoot and Felix in a demo and some feedback I had
was see but SpringBoot is just one jar while in Felix you need to deploy
like in EE container
The facts that (a) extracted SpringBoot generated jar file contains much
more than felix + relevant bundle (b) it uses roughly twice the memory and
(c) it loads roughly twice as many classes - was largely ignored.

So for me personally it's not a big deal - I like Karaf the way it is and I
know how to work with it. However for marketing purposes it would be nice
to have a feature that will generate a compile app by running a single
maven command.

Just my 2 cents

Best,
Milen


On Tue, Apr 28, 2015 at 10:22 AM, Jean-Baptiste Onofré j...@nanthrax.net
wrote:

 Hi Fabian,

 I fully agree.

 My point is more to follow the docker discussion that we have. Lot of
 people see Karaf as a complex and large container, and they prefer usage
 of spring-boot for instance. I want to show that Karaf is now a very
 modern, flexible, lightweight and polymorphic container. So, as I don't
 think it's a lot of effort, I would like to provide the tooling (code,
 bootstrapper, etc) to provide an alternative to spring-boot based on Karaf.

 My €0.02 ;)

 Regards
 JB


 On 04/28/2015 09:06 AM, Fabian Lange wrote:

 Hi JB,

 correct. But I don't consider that to be a real problem. I have to deal
 with about 50 osgi bundles at the moment. And because the standard
 assembly
 is not in the layout I want I would anyway need to have one to change the
 layout and customize the contents (properties etc).

 So my opinion is that while your proposal is nice to have, its not really
 worth much effort, because anybody who wants to build a dist needs
 actually
 much more control, rather than more helper magic.

 Fabian

 On Tue, Apr 28, 2015 at 7:28 AM, Jean-Baptiste Onofré j...@nanthrax.net
 wrote:

  Hi Fabian,

 I fully agree with you that creating a custom distro is easy but, correct
 me if I'm wrong, right now, you have:
 - modules with your application code
 - a module dedicated for your feature
 - a module dedicated for your custom distribution assembly

 You provision the distribution created by the assembly.

 What I'm proposing is just a simple way to have a ready to go code and
 building, in order to avoid the overhead of the custom distribution
 plumbing module.

 Regards
 JB


 On 04/27/2015 09:57 PM, Fabian Lange wrote:

  Hi,

 quick feedback from here. I used the current 4.0 way of building my
 custom
 dist and it was actually easy enough.
 What you propose seems to hide a few karaf details, which I personally
 think should be handled explicitly.

 In my case for example, I am actually happy with managing the required
 bootFeatures myself.

 Fabian

 On Mon, Apr 27, 2015 at 9:53 PM, Jean-Baptiste Onofré j...@nanthrax.net
 wrote:

   Actually, I wasn't clear.


 At I'm proposing is not only a new plugin, it's also a dependency.

 Imagine, that in your project pom.xml, you have:

 parent
 groupIdorg.apache.karaf.boot/groupId
 artifactIdkaraf-boot-starter-parent/artifactId
 version4.0.0-SNAPSHOT/version
 /parent

 The parent contains all plugins and dependencies set, especially the
 Karaf
 standard distribution.

 Later in your pom.xml, you have:

 build
 plugins
 plugin
 groupIdorg.apache.karaf.boot/groupId
 artifactIdkaraf-boot-maven-plugin/artifactId
 /plugin
 /plugins
 /build

 In your project, you just need a class describing your Karaf
 bootstrapping:

 @KarafBootApplication
 @WithShell
 @profiles({a,b,c})
 @featuresBoot({f1,f2})
 public class MyContainer implements KarafBootstrapper {

 @Override
 public void run() {
 // setup your Karaf bootstrapping
 }

 }

 The user can add boot features to customize the container:

 dependency
 groupIdorg.apache.karaf.boot/groupId
 artifactIdorg.apache.karaf.boot.webcontainer/artifactId
 /dependency

 for instance it will automatically add Pax Web war feature in
 featuresBoot
 (no need to use @featuresBoot).

 The purpose is to (depending of the goal used by the user):
 1/ be able to run container+application easily
 2/ package a custom distribution, ready to go (key turn) including
 applications

 Again, the approach is, from the native user codebase, be able to
 bootstrap a container embedding the user applications. This container
 can
 be started directly from the project, and provide an artifact ready to
 deploy (on docker, or whatever). The artifact is actually a custom
 karaf
 distribution.

 I hope it's clearer. Again, it's just an idea, but IMHO, it will give a
 new dimension to Karaf: it will turn Karaf as a modern polymorphic
 container.
 The users can still use Karaf standalone where they do the
 provisioning,
 or they can use Karaf boot as basis for key turn application
 container.

 Regards
 JB

 On 

Re: [DISCUSS] Remove features lifecycle in K4

[Milen Dyankov]

Please correct me if I'm wrong but aren't we talking about a problem that
(at least conceptually) has been solved? Package management has been around
in Linux for quite some time. Can't features just mimic the same behavior?
From my perspective features are quite similar to virtual packages in
Debian based linux distributions.

Best,
Milen
14 kwi 2015 08:54 Christian Schneider ch...@die-schneider.net
napisał(a):

 I was not aware we have this information in the wires. I will try to
 implement it using these.

 So what I would do is this:
 I start with the features to be stopped / started.
 I then propagate down to the subfeatures / bundles.
 For each feature processed I compute the state as the highest state of all
 features that depend on it and the requested state.

 Does that make sense?

 The problem in this algorithm is that in many cases we will not be able to
 stop features / bundles as they are needed by other features.
 So probably we will need some reporting to explain why some features /
 bundles could not achieve the request state. To really stop a feature the
 user would then
 have to stop all top level features. Only then would it really change its
 state.

 We could also have kind of a force mode where we change the state first to
 the top and then down again. So this would guarantee that a feature changes
 its state but it could shut down half of karaf unintendedly. Which would be
 especially dangerous if we hit some core features like the feature service.
 So I tend to rather not support this.

 Christian

 On 13.04.2015 18:01, Guillaume Nodet wrote:

 Yeah, I was thinking about it.
 Though the obvious other solution is to fix it.

 I have actually started an email this morning to discuss but I haven't
 finished it.

 Overall, I think it may not be very difficult to fix, as the bundle state
 changes are already handled correctly afaik.  The real problem is to agree
 on the semantics on the effects, so that we can compute the desired state
 of each bundle correctly.

 Problems arise when a bundle is used by several features, one of which
 being started and the other resolved.

 Anyway, it's really up to you, I don't mind fixing the code as long as we
 agree on the behaviour.

 2015-04-13 17:51 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net:

  Hi all,

 I discussed with Christian about KARAF-3102.

 The feature lifecycle doesn't actually fully work, especially around the
 stop action.

 In order to avoid to perturb the users, I think we should remove the
 features lifecycle commands. Else, if they are provided, users will try
 it
 and may be disappointed as they won't work as expected.

 WDYT ?

 Regards
 JB
 --
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com



 --
 Christian Schneider
 http://www.liquid-reality.de

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

Re: [DISCUSS] Remove features lifecycle in K4

[Milen Dyankov]

Hi Jean-Baptiste,

perhaps I don't understand what is discussed here and what you meant by remove
the features lifecycle commands.

Just wanted to share my point of view regarding features. That is, I see
features as deployment option (get needed bundles in place) and not as
bundle lifecycle batch management option. Or to follow up with my linux
example, one will do apt-get install mysql which will install also a
bunch of other things apart form mysql itself. But one does not do apt-get
start/stop mysql because that does not make sense. So if those are the
commands you think of removing then that's fine with me (although a bundle
start/stop batch job based on feature as grouping option is nice to have in
some cases)
But what is more important for me personally is to be able to tell how a
bundle was installed (stand alone or via feature). AFAIK this is not
something provided in K3

Best,
Milen




On Tue, Apr 14, 2015 at 11:14 AM, Jean-Baptiste Onofré j...@nanthrax.net
wrote:

 Hi Milen,

 we already have the Jira about what you propose, and it's not K4 related:
 it's already for K3.

 Regards
 JB


 On 04/14/2015 11:12 AM, Milen Dyankov wrote:

 I was thing about something like 3 base functionalities (with respect to
 configured repositories):

 feature:install  - installs a feature, all sub-featirues, bundles, ... (I
 guess nothing needs to change here)
 feature:remove - removes the feature only. All sub-features, bundles, are
 not touched! Perhaps there could be -r option to remove sub-features as
 well but bundles will always remain unchanged
 feature:list - shows bundles installed by a feature * even if the feature
 is not installed *
 bundle:provided-by - shows features that install that bundle (even if
 those
 are not currently installed)

 Given those above one could then script / develop all kind of helper
 command / tools. Like for example :

 autoclean - removes all bundles that were (1) installed as part of a
 feature which was removed and (2) no other feature point to them
 forced-remove - removes all bundles that were installed by given feature
 even if in use
 

 Does it make sense?





 On Tue, Apr 14, 2015 at 9:11 AM, Christian Schneider 
 ch...@die-schneider.net wrote:

  Very well possible. What is the algorithm in Linux?

 Christian

 On 14.04.2015 09:06, Milen Dyankov wrote:

  Please correct me if I'm wrong but aren't we talking about a problem
 that
 (at least conceptually) has been solved? Package management has been
 around
 in Linux for quite some time. Can't features just mimic the same
 behavior?
   From my perspective features are quite similar to virtual packages in
 Debian based linux distributions.

 Best,
 Milen
 14 kwi 2015 08:54 Christian Schneider ch...@die-schneider.net
 napisał(a):


  --
 Christian Schneider
 http://www.liquid-reality.de

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





 --
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com




-- 
http://about.me/milen

Re: [DISCUSS] Remove features lifecycle in K4

[Milen Dyankov]

I was thing about something like 3 base functionalities (with respect to
configured repositories):

feature:install  - installs a feature, all sub-featirues, bundles, ... (I
guess nothing needs to change here)
feature:remove - removes the feature only. All sub-features, bundles, are
not touched! Perhaps there could be -r option to remove sub-features as
well but bundles will always remain unchanged
feature:list - shows bundles installed by a feature * even if the feature
is not installed *
bundle:provided-by - shows features that install that bundle (even if those
are not currently installed)

Given those above one could then script / develop all kind of helper
command / tools. Like for example :

autoclean - removes all bundles that were (1) installed as part of a
feature which was removed and (2) no other feature point to them
forced-remove - removes all bundles that were installed by given feature
even if in use


Does it make sense?





On Tue, Apr 14, 2015 at 9:11 AM, Christian Schneider 
ch...@die-schneider.net wrote:

 Very well possible. What is the algorithm in Linux?

 Christian

 On 14.04.2015 09:06, Milen Dyankov wrote:

 Please correct me if I'm wrong but aren't we talking about a problem that
 (at least conceptually) has been solved? Package management has been
 around
 in Linux for quite some time. Can't features just mimic the same behavior?
  From my perspective features are quite similar to virtual packages in
 Debian based linux distributions.

 Best,
 Milen
 14 kwi 2015 08:54 Christian Schneider ch...@die-schneider.net
 napisał(a):


 --
 Christian Schneider
 http://www.liquid-reality.de

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




-- 
http://about.me/milen