Hi, On 12.09.2011 08:52, Valentin Valchev wrote: > Hi Felix, > I have the following plugins already separated: > deppack > ds (declarative services) > shell > obr > > The question is can I commit now?
Sure, go ahead. Regards Felix > Regards, > Valentin > > On 9.9.2011 г. 18:59 ч., Valentin Valchev wrote: >> Hello, >> On 8.9.2011 г. 09:51 ч., Felix Meschberger wrote: >>> Hi all, >>> >>> On 07.09.2011 20:26, Valentin Valchev wrote: >>>> Btw what about the OBR plugin? Shall it remain build-in or moved as >>>> separate plugin? >>> Now, this starts to be an interesting discussion ;-) >>> >>> This is the current plugin setup in the Web Console: >>> >>> (1) Plugins I consider core and which should be kept: >>> - Bundle >>> - Services >>> - License >>> - System Properties >> Thinking of that, maybe we can add also another one - Framework >> Properties, that the user can obtain from >> BundleContext.getProperty(String key), since framework properties are >> important, but it's not actually necessary to be system properties. >>> (2) Plugins already considered for breaking out >>> - Deployment Admin -- FELIX-3099 >>> - DS - FELIX-3100 >>> - Shell - FELIX-3107 >>> >>> (3) Plugins still in the Web Console which might/should be split off >>> - Configuration Admin >>> - LogService >> I think that these should be build-in. Configuration and Log service are >> so common, that we can make them available by default. >>> - Preferences Service >>> - Wire Admin >> Could go into common bundle 'compendium plugins'. So with one bundle you >> can install almost all OSGi-related plugins/printers. >>> - Thread >>> - OBR >>> >>> The idea of also breaking out the Thread configuration printer is to >>> easier support thread dump funcitonality introduced with Java 5 and 6 >>> through the JMX Thread API. Also this could be aligned with the Apache >>> Kato project, particularly KATO-14. >> Yes, but still Thread information is general information, that can be >> used for system analysis and the information will be still usable, if >> you don't have that JMX API. So I vote for leaving Thread info into the >> main web console. Additional functionality could be provided by separate >> bundle - like that memory plugin, that already uses the JMX API I think. >>> Now, that we started breaking out plugins, we should probably be >>> consequent and break out non-central plugins. >>> >>> Regards >>> Felix >>> >>> >
