[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Extension Registry optional import of org.eclipse.core.runtime.jobs

Hi, DJ

Thank you for the comments.

The thing which I try to accomplish is running registry bundle on
Equinox, but without the jobs bundle. I think for 3.2.1 this is
impossible, because there is no logic which uses RegistryStrategyOSGI
class and don't rely on jobs (I'm looking in the code). But I need a
confirmation for this.

The other point in my previous message was about the current state of
the registry. I just think that it should be possible to use
PlatformAdmin without using org.eclipse.core.runtime.jobs. Currently I
think this too isn't possible without touching the code.

I just found that the org.eclipse.osgi.service.resolver import of
registry isn't optional. Who  provides this package in standard container?

Maybe I was not clear enough in my message and I apologize for this.
Hope this will clarify the things more.

Danail Nachev

DJ Houghton wrote:
> Perhaps unrelated, here are a few comments if you, by chance, are trying to
> get the Equinox registry (code from HEAD) to run on a framework other than
> Equinox:
> 
> - you need to install the following bundles:
>       <your framework>
>       org.eclipse.equinox.common
>       org.eclipse.equinox.supplement
>       org.eclipse.equinox.registry
> - you need to set the following system properties
>       eclipse.registry.nulltoken=true
>       eclipse.createRegistry=false
> 
> 
> equinox-dev-bounces@xxxxxxxxxxx wrote on 01/17/2007 12:11:45 PM:
> 
>> Hi,
>>
>> In the manifest of org.eclipse.equinox.registry bundle, the
>> org.eclipse.core.runtime.jobs import is marked optional. However, it
>> doesn't work this way. If you remove the org.eclipse.core.jobs bundle,
>> you end with class not found exception.
>>
>> This is expectable because no where in the code there is a check whether
>>  jobs bundle is provided. The logic always use EquinoxRegistryStrategy
>> which depends on jobs bundle. The correct strategy which should be used
>> is RegistryStrategyOSGI. But it is never used.
>>
>> The version I talk about is 3.2.1.
>>
>> In the CVS HEAD, the activator now checks whether the configuration
>> location is available and make decision on this - whether to use the
>> EquinoxRegistryStrategy or RegistryStrategyOSGI. So, the only thing
>> which determines whether to use container time stamp (through
>> PlatformAdmin) and not use Jobs mechanism for notifying is the presence
>> of configuration location.
>>
>> So, if the registry is deployed on OSGi standard container (which
>> doesn't provide configuration locations) it will use the correct
>> strategy (no jobs and no PlatformAdmin usage)
>> If the configuration locations is available, then the container should
>> be equinox and will use the container time stamp (OK) and will use jobs
>> scheduling.
>>
>> It appears that I need jobs to run registry on Equinox. What if I want
>> to run registry on Equinox and don't use jobs bundle?
>>
>> So, the questions are the following:
>>
>> 1. Do I overlooked something?
>> 2. Why this optional import even exists in 3.2.1
>> 3. Where should I post my comments on the CVS HEAD version
>>
>> Danail
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 
> 

-- 
-------------------------------------------------
Danail Nachev . Software Engineer/Development Tools
ProSyst Labs EOOD
1606 Sofia, Bulgaria . 48 Vladajska Str.
Phone:  +359 (0)2 952 35 81/102 . Fax +359 (0)2 953 26 17
http://www.prosyst.com . d_nachev@xxxxxxxxxx
-------------------------------------------------
stay in touch with your product.
-------------------------------------------------