I would rename/refactore the standard feature which currently gather:
<details>Standard providing core Karaf features</details>
<bundle
start-level="30">mvn:org.apache.karaf.features/org.apache.karaf.features.command/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.features/org.apache.karaf.features.management/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.instance/org.apache.karaf.instance.core/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.shell/org.apache.karaf.shell.console/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.modules/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.config/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.instance/org.apache.karaf.instance.command/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.features/org.apache.karaf.features.core/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.instance/org.apache.karaf.instance.management/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.diagnostic/org.apache.karaf.diagnostic.core/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.diagnostic/org.apache.karaf.diagnostic.common/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.diagnostic/org.apache.karaf.diagnostic.command/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.diagnostic/org.apache.karaf.diagnostic.management/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.shell/org.apache.karaf.shell.log/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.management.mbeans/org.apache.karaf.management.mbeans.log/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.shell/org.apache.karaf.shell.dev/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.management.mbeans/org.apache.karaf.management.mbeans.dev/3.0.0-SNAPSHOT</bundle>
<bundle
start-level="30">mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.command/3.0.0-SNAPSHOT</bundle>
WDYT ?
Regards
JB
On 03/26/2012 11:37 AM, Jean-Baptiste Onofré wrote:
It sounds good to me.
We can have:
- startup feature used only to create the startup.properties
- framework feature gathering "core" component like commands, etc
Regards
JB
On 03/24/2012 08:44 PM, Christian Schneider wrote:
While it is no big issue for you to create a custom distribution I am
quite sure that for 99% of users it is and they will not even try.
So my argument is that people rather will start with one of the default
karaf distros. As on the other hand users will quite for sure need more
bundles than those in the distro - at the very least their own bundles.
So they have two options. They can either deploy to the deploy folder or
they use maven.
For those users that use maven the network distro is ideal. They will
load bundles from their maven repo anyway so why not load as many as
possible and make the distro as small as possible. As the bundles will
be cached anyway the performance effect is only relevant on first
install. So the network distro is an ideal way for maven users to use
karaf imho. Especially I think it is ideal for all developers as they
will have either a maven repo or internet access quite for sure.
For distribution creation the network distro may also be intersting. We
could provide commands to build a distro:
Like distro:create which creates a distro that contains all bundles from
all active feature urls and all current config. So the developer could
work with the network distro to have a small install and create a custom
distro whenever needed.
Christian
Am 24.03.2012 19:19, schrieb Jean-Baptiste Onofré:
Around the same topic, from a general perspective, I don't think it's
a good idea to provide too thin distribution.
I mean that Karaf is a container, and as a container, it provides
standard features, and the end-user accepts that (as an end-user
accepts to use JEE application server even if he doesn't use all
features provided by the app server).
The key point is to give the ability to the end user to create a
custom container starting from a standard distribution. That's why:
- I'm always agree to provide simple and useful way to create custom
distribution (Maven plugins, etc), etc.
- I'm most of the time against to provide new distributions. We should
have ONE standard distribution. The minimal (or framework) is
interesting to create custom distribution (so used with
karaf-maven-plugin) but it doesn't make sense on its own (nobody will
start a "production" container with minimal, an user will always
create its own distribution on top of minimal).
If the user wants really "home made" container, he can start from the
framework and create its own, specific need oriented.
Regards
JB
On 03/24/2012 10:58 AM, Christian Schneider wrote:
Hi all,
the framework feature is used to create the startup.properties. If I
understood this correctly then
these bundles are loaded in a special way (not with pax-url). To be
able
to create a smaller minimal distro (or an even small "network" distro)
I think it makes sense to have as few bundles in there as possible.
So what has to be in there as a bare minimum. I think we need at least
the feature-core and pax-url with their dependencies.
Ist that correct? If we makes these independent of blueprint then I
think we can even skip the whole aries bundles.
So I propose to create a new feature like karaf-core or similar
where we
move all features that should always be started but that do not have to
be in the startup.properties.
Does that make sense? If yes I will create a jira and move as many
bundles as possible.
So what is the benefit of moving these? If I think of the "network"
assembly then we can create a karaf distro that only contains the libs
of the startup.properties in the system
dir. The rest can be loaded using pax url. So I am quite sure we can
achieve to have a distro that is smaller than 2-3 MB.
Christian
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
