karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup
Date Wed, 16 Dec 2015 15:38:37 GMT
I see your point about starter. maybe just karaf-boot ? So we can have 
karaf-boot, karaf-boot-core, and karaf-boot-parent ?

For the osgi.bnd, if the karaf-boot (aka 
karaf-boot-starter/karaf-boot-api) can provide a default one, it's fine 
for me.

We will provide an archetype, but anyway, the purpose of karaf-boot is 
also to be able to start very quickly: so a very basic pom.xml just 
defining karaf-boot-parent should be enough.


On 12/16/2015 04:30 PM, Christian Schneider wrote:
> I think the name starter is misleading. When I read it first I thought
> it was some way to boot up the application
> but after all it is just a name.
> About the osgi.bnd. Currently you have to provide it but this can
> probably be changed either in the maven-bundle-plugin or in bnd itself.
> I would also prefer to just create it if you really want to tweak
> something.
> On the other hand it is not a big problem as we will most probably
> provide a archetype that contains it anyway. For the archetype I would
> even provide an empty osgi.bnd as it is easier to edit it than to know
> that you have to create a file with this name.
> Christian
> On 16.12.2015 16:22, Jean-Baptiste Onofré wrote:
>> Hi Christian,
>> thanks for this !
>> karaf-boot-api sounds like the BOM that I proposed in
>> karaf-boot-starter. It sounds good to me, but maybe the
>> karaf-boot-starter name is better than API (or it makes sense if we
>> add some annotations/extensions).
>> For the parent pom, as already said on IRC, it was my first intention
>> and we discussed on the mailing list. Achim convinced me to go on a
>> less intrusive approach. The only drawback with a parent POM is that
>> users have to define it in their POM. At the end, I think it's not a
>> big deal and it makes sense as it can be the parent pom of the user
>> parent pom ;)
>> One of the key purpose of the karaf-boot is to be very very very (and
>> 10x very ;)) easy to start with and use. So, if parent pom is easier,
>> I'm OK with that.
>> For the "external" osgi.bnd, it's also fine for me as soon as the user
>> doesn't have to provide one by default (again, simple). If the user
>> wants to tweak, he can provide a custom osgi.bnd.
>> I like the idea of the annotations for the feature, it's exactly
>> aligned with karaf-boot ideas. Big +1 for this.
>> Thanks !
>> Regards
>> JB
>> On 12/16/2015 03:54 PM, Christian Schneider wrote:
>>> I found a bit of time to work on the karaf-boot effort JB initiated at
>>> last.
>>> I adapted the tasklist example from aries jpa for karaf boot.
>>> You can find the result in a branch:
>>> https://github.com/jbonofre/karaf-boot/tree/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist
>>> The example contains a JPA persistence unit, a TaskService which
>>> implements a JPA based repository and a servlet using the
>>> http-whiteboard.
>>> I did a little different approach to what JB used with the starter pom
>>> and the karaf boot plugin.
>>> - I created a karaf-boot-api with the same idea like the enroute
>>> base-api. It is a pom that contains all APIs you will likely need for
>>> starting a real business application.
>>> This is the only dependency of the sample. So people starting with this
>>> pom will be able to start coding business code without thinking about
>>> the necessary libs.
>>> I also put some test dependencies there like slf4j and junit to help
>>> people with creating tests.
>>> - I also created a karaf-boot-parent as a parent for all karaf-boot
>>> samples. It sets up all the necessary plugins like maven-bundle-plugin
>>> or compiler-plugin. This is different
>>> from JBs approach of using a karaf-boot-plugin. I think the parent
>>> approach is better as it is easier to understand and extend. People can
>>> look into the parent to see what it does
>>> and when their project grows they can copy/paste the useful parts into
>>> their own parent.
>>> - I externalized the osgi settings using an osgi.bnd file. This allows
>>> to easily customize the OSGi settings without redefining the
>>> maven-bundle-plugin. It is also compatible to bndtools 3.1
>>> as far as I can tell. So it should make it easier to work on the code
>>> using bndtools.
>>> Apart from that I created a small stub for defining a feature using
>>> annotations:
>>> This is how it could look like:
>>> https://github.com/jbonofre/karaf-boot/blob/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist/src/main/java/org/apache/aries/jpa/example/tasklist/feature/TasklistFeature.java
>>> @Feature(
>>>           name="tasklist",
>>>           version="1.0.0",
>>>           features = {"jpa", "transaction", "hibernate", "http"},
>>>           configFile = "org.ops4j.datasource-tasklist.cfg"
>>> )
>>> The idea is to add this annotation to any class and then let a yet to be
>>> written karaf-feature plugin create a feature.xml from it.
>>> The result would be a feature with the given name and dependencies. The
>>> feature would by default also contain the current bundle. So this would
>>> allow to start with one maven project that contains everything to easily
>>> get a small business application running.
>>> So some things left to do are:
>>> - plugin for the feature creation
>>> - plugin for packaging a self contained karaf including the application
>>> and all deps and config. More or less this can be done with the current
>>> karaf-maven-plugin but we need to tune it so it needs less
>>> configuration.
>>> - plugin for running the application from the command line
>>> - artifact for creating new karaf-boot applications
>>> - documentation for the transition to a larger multi project setup with
>>> its own parent. Maybe a separate artifact would also do, not sure
>>> - Integration with bndtools to give the user a nicer IDE for OSGi than
>>> plain eclipse
>>> I would be happy about any feedback.
>>> Christian

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message