For me the main purpose of karaf boot in unchanged form is to allow
people to easily create small proof of concepts.
In this stage it normally is no issue that you do not use the company
parent pom. You can start easily with karaf boot and bring your poc to a
level where management decides to use karaf.
Then at some point you need to transition to a regular project. So you
can copy the karaf boot parent, edit it to include your company parent
and other changes you might need and use it for your project(s).
This transition phase will also happen when you use the blackbox
karaf-boot plugin but then it will be a lot harder to adapt it to your
needs.
Another thing we need to look at is the transition from a single module
project to a multi module project. I think it is really great to let
people start with a single module/project but to leverage OSGi people
will want to build multi module projects at some point. This will either
happen during the transition from poc to a regular project or even
earlier. So I think we also need to make sure that multi module projects
can be built easily. For this case I think
it is natural that the set of modules that form you application will
have their own parent pom (that of course might depend on a company parent).
Christian
On 17.12.2015 10:51, Jean-Baptiste Onofré wrote:
Hi Serge,
It's what I meant by "intrusive": sometime we have to use a company
wide parent pom, no choice. So we can't force the usage of a
karaf-boot parent IMHO.
That's why, after the earlier discussions on the mailing list, I did:
- a set of karaf-boot-starter, providing dependencies depending what
you need (rest, jpa, shell, etc). They act as BoM and users just have
to define in the dependencies set (see the karaf-boot-samples).
- as a BoM doesn't bring plugin (only dependencies), and to simplify
the build/bootstrapping at maximum, I created the
karaf-boot-maven-plugin. This plugin is responsible of scanning the
starters, scanning the sources, and depending of those, build and
possibly bootstrap the project by wrapping other plugins.
So, we are really in a kind of black box, where processes are hidden:
and it's one of karaf-boot main purpose. However, I got Christian's
point: he's more in the way to not hide as he expects later people
won't use karaf-boot to a more advanced/expert way. So, at that time,
people can "duplicate" what we have in a parent-pom.
That's why maybe we can provide both:
- I honestly think that "hide way" will match in 80% of the cases,
where people wants to focus on business code and don't care about the
plumbing. It's the feedback that I got discussing with different
people like Serge, and others (from different background, business,
company).
- However, at least by documentation or parent pom, we have to provide
a way to karaf-boot users to use a very advanced/expert way. I like
Christian's idea to use an extender, it makes sense in some use case.
The profile or feature generation by annotation or starter scanning is
also interesting IMHO.
My $0.02 ;)
Regards
JB
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
