Hi Milen,
First, let's take spring-starter-embed out of the picture (it's the part
to embed Karaf and applications in a big jar file ready to execute).
Let's focus on the pure dev path.
Let me take two use cases:
1. Very Simple
In this example, you have one interface, one bean (business code), you
want to expose the bean as a service.
You can:
1.1. Use native OSGi:
- Effort: in addition of the business code, you have to write the
Activator, knowing the "OSGi API", dealing with the service registration
lifecycle. In addition, you have to prepare a Maven pom.xml with bundle
as packaging and dealing with maven-bundle-plugin.
- Workload: I evaluate that your business code is only 50% of the
workload, as you need to write the Activator and the pom.
1.2. Use blueprint:
- Effort: in addition of the business code, you have to write
OSGI-INF/blueprint/your.xml blueprint descriptor. So, instead of the
"OSGi API", you have to know the blueprint syntax. The pom.xml is the
same as in 1.1.
- Workload: I evaluate that your business code is 55-60% of the
workload. You need to write the blueprint XML, but if you have multiple
beans it's probably easier than an activator (not sure ;)).
1.3. Use scr annotations:
- Effort: you use scr annotations directly in your bean (@Component,
@Activate, etc). The pom.xml is the same as the maven-bundle-plugin
generate the components XML for you. It requires that your know the SCR
annotations (low level), and add required dependencies in the pom.xml
- Workload: your business code is 80% of the workload, 20% is about the
annotations and pom.xml
1.4. Use karaf-boot:
- Effort: you have the choice between the karaf-boot annotations (high
level) or the scr annotations (low level). In the pom.xml, you just have
to add a dependency to karaf-boot-starter (for karaf-boot annotations)
or karaf-boot-starter-scr (for scr annotations). The karaf-boot-starter*
are BoM describing all that you need, including scr dependencies.
- Workload: your business code is 85% of the workload, 15% about the
annotations and pom.xml. The gap of 5% compared to 1.3 is due to the
usage of karaf-boot-starter* that brings all the dependencies for you
(you don't have to figure out all dependencies set, etc in your pom.xml).
So, on this first use case, scr and karaf-good are probably the easiest
way to go.
2. JPA (the same can be applied to JTA, REST, SOAP, etc)
In this example, you want to expose a service dealing with JPA/JTA.
You have an @Entity POJO, and a DAO using JPA and the entity.
You can:
2.1. Use native OSGi:
- Effort: you have to create the Activator. The Activator can create an
EntityManager or retrieve one as a service. You have to create the
META-INF/persistence.xml. You have to call the maven-budle-plugin in
your pom.xml, without forget to define the <META-INF/> element.
- Workload: your business code is about 40% of the workload, bunch of
code has to be written in the activator. You also have to create the
META-INF/persistence.xml.
2.2. Use blueprint:
- Effort: with latest Aries Blueprint versions, you have to create a
blueprint XML with <jpa:enable/> element and defining beans/services.
You still have to write the persistence.xml and update the pom.xml
- Workload: your business code is about 60% of the workload
2.2. Use SCR:
Unfortunately, we don't have direct support of JPA (or other enterprise
stuff) in SCR.
2.3. Use karaf-boot:
- Effort: your just add @jpa(provider="openjpa",dataSource="my") on the
your DAO class. karaf-boot will create the persistence.xml for you (and
the blueprint descriptor for now).
- Workload: your business code is 95% of the workload, 5% is just to
define karaf-boot-starter-jpa dependency in your pom.xml.
For instance, for rest service, it could be the same: right now you have
to write a blueprint xml with <jaxrs:server/> element (using CXF-RS).
karaf-boot-starter-rest will do that for you, using the @rest high level
annotation that you can define on your rest class (where you already
have the @Path, @GET, etc jax-rs annotations).
By the way, for all, on the other hand, in the mean time where I'm
working on karaf-boot, I'm also enhancing the Karaf developer guide,
with samples.
@Milen, please, don't hesitate to share your thoughts !
Regards
JB
On 09/12/2015 09:13 PM, Milen Dyankov wrote:
Can someone please point me to an example use case that is "easy" to do
with SpringBoot but "hard" with Karaf? Some of you mentioned you know
people that have concidered Karaf but went with SpringBoot because it's
easier. Is there anything more concrete than the subjective "easy" vs.
"hard" judgment?
12 wrz 2015 20:52 "Jean-Baptiste Onofré" <[email protected]> napisał(a):
Documentation is always good, but more than reading the documentation,
people may want something ready to go with minimal documentation.
I'm working on huge refactoring of Karaf developer guide, providing
documentation about scr/ds, cdi, jpa, jta, etc. It's time consuming but a
must have. So it means users will spend so much time just to
mimic/duplication what's describe in the documentation, ready a long long
one.
The goal is to simplify the artifact with minimal documentation.
For me, it's different approach: something easy and quick, on the other
hand detailed documentation for advanced users.
Regards
JB
On 09/12/2015 07:51 PM, garyhodgson wrote:
Hi JB,
A set of BoMs and archetypes, together with the corresponding
documentation, would certainly be a great benefit to the project.
Particularly if, in the process, it helps resolve outstanding issues such
as missing profile documentation, the karaf:run functionality, the
developer documentation, etc. My fear is that the talk of mimicking
spring-boot, with @jpa annotations and such, would turn into a time and
resource black hole.
To your statement: "I bet your spent lot of time and efforts on choosing
the right programming model, setup your modules, etc." - this is correct to
some extent, but largely due to incomplete documentation about the plethora
of options available. The Enterprise sections of the user guide is
woefully inadequate in this regard. In these cases a Bom or Archetype
would give another useful example, but it wouldn't take the place of some
well written, and well-maintained documentation about the various
technologies available. Case in point, it was Christian's blog posts that
mainly got me up to speed with JPA etc.
Regards,
Gary
On 12 September 2015 at 18:22, jbonofre [via Karaf] <
[email protected]> wrote:
Hi Gary,
Your point about the Jira is fair, but this remark applies to any
project. My point is that unfortunately, all our efforts are nothing if
we don't provide tooling for developer users. It's really frustrating to
get feedback like "Karaf is awesome, but I prefer other (like
spring-boot) just because is simpler to start with".
My goal is not the Karaf starter/bootstrapper first (by the way, I
already have karaf:run ready on one of my branches), it's first a set of
BoM, samples and documentation to quickly start "key turn" artifacts.
Actually, part of karaf-boot came when I work (and still working ;)) on
the Karaf developer guide.
I bet your spent lot of time and efforts on choosing the right
programming model, setup your modules, etc. That's my concern: it can be
long and sometime complex.
Regards
JB
On 09/12/2015 02:23 PM, garyhodgson wrote:
Hi,
I thought I would add briefly to the discussion my opinion as a relative
newcomer to OSGi and Karaf, who is evaluating introducing it as part of
our
architecture at $WORK.
Whilst I can see the attraction of working on some kind of karaf-boot
offering, my concern is that it would take resources away from other
less
exciting, yet more important, tasks such as documentation, ensuring
stability and bug fixing.
Although it's probably not a popular opinion, I would say that working
through some of the (currently) 559 unresolved issues in Jira should
take
priority over any new endeavour.
The flexible nature of OSGi and Karaf means that any karaf-boot solution
would have to be either (a) very opinionated as to what technologies to
use
(DS, BP, etc), and therefore have a narrow target audience; or (b)
highly
configurable and consequently almost as complex as implementing a
solution
from scratch (I think OSGiliath exhibits this trend to some extent).
To introduce Karaf, et al at $WORK, I have ended up creating a
multi-module
Maven project with a features module, a custom Karaf module, a business
module with CDI/JPA etc. All of which can be made running quite easily
(and
could be further enhanced by creating a "karaf:run" type command,which
sounds like what "karaf-boot-starter" is expected to do.). Having a
"quick
start" archetype which sets this up would of course be useful,
particularly
for those beginning with Karaf, but any realistic project will soon have
to
change or replace parts to suit their own requirements. In my opinion,
having more documentation would provide more value, quicker.
Best regards,
Gary
--
View this message in context:
http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf-Boot-tp4042437p4042534.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
--
Jean-Baptiste Onofré
[hidden email] <http:///user/SendEmail.jtp?type=node&node=4042537&i=0>
http://blog.nanthrax.net
Talend - http://www.talend.com
------------------------------
If you reply to this email, your message will be added to the discussion
below:
http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf-Boot-tp4042437p4042537.html
To unsubscribe from [DISCUSSION] Karaf Boot, click here
<
http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4042437&code=Y29udGFjdEBnYXJ5aG9kZ3Nvbi5jb218NDA0MjQzN3w4NTU3ODE3OA==
.
NAML
<
http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
--
View this message in context:
http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf-Boot-tp4042437p4042538.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
