karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milen Dyankov <milendyan...@gmail.com>
Subject Re: [DISCUSSION] Karaf Boot
Date Fri, 11 Sep 2015 08:13:18 GMT
I need to partly agree with Achim. I mean I would probably fully agree if I
was to accept the initial problem is as he describe it. But personally I
think it's slightly different. I acknowledge the fact that I may be wrong
in my judgement but here is what it is based on:
 - I have been working with Java EE for the last 15 years
 - I have been "in love" with OSGi for the last 6-7 years but never used it
for anything big (as Achim mentioned, other technologies pay my bills)
 - up until last year OSGi was not part of my day job, and even today it
still is not a major part
 - it's been about 3 years, since the company I work for started migrating
huge EE project to OSGi. Since then, as a consultant, I've have had a
countless discussions with customers and partners about motivation,
worries, challenges, expectations, ...

So from this perspective I think people outside of OSGi simply don't
understand what OSGi is about. And we (all OSGi fans) and not doing nearly
enough to explain it. Bah, some well known and respected sources
<https://www.thoughtworks.com/radar/platforms/osgi> claims OSGi is
practically dead and advises to go "microservices way" or "wait for
Jigsaw". I spent the last year attending conferences and talking about how
OSGi is valuable alternative to microservices and why. And I can tell you
from experience, getting a OSGi talk accepted on a respectful Java
conference is a huge challenge.

So what I sense now is "lets use the microsevices hype to make people shift
to OSGi / Karaf". And to do that, let's make it easy. And to make it easy,
let's hide from them the only thing that makes OGSi stand out - real
dynamic modularity! This may even work, but is that what we really want?
SpringBoot, Docker, Kubernetes, ... are great technologies that make people
think they can do distributed computing without knowing anything about
distributed computing! If you ask me, the fall of disappointment is coming,
we just don't see it yet. And it's not because those technologies are bad.
It's because they made people thing that something that is hard, can be
solved with a bunch of annotations and wrappers. I'm blown away by the fact
there are so many developers out there that believe in magic.

I personally don't want to go down that road. For me the real power of OSGi
is building truly dynamic modular systems than can start as "monoliths" and
scale out to distributed. The fact that one needs to learn to deal with the
dynamism even when everything runs inside a single JVM makes it so much
easier to scale out when the right time comes. Take away (or hide) it from
me and I have absolutely no reason to choose OSGi over JEE. Why should I?
Apart from that one thing JEE ca do everything OSGi can do! JEE community
is by far larger! It's THE "standard"! It's on every single Java
conference! It now supports microservices (if you don't believe me just
watch some recent talk from RedHat fellows)! And with Java 9 on the
horizon, more and more people will be speaking about Jigsaw and how it is
the way to go.

I don't think the response to that should be "hey we do microservies as
well" or "hey we also make it easy to start" or "hey did you know you use
CDI in OSGi too". I think we should concentrate on more evangelism about
what the real power of OSGi is. And for me that means exactly the opposite
of hiding things.

So I generalized about OSGi and naturally you will probably ask about
Karaf. What made me look at and stay with Karaf for my personal projects
was "features/KARs", "instances" and much friendlier console! I still
prefer Karaf's features over subsystems. I would love to see Karaf going
that way - making it easier to work with things, providing useful features,
improving user/developer experience, ... but without hiding things and
without trying to convince people that some "magic" would make it up for
the lack of knowledge.

But that's just me. I may be wrong!

Best,
Milen


On Fri, Sep 11, 2015 at 9:09 AM, Achim Nierbeck <bcanhome@googlemail.com>
wrote:

