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
On 12/17/2015 10:22 AM, Serge Huber wrote:
Hi guys,
Sorry for jumping in like this but I’m also very interested in the Karaf boot
project, although I unfortunately am so busy with other things I can’t
contribute much code to it for the moment.
On 17 déc. 2015, at 09:11, Christian Schneider <[email protected]> wrote:
BOM and pom unfortunately both do not provide any way to add plugins to the
user code.
This is what I use the parent for. You are right that it does not provide much
flexibility but I think it is better than
a monolithic karaf boot plugin that calls all other necessary plugins. One
reason is that a parent is more transparent.
So the user can look into the parent and easily understand what it does. A
parent is also a nice template
for the more advanced user to create his own parent.
The biggest issue I see with a parent POM is that in our experience with
integrators, a lot of them that already use Maven have an “imposed”
company-wide parent POM, and therefore could not imagine starting a project
with anything else than their own parent POM.
In the “boot” world, a lot of projects are now even using shell scripts that
will install all the requirements. One of the best ones I’ve seen is the
Homebrew project for Mac OS X (http://brew.sh) that makes it incredibly simple
to get started. Maybe we could even install Maven using a shell script ? Or
maybe I’m pushing this idea a bit too far and assuming Maven is installed is an
acceptable first step.
One thing that would be really cool also would be a way to “transform” existing
project to be Karaf boot compatible. Let’s imagine I have a legacy WAR project.
Using a plugin or a shell script I could quickly transform it to be packaged as
a Karaf custom distribution, making it very easy to provide a runnable
standalone application.
In the same way we could also look at packaging a JRE so that people wouldn’t
even need anything else to run it. Of course this would require having platform
specific distributions, but that’s not a huge problem to overcome (apart from
manpower to achieve this of course).
I dream of a world where people can “switch over” not only “get started” with
Karaf so that we can drive adoption as easily as possible.
cheers,
Serge…
On 17.12.2015 01:03, Achim Nierbeck wrote:
Hi,
once more, I still think and I think I convinced JB on this point, Parent
POMs are a bad way to start with just to create your own application, this
is where BOMs (Bill Of Material) plays in much more nicely. Especially if
you want to combine different aspects. Like DS plus Web for example, now
you would need two Parents, which isn't possible.
Now regarding Provisioning and features. I wouldn't go with features, cause
the tend to be
bloated in comparison to the small footprint we want to have with
karaf-boot.
That's why I proposed long time ago to use profiles.
My first steps no that can be found at the project in JBs GitHub account.
It's the profiles branch. [1]
In this we'll have the profiles attached to the BOMs and therefore it could
be extracted through a specialized Mojo (already worked on that) to merge
all those profiles into one to create a custom Karaf on the fly.
regards, Achim
[1] - https://github.com/jbonofre/karaf-boot/tree/profiles
2015-12-16 22:33 GMT+01:00 Christian Schneider <[email protected]>:
Probably not .. I just did not yet change it :-)
Will fix it.
Christian
2015-12-16 22:03 GMT+01:00 Tim Jones <[email protected]>:
Hi Christian, looks good, one minor, is the package name supposed to be
org.apache.aries.jpa.example.tasklist.*blueprint*.impl?Tim
--
View this message in context:
http://karaf.922171.n3.nabble.com/karaf-boot-Added-a-DS-sample-with-Servlet-and-JPA-and-slightly-different-setup-tp4044335p4044358.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
--
--
Christian Schneider
http://www.liquid-reality.de
<
https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de
Open Source Architect
http://www.talend.com
<
https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com
--
Christian Schneider
http://www.liquid-reality.de <http://www.liquid-reality.de/>
Open Source Architect
http://www.talend.com <http://www.talend.com/>
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
