karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <ben...@basistech.com>
Subject Re: [DISCUSSION] Karaf Boot
Date Thu, 10 Sep 2015 18:05:32 GMT
I've just built a small armada of DS services in Karaf.

I didn't find it too terrible (except for learning DS at all).

A typical service is one bundle + its dependencies. So, for each one,
I make a Maven module that is of <packaging/> bundle, and then I add
an execution of the feature generator. I use DS annotations to use and
register services. If I had SCR>1.8.2, I'd be using .cfg files to do
cardinality constraints.

 Now, I'm not interested in JPA and JTA, so I don't have exposure to
whatever problems those pose.

I could imagine another lifecycle in the karaf-maven-plugin that would
combine the bundle-ing and the feature-ing. I hit some aspects of the
feature generator that bothered me. But I didn't see any problems that
correspond to a reason to want to use any new annotations.


On Thu, Sep 10, 2015 at 1:44 PM, Jean-Baptiste Onofré <jb@nanthrax.net> wrote:
> I fully agree: my concern about SCR is:
> 1/ it's very OSGi oriented and low level
> 2/ it's not extendable easily
>
> That's why I would prefer to abstract with a new top annotations (providing
> advanced high level features like security, jpa, etc).
>
> Regards
> JB
>
>
> On 09/10/2015 07:33 PM, Christian Schneider wrote:
>>
>> Providing jpa and jta annotations for SCR would be great. I think the
>> big problem with scr is that it does not have a plugin model.
>> So while it might be possible to add jpa / jta processing around the
>> service it might be difficult to provide it in a way that it can be
>> combined with other annotations
>> from different sources. Like e.g. security. Unfortunately Peter Kriens
>> was not very open when I asked him about such a model. Do you have an
>> idea how to make it work?
>>
>> Another question of course would be where to put that code.
>> I would tend to put such code maybe in felix near the scr impl and the
>> maven bundle plugin as it is quite related.
>>
>> Christian
>>
>> Am 10.09.2015 um 19:22 schrieb Jean-Baptiste Onofré:
>>>
>>> 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

Mime
View raw message