Hi,

Hmm, difficult question...

How about this: We leave it in for the 3.0 release and make upgrade from
previous releases as seemless as possible.

For the next release we scan all contained plugins and decide on which
plugins to keep in the core web console (I would assume the OSGi Core
Spec as well as the platform related plugins) and which plugins (the
compendium related plugins like configuration, scr, Deployment Admin,
...) to separate out into their own plugin bundles.

This makes it possible to easily mix and match the required/used plugins
and also allows use to independently evolve the different plugins.

WDYT ?

Regards
Felix

On 24.03.2010 13:22, Valentin Valchev wrote:
> For me - let's remove it, I don't need it, ProSyst too.... So don't
> count my voice.
> 
> But, as not ProSyst employee, my opinion is that if removed, it makes no
> sense to delay the plugin, but to release it together with webconsole
> 3.0.0. This way, people that need OBR will be able to install it. Later,
> we can improve it and create a new OBR Plugin release.
> 
> Regards,
> Valentin
> 
> On 24.3.2010 г. 12:15, Felix Meschberger wrote:
>> Hi,
>>
>> On 23.03.2010 15:05, Valentin Valchev (JIRA) wrote:
>>   
>>> BTW. Isn't it better to make OBR & SCR a separate plugins.
>>>
>>> OBR is not into OSGi core spec, and SCR is IMHO rarely used. The benefits 
>>> of that step will be:
>>> 1. This will solve the resolve problem we have now
>>> 2. OBR activator might track OBR service and register the plugin only when 
>>> it is available
>>> 3. SCR might be available only if at least one component is installed
>>>
>>> A similar approach is used by UPnP Plugin. It will not be visible in 
>>> console, unless at least one UPnP Device is available.
>>>
>>> This prevents the user from being confused by opening as example 
>>> "Components" page, that says "No components".
>>>     
>> I am not against this proposal at all, in fact it makes some sense (and
>> the console bundle itself a bit smaller ;-) and lives by the OSGi ideas).
>>
>> My question is: Do we want to do this for the Web Console 3.0 release
>> already ?
>>
>> One advantage would be to be able to delay the OBR plugin release until
>> the bundlerepository and utils projects have settled. The disadvantage
>> of this is, that people upgrading from previous versions of the Web
>> Console would end without (released) support for OBR.
>>
>> WDYT ?
>>
>> Regards
>> Felix
>>
>>
>>   
> 
> 

Reply via email to