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 07:30:17 GMT
I'm with you guys. The first target of karaf-boot is not microservice 
(microservice is one kind of artifact that karaf-boot can provide): the 
real purpose of karaf-boot is to provide easy way to create 
artifacts/applications, using annotations.

Regards
JB

On 09/11/2015 09:26 AM, Christian Schneider wrote:
> Hi Achim,
>
> very good overview of the problems users face and I also agree with your
> proposed solutions.
> Just for pax cdi I think we are not yet there so I would go with
> blueprint generation from CDI annotations for now and switch to
> proper pax cdi when it is fully working.
>
> On top I would add that I have the feeling that springsource more or
> less hyped microservices because they know spring does not scale!
>
> The bigger a spring application grows the more you see that it does not
> provide real modularization.
> 1. All of the dependencies have to be hammered into a flat classpath.
> This works or an astonishingly long time but at some point
> in the growth of a project it gets harder and harder.
> 2. The single spring context. In the end the whole application runs on
> one merged spring contex. All the settings done in the small
> contexts scattered around the project artifacts have to work together in
> the big context created at runtime.
> 3. No enforcement of visibility rules. You can define an API but you
> also have access to all the impls and developers tend to use them
> when the time pressure comes.
> 4. Static setup. Spring has to boot up all beans in the correct order.
> 5. They tried with OSGi but I think they realized that making spring
> fully OSGi ready is too much work
>
> All this leads to people thinking that an application needs to be split
> into microservices to make the above problems smaller.
> Only later they find that implementing microservices is pretty hard. The
> biggest problem is that they may not share a database. So you have
> to invent a lot of additonal logic to keep the different databases in
> the same state. Additionally there is security and monitoring which is
> also pretty much unsolved in microservices.
>
> If you compare this to a proper OSGi application then the need for the
> spring style microservices is almost not there. Instead you write small
> modules with a clearly defined API and boundaries and OSGi services to
> communicate. If you need to cross server boundaries then OSGi remote
> services allow
> to extend the OSGi services model to a larger environment.
>
> So I would argue that the microservices hype will not live to its
> promises. People will realize that OSGi provides better solutions with
> less overhead than microservices.
> This will take some time of course and we will need to make sure to not
> loose too many people to spring boot in the mean time.
>
> So what we need is a nice way to create microservices in karaf like you
> described. Additionally we should also allow people to just deploy a
> normal OSGi
> application in a simple way like you would for a microservice. So I
> think we need to make sure that karaf boot not only works for single
> projects but also
> for whole applications in form of a set of bundles. This will allow
> people to transition away from pure microservices when they realize they
> are not as good as they think
> while still keeping a lot of the benefits of the small and simple
> deployment unit.
>
> Christian
>
> Am 10.09.2015 um 23:58 schrieb Achim Nierbeck:
>> 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.
>>
>>
>> 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.
>>
>>
>> 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.
>>
>>
>> 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.
>>
>>
>>
>> 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
>>
>>
>> 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

Mime
View raw message