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 09:52:49 GMT
Yup, and it's where karaf-boot is interesting.

Let me move forward by providing a serie of karaf-boot-starter* (as BoM) 
and corresponding samples.
I gonna enhance the annotations too, providing more higher level.

Regards
JB

On 09/11/2015 11:28 AM, Achim Nierbeck wrote:
> Hey guys,
>
> yes we all are walking the same path.
> I can't tell you how much dislike I have right now for that micro-monolith
> hype everyone is following like a Lemming!
> And I fully agree with what Milen talked about. It's more to the point that
> a lot of people that used to be very OSGi friendly
> turned away and now walk the same path. One of them is a colleague of mine.
> We need more talks about how awesome Karaf and OSGi is, but on the other
> side we need to face those "dislikes" and need to take those as a challenge
> for improvement.
>
> Right now I'd say the most important way of achieving this is to make it
> easier to start with.
> And this is the point we already agreed on with the *-starter BOMs.
> Lust but not least we need to get louder ... and this is where we need the
> community of users to actually publish blogs, make noise to let people know
> how good the software is that it uses. Also for those "micorservice"
> use-cases :D
>
> regards, Achim
>
>
> 2015-09-11 10:21 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>:
>
>> 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
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>
>

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



Mime
View raw message