karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [DISCUSSION] Karaf Boot
Date Fri, 11 Sep 2015 08:21:09 GMT
Great feedback Milen ! and I agree with your points.

My feeling is the same:
1/ Karaf is an awesome container, for sure ;)
2/ maybe developers will be disappointed by "monolithic" approaches, but 
for now, there are more and more devs going to spring-boot, dropwizard, 
or whatever. The only reason is: "it's easy".
3/ my "frustration" comes from the fact that we know Karaf/OSGi values, 
but honestly, it's not easy to dev on it for beginners.

So, I don't want to provide the same thing as spring-boot: I just try to 
figure out a way to simplify first steps for new developers on Karaf ;)

Regards
JB

On 09/11/2015 10:13 AM, Milen Dyankov wrote:
> 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
>>
>
>
>

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

Mime
View raw message