> Hi,
>
> Fully agree.
> >
> > You want karaf-boot to be a collections of BoM that you can assembly as
> > lego brick: I'm with you !
> >
>
> > Anything that allow us to provide something easy & straight forward is
> > good for me !
> >
> > Let me move forward on karaf-boot and try to create such kind of BoM
> there.
> >
> >
> yeah ... might want to take a look at those available from spring-boot:
>
> https://github.com/spring-projects/spring-boot/tree/master/spring-boot-starters
>
> and to have an easy assmbly we need the following:
> one or more maven-plugin(s) that do the following:
> 1/ build the bundle
> 2/ create the requirements
> 3/ checks the available features in the project (inherited from the BOMs)
> 4/ include those features in the resulting feature
> 5/ instead of a feature generate a profile
> 6/ run a feature/profile based karaf - based on the minimalistic Karaf
> 7/ most important within one project with a karaf-boot packaging :-)
>
> I think only 3 is actually not as good as it should be right now and needs
> improvement.
> But with Karaf4 features it shouldn't be to hard to achieve
> The rest is mostly available today we just need make it work together.
>
> regards, Achim
>
>
>
> > Regards
> > JB
> >
> >
> > On 09/11/2015 08:55 AM, Achim Nierbeck wrote:
> >
> >> Hi JB,
> >>
> >> my point is that you are a veteran on different technologies, that you
> >> know
> >>
> >>> ;)
> >>>
> >>>
> >> and that's the reason I already know where other people are struggling
> >> with.
> >> I do a lot of consulting to people that either don't care or are not
> >> interested in their day-job.
> >> They just need to get that stuff done.
> >> Therefore it needs to be easy as taking a dump.
> >>
> >>
> >>
> >>> But anyway, veteran or not, it would be very helpful to have tooling. I
> >>> would love to have a karaf-boot tool that allows me to quickly create
> my
> >>> artifacts, without taking a look on 3 or 4 different
> >>> projects/technologies,
> >>> plugins, etc/
> >>>
> >>> Just my €0.02 (I'm in € now ;)).
> >>>
> >>>
> >>> I'm with you that we need better tooling, but actually we should focus
> on
> >> the build-chain first.
> >> Make it good, make it awesome.
> >> After that let's take a look on where we find some more room for
> >> improvement.
> >> That's why I think if we talk of *-boot we should focus on having easy
> >> inclusion of different dependencies.
> >> Cause not everybody want's to start with a REST-Microservice, but might
> be
> >> interested in Database first.
> >> That's why we need different BOMs that stick together as lego-bricks.
> >>
> >> regards, Achim
> >>
> >>
> >>
> >> Regards
> >>> JB
> >>>
> >>>
> >>> On 09/11/2015 08:47 AM, Achim Nierbeck wrote:
> >>>
> >>> Hi JB,
> >>>>
> >>>> I'm very sorry but I have to completely disagree on this.
> >>>> Let me point this out inline
> >>>>
> >>>>
> >>>> Generally speaking, I think we are not the best ones to evaluate this
> >>>>
> >>>>> because we are involved in the "low level", and so we might not see
> >>>>> values
> >>>>> there.
> >>>>>
> >>>>>
> >>>>> This might be true for core developers that only work on Karaf, it
> >>>>>
> >>>> certainly doesn't affect me, as my day-job requires me to work with
> >>>> everything else but OSGi. Therefore I think I'm in the very convenient
> >>>> position to say: "I know what is missing and I know where the benefits
> >>>> of
> >>>> Spring-Boot are"
> >>>> Working on Karaf and Pax Web is just a mere hobby for me, as it
> doesn't
> >>>> pay
> >>>> my bills.
> >>>>
> >>>>
> >>>> It would be great to have "new developers" feedback (it's where I
> >>>> started
> >>>>
> >>>>> for karaf-boot actually). That's the key point: think when you are
> very
> >>>>> new
> >>>>> to Karaf and you have to start.
> >>>>>
> >>>>>
> >>>>> see above
> >>>>>
> >>>>
> >>>>
> >>>> Anyway, my comments inline:
> >>>>
> >>>>>
> >>>>>
> >>>>> On 09/10/2015 11:58 PM, Achim Nierbeck wrote:
> >>>>>
> >>>>> Hi
> >>>>>
> >>>>>>
> >>>>>> after reading this thread about two times, I finally understood the
> >>>>>> intention and the confusion in the thread.
> >>>>>> Let me try to summarize this to start some more confusion :-D
> >>>>>>
> >>>>>> Initial Problem:
> >>>>>> - learning OSGi has a steep learning curve
> >>>>>> - initial setup for a new OSGi project needs a lot of
> infrastructural
> >>>>>> "thingis"
> >>>>>> - doing the "microservice" dance is hard as it requires to much
> >>>>>> "extras"
> >>>>>> to
> >>>>>> have a simple REST service
> >>>>>> -- including infrastructure
> >>>>>> - Spring boot brings everything needed in one place in one
> >>>>>> "application"
> >>>>>> with just annotations
> >>>>>>
> >>>>>> These are the "problems" we know of and if I did get it right are
> the
> >>>>>> intention for the Karaf-Boot project.
> >>>>>> Now let me try to summarize the idea on how to solve that.
> >>>>>>
> >>>>>>    From a simple Class file with some annotation generate
> >>>>>> - a OSGi service, including OSGi wiring via Blueprint - via an extra
> >>>>>> maven
> >>>>>> plugin
> >>>>>> - get rid of all those infrastructural "add-ons" for the first OSGi
> >>>>>> bundle
> >>>>>> by having a easy to use Parent-POM
> >>>>>> - do the microservice - dance by wrapping everything together
> >>>>>> including
> >>>>>> CXF
> >>>>>> in a "one-size-fits-all" executable jar, which is a
> >>>>>> wonna-be-spring-boot
> >>>>>> jar but made of karaf
> >>>>>>
> >>>>>> Now some thoughts of mine ...
> >>>>>> I somehow fear you try to mix several problems and try to solve all
> of
> >>>>>> them
> >>>>>> with one go.
> >>>>>> Let's try to analyze those initial problems separately and we might
> >>>>>> find a
> >>>>>> valid approach.
> >>>>>>
> >>>>>> Learning curve of OSGi:
> >>>>>> right now we have different approaches to make it easier with OSGi.
> >>>>>> - Blueprint
> >>>>>> - DS
> >>>>>> - CDI
> >>>>>> - iPojo
> >>>>>> - Felix DependencyManager
> >>>>>>
> >>>>>> Blueprint just tastes to much like spring xml and actually isn't
> state
> >>>>>> of
> >>>>>> the art anymore. You'll get a lot of negative feedback regarding the
> >>>>>> "old-school" xml. It's biggest plus is the Enterprise "features"
> like
> >>>>>> JPA
> >>>>>> and JTA, which isn't covered by any other technique right now
> (unless
> >>>>>> you
> >>>>>> look at non Apache Hosted OSS projects like Amdatu).
> >>>>>>
> >>>>>> Declarative Services, especially the latest R6 looks rather
> promising,
> >>>>>> especially in conjunction with MetaType. But we have specialized
> >>>>>> annotations which again don't actually help with the learning curve.
> >>>>>> Another downside is the missing JPA and JTA Enterprise features.
> >>>>>>
> >>>>>> CDI, we have the Pax-CDI project which has been on the way of being
> >>>>>> the
> >>>>>> reference implementation of the OSGi-CDI spec. Well, we all know how
> >>>>>> that
> >>>>>> turned out. One of its biggest benefits is definitely the easy
> >>>>>> transition
> >>>>>> because of the CDI annotation which help a lot with wiring inside a
> >>>>>> bundle
> >>>>>> and also with extra annotations (@OsgiService) with OSGi-Services.
> CDI
> >>>>>> though still lacks runtime OSGi annotation support for JPA and JTA
> if
> >>>>>> we
> >>>>>> are somehow capable to compensate that, we'll have the required EE
> >>>>>> stack
> >>>>>> at
> >>>>>> hand.
> >>>>>>
> >>>>>> iPojo ... sorry never used
> >>>>>>
> >>>>>> Dependency Manager is a bit more low-level compared to DS but seems
> to
> >>>>>> have
> >>>>>> a nice DSL for easy wiring of Services.
> >>>>>>
> >>>>>> So do we really need another Build-Time-Annotation which generates
> >>>>>> another
> >>>>>> "wiring" plan which is used during runtime (exactly what DS already
> >>>>>> does)?
> >>>>>> Right now I'm not convinced of this. Instead of another generation I
> >>>>>> would
> >>>>>> prefer to use CDI as it is known to work in classic Spring/EE world
> >>>>>> and
> >>>>>> OSGi. Instead we should focus on bringing the full support of
> >>>>>> Enterprise
> >>>>>> style annotations to the OSGi world.
> >>>>>>
> >>>>>>
> >>>>>> I agree. With the current annotations (whatever the ones we use,
> CDI,
> >>>>> DS,
> >>>>> etc):
> >>>>> - they are very low level, and doesn't provide "key turn" annotations
> >>>>> - they don't provide enterprise ready annotations
> >>>>> - depending of the annotations, it's spread on different dependencies
> >>>>> and
> >>>>> packages (not easy for the user)
> >>>>>
> >>>>> Basically, a new developer starts on Karaf, it could be lost: a fair
> >>>>> question is what technology should I use.
> >>>>>
> >>>>>
> >>>>> Use CDI it's a standard annotation and can equally be used for Spring
> >>>>> or
> >>>>>
> >>>> in
> >>>> a modern Enterprise Server.
> >>>>
> >>>>
> >>>>
> >>>> We bring an important flexibility, which is awesome for the advanced
> >>>>
> >>>>> users.
> >>>>>
> >>>>> But this flexibility means it's not easy to start and choose
> >>>>> something: I
> >>>>> have to learn, prepare my pom.xml accordingly, etc.
> >>>>>
> >>>>> The purpose of karaf-boot is not to create new technology, it's just
> to
> >>>>> leverage the existing ones, hide it to the developer, and provide a
> >>>>> quick
> >>>>> and easy starter.
> >>>>>
> >>>>>
> >>>>>
> >>>>> great, and this is the point we need to focus on! Make it easier to
> >>>> develop
> >>>> a Bundle to run on Karaf.
> >>>> That's why I might need to elaborate a bit more about my idea of BOMs.
> >>>> Take for example the spring-boot-log4j-starter bom. If you use that
> one
> >>>> all
> >>>> is included to work with log4j logging, one dependency in your POM,
> >>>> no need to have a Parent.
> >>>> Same for REST, depending on what people would like to use it can be a
> >>>> karaf-boot-cxf-jaxrs-starter bom, which contains the dependencies for
> >>>> working with cxf rest including the feature definition that needs to
> be
> >>>> used by karaf.
> >>>> Here we need something "new", if a feature is present in the POM and
> we
> >>>> have the karaf-maven-plugin in use (the only valid point for a Parent
> >>>> POM
> >>>> to have that as default available) this feature must be used inside
> the
> >>>> generated feature as dependency and the karaf-maven-plugin should
> >>>> generate
> >>>> according to the requirements the dependencies from that feature.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Initial Setup for a new OSGi Bundle Project
> >>>>>>
> >>>>>> Instead of a parent POM I think it would be much more beneficial to
> >>>>>> work
> >>>>>> with a BOM (Bill of Material) for easier development, especially
> when
> >>>>>> working with std. CDI annotations plus some extra PAX-CDI ones.
> Maven
> >>>>>> Archetype are actually good enough to create an initial structure
> for
> >>>>>> a
> >>>>>> maven project.
> >>>>>> The big benefit of the spring-boot approach is to actually have a
> >>>>>> bunch
> >>>>>> of
> >>>>>> 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-activate" the
> >>>>>> pax:run maven plugin to run nicely with a karaf instance, or use it
> as
> >>>>>> foundation for the karaf:run maven plugin.
> >>>>>>
> >>>>>>
> >>>>>> See my previous comment.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> So in the end, do we really need all this?
> >>>>>> I'm not so sure, but we surely need an easier "to use" approach.
> >>>>>> Therefore we should first focus on having easier setup of bundle
> >>>>>> development.
> >>>>>> -> karaf-boot-starter-* BOMs should take care of that
> >>>>>> -> karaf:run should make it easier to have a running container
> >>>>>>
> >>>>>> Do we need new annotations? I can't see that yet.
> >>>>>> Instead we should/could focus on the following:
> >>>>>> a) make sure DS also is capable to work with JPA/JTA and some other
> >>>>>> enterprise annotations
> >>>>>> b) make sure CDI works with runtime JPA/JTA annotation smoothly
> >>>>>> c) provide more demos and archetypes with OSGi and CDI annotations
> >>>>>>
> >>>>>>
> >>>>>> You talk about JPA/JTA and I agree. But don't forget high level
> >>>>> annotations like @jpa(provider = "openjpa", dataSource = "my"),
> @rest,
> >>>>> @soap, @jms, etc.
> >>>>>
> >>>>>
> >>>>> all those "high" level annotations are already solve.
> >>>> Take Jersey or CXF you can use either to solve the @rest or @soap
> >>>> annotations. We don't need extras here
> >>>> We should thoroughly look through the ones that are already available
> >>>> with
> >>>> CDI and make sure we don't re-invent the wheel wrong here.
> >>>>
> >>>>
> >>>>
> >>>> That's why abstract, high level annotations could make sense.
> >>>>>
> >>>>>
> >>>>>
> >>>> only for the ones missing, yes then it might be helpful, but to my
> >>>> understanding this should be the last Story in the backlog to have a
> >>>> quick-and-easy to build environment.
> >>>>
> >>>>
> >>>> regards, Achim
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Regards
> >>>>> JB
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> regards, Achim
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2015-09-10 20:41 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>:
> >>>>>>
> >>>>>> Thanks Milen,
> >>>>>>
> >>>>>>
> >>>>>>> it's an open place to discussion. We just share standpoints and
> >>>>>>> opinions:
> >>>>>>> that's the key part !!!
> >>>>>>>
> >>>>>>> My goal is to give more traction on Karaf by providing easier
> >>>>>>>
> >>>>>>> We all provide valid points, but I think we are not the most setted
> >>>>>>> to
> >>>>>>> argue as we are deeply involved in OSGi and Karaf. The karaf-boot
> >>>>>>> proto
> >>>>>>> came when discussing with new Karaf users, coming from "outside" of
> >>>>>>> OSGi,
> >>>>>>> or people that decided to use spring-boot (even if they like a lot
> >>>>>>> Karaf),
> >>>>>>> just because it's easier. It's hardly frustrating for us as we just
> >>>>>>> need
> >>>>>>> some tooling to provide even more traction. On the container side,
> I
> >>>>>>> think
> >>>>>>> Karaf is already great, and answers all needs. The part where we
> >>>>>>> should
> >>>>>>> improve what we deliver is around developer tooling: easier,
> faster,
> >>>>>>> key
> >>>>>>> turn.
> >>>>>>>
> >>>>>>> If karaf-boot will be a success, I don't know (who knows ? ;)). But
> >>>>>>> anyway, it brings points, questions, and identify some missings in
> >>>>>>> the
> >>>>>>> current picture.
> >>>>>>>
> >>>>>>> My $0.01 ;)
> >>>>>>>
> >>>>>>> Regards
> >>>>>>> JB
> >>>>>>>
> >>>>>>>
> >>>>>>> On 09/10/2015 08:02 PM, Milen Dyankov wrote:
> >>>>>>>
> >>>>>>> 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é <
> >>>>>>>> jb@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é <
> >>>>>>>>>> jb@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é <
> >>>>>>>>>>>> jb@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 <
> >>>>>>>>>>>>>> chris@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
> >>>>>>>>>>>>>>>>>> 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é <
> >>>>>>>>>>>>>>>>>>> jb@nanthrax.net
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 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 your pom.xml with
> >>>>>>>>>>>>>>>>>>>> different
> >>>>>>>>>>>>>>>>>>>> plugin
> >>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> dependency.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Moreover, when you have your artifacts, you have to
> >>>>>>>>>>>>>>>>>>>> prepare
> >>>>>>>>>>>>>>>>>>>> Karaf
> >>>>>>>>>>>>>>>>>>>> container, and deploy those artifacts there. Even if
> >>>>>>>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>> "container"
> >>>>>>>>>>>>>>>>>>>> approach is the most important for me, we can give
> even
> >>>>>>>>>>>>>>>>>>>> more
> >>>>>>>>>>>>>>>>>>>> flexibility by
> >>>>>>>>>>>>>>>>>>>> providing a way to embed and prepare Karaf in a ready
> to
> >>>>>>>>>>>>>>>>>>>> execute
> >>>>>>>>>>>>>>>>>>>> jar/artifact.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>          What is Karaf Boot ?
> >>>>>>>>>>>>>>>>>>>>          --------------------
> >>>>>>>>>>>>>>>>>>>> Karaf Boot provides four components:
> >>>>>>>>>>>>>>>>>>>> * karaf-boot-parent is the Maven parent pom that your
> >>>>>>>>>>>>>>>>>>>> project
> >>>>>>>>>>>>>>>>>>>> just
> >>>>>>>>>>>>>>>>>>>> inherit: that's all ! All plugins, dependencies, etc
> are
> >>>>>>>>>>>>>>>>>>>> described
> >>>>>>>>>>>>>>>>>>>> in this
> >>>>>>>>>>>>>>>>>>>> parent, you even don't have to define packaging as
> >>>>>>>>>>>>>>>>>>>> bundle,
> >>>>>>>>>>>>>>>>>>>> standard
> >>>>>>>>>>>>>>>>>>>> jar is
> >>>>>>>>>>>>>>>>>>>> fine.
> >>>>>>>>>>>>>>>>>>>> * karaf-boot (coming with karaf-boot-parent) provides
> >>>>>>>>>>>>>>>>>>>> annotations
> >>>>>>>>>>>>>>>>>>>> that you
> >>>>>>>>>>>>>>>>>>>> use directly in your business code (like @Bean,
> >>>>>>>>>>>>>>>>>>>> @Service,
> >>>>>>>>>>>>>>>>>>>> @Reference,
> >>>>>>>>>>>>>>>>>>>> @Inject, etc): again, your focus on your code,
> >>>>>>>>>>>>>>>>>>>> karaf-boot
> >>>>>>>>>>>>>>>>>>>> deals
> >>>>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> plumbing.
> >>>>>>>>>>>>>>>>>>>> * karaf-boot-maven-plugin (coming with
> >>>>>>>>>>>>>>>>>>>> karaf-boot-parent)
> >>>>>>>>>>>>>>>>>>>> scan
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> classes
> >>>>>>>>>>>>>>>>>>>> and generate a blueprint XML. For now, I'm using
> >>>>>>>>>>>>>>>>>>>> blueprint
> >>>>>>>>>>>>>>>>>>>> generation
> >>>>>>>>>>>>>>>>>>>> (because we can cover lot of use cases, for instance,
> I
> >>>>>>>>>>>>>>>>>>>> plan
> >>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> provide
> >>>>>>>>>>>>>>>>>>>> @rest annotation that will generate blueprint XML with
> >>>>>>>>>>>>>>>>>>>> cxf
> >>>>>>>>>>>>>>>>>>>> jaxrs
> >>>>>>>>>>>>>>>>>>>> server,
> >>>>>>>>>>>>>>>>>>>> etc).
> >>>>>>>>>>>>>>>>>>>> * karaf-boot-starter is the module providing a
> >>>>>>>>>>>>>>>>>>>> convenient
> >>>>>>>>>>>>>>>>>>>> way
> >>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> embed,
> >>>>>>>>>>>>>>>>>>>> configure and bootstrap Karaf.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Just to illustrate this, let's take a look on the
> >>>>>>>>>>>>>>>>>>>> karaf-boot-sample-simple.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> The pom.xml is really simple:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
> >>>>>>>>>>>>>>>>>>>> <project xmlns="http://maven.apache.org/POM/4.0.0"
> >>>>>>>>>>>>>>>>>>>> xmlns:xsi="
> >>>>>>>>>>>>>>>>>>>> http://www.w3.org/2001/XMLSchema-instance"
> >>>>>>>>>>>>>>>>>>>> xsi:schemaLocation="
> >>>>>>>>>>>>>>>>>>>> http://maven.apache.org/POM/4.0.0
> >>>>>>>>>>>>>>>>>>>> http://maven.apache.org/xsd/maven-4.0.0.xsd">
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>             <modelVersion>4.0.0</modelVersion>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>             <parent>
> >>>>>>>>>>>>>>>>>>>> <groupId>org.apache.karaf.boot</groupId>
> >>>>>>>>>>>>>>>>>>>> <artifactId>karaf-boot-parent</artifactId>
> >>>>>>>>>>>>>>>>>>>>                 <version>1.0.0-SNAPSHOT</version>
> >>>>>>>>>>>>>>>>>>>>             </parent>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> <artifactId>karaf-boot-sample-simple</artifactId>
> >>>>>>>>>>>>>>>>>>>>             <version>1.0.0-SNAPSHOT</version>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> </project>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> You can see, the only thing that the developer has to
> >>>>>>>>>>>>>>>>>>>> do:
> >>>>>>>>>>>>>>>>>>>> define
> >>>>>>>>>>>>>>>>>>>> karaf-boot-parent as parent pom. That's all.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Now, in the code, you have just one bean that we want
> to
> >>>>>>>>>>>>>>>>>>>> run:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> package org.apache.karaf.boot.sample.simple;
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> import org.apache.karaf.boot.Bean;
> >>>>>>>>>>>>>>>>>>>> import org.apache.karaf.boot.Init;
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> @Bean(id = "simple-bean")
> >>>>>>>>>>>>>>>>>>>> public class SimpleBean {
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>             @Init
> >>>>>>>>>>>>>>>>>>>>             public void simple() {
> >>>>>>>>>>>>>>>>>>>>                 System.out.println("Hello world");
> >>>>>>>>>>>>>>>>>>>>             }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> You can see the @Bean and @Init karaf-boot
> annotations.
> >>>>>>>>>>>>>>>>>>>> The
> >>>>>>>>>>>>>>>>>>>> karaf-boot-maven-plugin will generate the blueprint
> >>>>>>>>>>>>>>>>>>>> descriptor
> >>>>>>>>>>>>>>>>>>>> using
> >>>>>>>>>>>>>>>>>>>> this.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>          Current Status
> >>>>>>>>>>>>>>>>>>>>          --------------
> >>>>>>>>>>>>>>>>>>>> I pushed Karaf Boot structure there:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> https://github.com/jbonofre/karaf-boot
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It's a mix of rewrapping of existing code (from aries,
> >>>>>>>>>>>>>>>>>>>> pax-exam,
> >>>>>>>>>>>>>>>>>>>> etc) and
> >>>>>>>>>>>>>>>>>>>> additions.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I created the annotations, I'm now working on the
> >>>>>>>>>>>>>>>>>>>> karaf-boot-maven-plugin
> >>>>>>>>>>>>>>>>>>>> based on Christian's work in aries (I'm actually
> >>>>>>>>>>>>>>>>>>>> scanning
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> boot
> >>>>>>>>>>>>>>>>>>>> annotations now, and generating the XML).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I will push new changes later today and tomorrow.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>          Open Questions
> >>>>>>>>>>>>>>>>>>>>          ---------------
> >>>>>>>>>>>>>>>>>>>> * For now, I would prefer to be 'artifacts' and
> >>>>>>>>>>>>>>>>>>>> 'resources'
> >>>>>>>>>>>>>>>>>>>> generator: I
> >>>>>>>>>>>>>>>>>>>> think it's better than to depend to a feature running
> in
> >>>>>>>>>>>>>>>>>>>> Karaf,
> >>>>>>>>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>> open to discussion.
> >>>>>>>>>>>>>>>>>>>> * I'm now generating blueprint. Probably native OSGi
> or
> >>>>>>>>>>>>>>>>>>>> scr
> >>>>>>>>>>>>>>>>>>>> generation can
> >>>>>>>>>>>>>>>>>>>> make sense.
> >>>>>>>>>>>>>>>>>>>> * I'm generating bundles: thanks to the Karaf4
> features
> >>>>>>>>>>>>>>>>>>>> resolver,
> >>>>>>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> bundles provide requirements/capabilities metadata, I
> >>>>>>>>>>>>>>>>>>>> think
> >>>>>>>>>>>>>>>>>>>> it's a
> >>>>>>>>>>>>>>>>>>>> good
> >>>>>>>>>>>>>>>>>>>> start. However, maybe it's worth to be able to create
> >>>>>>>>>>>>>>>>>>>> features,
> >>>>>>>>>>>>>>>>>>>> kar,
> >>>>>>>>>>>>>>>>>>>> profile.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Thoughts ?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>>>>> JB
> >>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>> Jean-Baptiste Onofré
> >>>>>>>>>>>>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>>>>>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>>>>>>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Jean-Baptiste Onofré
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Jean-Baptiste Onofré
> >>>>>>>>>>>>
> >>>>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>
> >>>>>>>>>> Jean-Baptiste Onofré
> >>>>>>>>>>
> >>>>>>>>> jbonofre@apache.org
> >>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> --
> >>>>>>>>
> >>>>>>>> Jean-Baptiste Onofré
> >>>>>>> jbonofre@apache.org
> >>>>>>> http://blog.nanthrax.net
> >>>>>>> Talend - http://www.talend.com
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>> Jean-Baptiste Onofré
> >>>>> jbonofre@apache.org
> >>>>> http://blog.nanthrax.net
> >>>>> Talend - http://www.talend.com
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>> Jean-Baptiste Onofré
> >>> jbonofre@apache.org
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >>>
> >>>
> >>>
> >>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
> >
> >
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>



-- 
http://about.me/milen

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