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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply via email to