Hi Felix, I have the following plugins already separated: deppack ds (declarative services) shell obr
The question is can I commit now? 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 >> >> > -- ------------------------------------------------- Valentin Valchev · Lead Software Engineer ProSyst Labs EOOD 1606 Sofia, Bulgaria · 48 Vladajska Str. Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17 http://www.prosyst.com · v.valc...@prosyst.bg ------------------------------------------------- stay in touch with your product. -------------------------------------------------
<<attachment: v_valchev.vcf>>
signature.asc
Description: OpenPGP digital signature
