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>
