well I tried to differntiate from any post/pre scripting ideas which are already around and I though an analogy to the fragment-bundle and host would be best :)
Concerning the multiple Hosts I have no objections :) 2012/2/2 Ioannis Canellos <[email protected]> > +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 > > -- 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/>
