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 06:50:21 GMT
Hi Achim,

my point is that you are a veteran on different technologies, that you 
know ;)

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

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


Mime
View raw message