On 11-02-17 01:25 AM, Bengt Rodehav wrote:
Jamie,
Yes, I also recommend using features for provisioning bundles (where
possible). However, it seems like you have the same problem like me
when it comes to creating a custom Karaf server. I find myself having
to modify a lot of files in the Karaf distribution every time I
upgrade to a new release of Karaf (startup.properties is one of them).
startup.properties and my pom.xml are the two that I have to change.. I
haven't customized any of the other files (although it looks like I'll
be customizing the features.cfg file now) so they haven't been an
issue. I don't think that in my case that's avoidable (for now) though
: my custom build has the somewhat unfortunate side effect of having a
different deploy structure, for instance karaf 2.1.3 has
system/org/apache/aries/blueprint/org.apache.aries.blueprint/0.2-incubating/org.apache.aries.blueprint-0.2-incubating.jar
where as mine would be
system/org.apache.aries.blueprint/org.apache.aries.blueprint/0.2-incubating/org.apache.aries.blueprint-0.2-incubating.jar
because my assembly bin file uses group id and artifact id. I have it
this way because it makes for a very simple bin file, and overriding the
convention makes it a much bigger creature, but I may change it in
future to help make upgrades easier. For now though, ease of
comprehension in bringing new developers on board is more important than
how much work I need to do behind the scenes for transitions. so a very
simple assembly bin (and other files also being simple) is important.
I started a thread here about a week ago on this topic. You can read
it here:
http://mail-archives.apache.org/mod_mbox/karaf-user/201102.mbox/browser
It started on the user list but continued on the dev list, here:
http://mail-archives.apache.org/mod_mbox/karaf-dev/201102.mbox/browser
Seems like good ideas are flowing. JB mentioned that some JIRA posts
related to the thread will be added at some point, I look forward to
reading them.
I've also been trying to use custom.properties but did not succeed. I
think the goal should be that all customisation of Karaf should be
done outside of Karaf - i e one should not have to modify files in the
Karaf distribution. For that reason extension points are needed
similar to what (I think) the intention with custom.properties is.
I join Andreas in agreeing :)
-Jamie
