Hi,
Samples should be part of Karaf itself (the problem of "outside"
tutorials is that it's hard to maintain up to date and to test with
every release).
So, that's exactly the purpose of the new developer guide: provide ready
to go samples, embedded directly in Karaf, that we test in the Karaf
itests. Like this, we are "forced" to keep it up to date.
If samples/tutorials/demos (whatever the name we give) are good, it
means that the developers "duplicates" the sample (copy/paste) and adapt
to their needs. It's good, but it's some "effort". Moreover, the samples
will be quite "low level".
So, we all agree: definitely, we have to provide samples in the Karaf
codebase, and it's already in the way with the new Karaf developer guide.
So, compare to such samples, karaf-boot would bring: a BoM (basically a
Maven dependency) providing all the dependencies version, etc, and some
more abstract/high level annotations or components.
Regards
JB
On 09/14/2015 05:03 PM, cuggbh wrote:
It's only 6 or 7 years I am a Java developer. I am working with Karaf for 5
years now (through fuse, servicemix, talend or directly).
If I resume shortly what I understood from JB's first idea it's a set of
annotations to hide OSGi configuration to the developer to bring popularity.
I think it would work.
Would I personally use it or would I use it as an argument to propose Karaf?
I don't think I would. For the reasons Achim and Christian gave.
I will read about it because I don't get it when you talk about "BOM" but I
think that examples/maven archetypes in the github of Karaf maintained with
the different versions and completed with new features as version goes along
would do the job. Just as the tutorials Christian wrote. What I feel is
needed is more of those examples and a versioning of them. If they are in
the github (it could be an other project but versioned as karaf) you can get
easily the examples working for the version of Karaf you use by checking out
a tag. I think that those examples should be also linked to the OSGi
framework version to have the information about compatibility on an other
container, but it's perhaps not the subject here.
Why I think this way is because when I struggle on some configurations, and
I don't want to read all the documentations because I need it to work fast,
one of my first step is too check github to see if someone already did it,
if I had only one repo to visit and know that the configurations I look at
have integration tests I would earn a lot of time.
I think people have to know what happens when they do OSGi. If you get
developers who come to use it because you leverage it, they don't have to
dig in it and so don't understand the true advantages wouldn't they leave
for an other "new" technology with a short learning curve as fast as they
join?
It looks perhaps dumb and I perhaps misunderstood the whole thing but I felt
you needed some different thoughts. So I tried to give mine ;)
--
View this message in context:
http://karaf.922171.n3.nabble.com/DISCUSSION-Karaf-Boot-tp4042437p4042572.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
