+1 @3.1; I'm completely with Lukasz on this one @Ioannis trigger sounds also strange to me. Maybe "modifier"?; I don't think that this will make much sense. Such situations would be rather seldom (tbh I cant remember to encounter any of them till now) but maybe lead to missuse.
Kind regards, Andreas 2012/2/2 Łukasz Dywicki <[email protected]> > +1 for doing that, -1 for pushing it into Karaf 3.0. As we discussed in > one from previous topics we should start stabilizing trunk to finally > prepare RC1. We lived so long without fragment features and I believe we > can release 3.0 without it too. > > Best regards, > Lukasz Dywicki > -- > Code-House > http://code-house.org > > Wiadomość napisana przez Andreas Pieber w dniu 2 lut 2012, o godz. 09:42: > > > 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/> > >> > >
