I got the same idea, but Achim explained it's different than a trigger.
A trigger means (or "embedded" features) require a new feature,
something like:
<feature name="karaf-war">
<feature>war</feature>
<bundle>war-commands</bundle>
</feature>
(same with trigger).
So it means that it's not transparent for the users, as they have to use
a specific karaf-war feature.
The Achim proposal is to install a new feature automatically when the
pax web war is installed, without modifying the "source" feature (pax
web war for instance).
Regards
JB
On 02/02/2012 11:10 AM, Ioannis Canellos wrote:
+1 for the idea. I am not very fond of the naming (fragment / host) it looks
more like a trigger rather than a fragment.
Does it make any sense to support multiple hosts?
On 2 Φεβ 2012, at 10:42 π.μ., Andreas Pieber wrote:
I really like the fragment idea. Actually I've encountered such situations
as you described already more than once :-/. But I think only extending
wont be enough; in addition it would be also required to remove/ignore
bundles from the host.
Otherwise +1
Kind regards,
Andreas
On Thu, Feb 2, 2012 at 09:30, Achim Nierbeck<[email protected]>wrote:
Hi all,
when I tried to work on https://issues.apache.org/jira/browse/KARAF-1017last
night I noticed that
our features are missing a nice "feature".
Following situation right now.
The Karaf standard feature does contain the http, war, http-whiteboard and
jetty feature.
Those features do not only contain the pax-web and jetty bundles but also
some extra
benefits of Karaf, the http and web commands.
AFAIR we decided once that it would be best that every project does take
care of the their features,
as Camel and CXF (AFAIK) have done so far.
For the pax-web project I did this for pax-web 2.0 which includes those
features named above.
The thing that is missing in the pax-web-features file are the http and web
commands.
*My proposal: *
Introduce a new features element called *features-fragment*
The tag could look like the following:
<features-fragment name="http-command" host="http">
<bundle ....>
</features-fragment>
this fragment is supposed to be extending the hosting feature to add
additional bundles which
are also installed by the features service when the hosting feature is
installed. The features service
could look for all features-fragments that are "bound" to the host
features.
I think just creating a feature that depends on the http features like the
following
<feature name="http-command">
<feature>http</feature>
<bundle ....>
</feature>
is not enough and is actually also a regression of Karaf 3.0 vs. Karaf
2.2.x
*Benefits: *
This way we are able to easily adapt/extend external features with
specialties needed in certain environments.
Right now it would be that the external pax-web feature is extended with
special Karaf commands.
But I could also think this to be a nice enhancement for customers
extending Karaf with their own features.
Regards, Achim
--
Apache Karaf<http://karaf.apache.org/> Committer& PMC
OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer&
Project Lead
blog<http://notizblog.nierbeck.de/>
Ioannis Canellos
FuseSource
Blog: http://iocanel.blogspot.com
Apache Karaf Committer& PMC
Apache Camel Committer
Apache ServiceMix Committer
Apache Gora Committer
Apache DirectMemory Committer
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
