|
|
Re: Long delay + UI locked when saving MANIFESTs [message #53345 is a reply to message #53301] |
Thu, 02 April 2009 15:31 |
Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
On 4/2/2009 10:01 AM, Stefan Roeck wrote:
> Hi Dave,
>
> we had the same problem and found out that the uses-constraints in our
> target platform bundles are a problem for resolving. There are two
> possible solutions (assuming that you don't need uses-constraints, i.e.
> don't have multiple versions of the same bundle in your target platform):
> - Set VM-Parameter osgi.resolver.usesMode=ignore
> - Remove all uses-constraints from manifest files
Do you mean remove them from the manifests in the target platform? That
doesn't seem very practical given a target platform that is based on one
of the EPP packages like "Eclipse for JEE Developers", is it?
Eric
> dave irving schrieb:
>> Hi,
>>
>> I have a workspace with several (~10) projects - each being built as
>> an OSGI bundle. I have a large number of dependencies in my target
>> platform (~200).
>>
>> When modifying dependencies for a bundle by editing its MANFIEST.MF,
>> I'm encountering a long (30 - 45 second) UI freeze when I save the
>> resource.
>> This occurs before any required re-building of the workspace kicks in.
>>
>> I've recently upgraded from Eclipse 3.3 to Eclipse 3.4(.2) and did not
>> experience this when developing in 3.3.
>>
>> During the 'freeze' - CPU ramps right up throughout the duration - and
>> most of the time we seem to be in 'resolveState' - having lots of fun
>> in GroupingChecker....
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker$PackageRoot s.isConsistentClassSpace(GroupingChecker.java:295)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker.isConsisten tInternal(GroupingChecker.java:103)
>>
>> at
>> org.eclipse.osgi.internal.module.GroupingChecker.isConsisten t(GroupingChecker.java:85)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.addConflicts(R esolverImpl.java:734)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.getConflicts(R esolverImpl.java:711)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.findBestCombin ation(ResolverImpl.java:629)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.findBestCombin ation(ResolverImpl.java:594)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.checkUsesConst raints(ResolverImpl.java:539)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles 0(ResolverImpl.java:535)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.checkUsesConst raints(ResolverImpl.java:573)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles 0(ResolverImpl.java:535)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles (ResolverImpl.java:501)
>>
>> at
>> org.eclipse.osgi.internal.module.ResolverImpl.resolve(Resolv erImpl.java:388)
>>
>> - locked <0x1339fe10> (a org.eclipse.osgi.internal.module.ResolverImpl)
>> at
>> org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateIm pl.java:428)
>> - locked <0x132553f8> (a org.eclipse.osgi.internal.resolver.UserState)
>> at
>> org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateIm pl.java:488)
>> at
>> org.eclipse.pde.internal.core.MinimalState.internalResolveSt ate(MinimalState.java:206)
>>
>> - locked <0x13255448> (a org.eclipse.pde.internal.core.PDEState)
>> at
>> org.eclipse.pde.internal.core.MinimalState.resolveState(Mini malState.java:201)
>>
>> at
>> org.eclipse.pde.internal.core.PluginModelManager.modelsChang ed(PluginModelManager.java:161)
>>
>>
>> This 30 - 45 sec lag when updating MANIFESTS is making 3.4 pretty much
>> unusable for me on fairly large projects.
>>
>> Is this a known issue? Is there anything I can tweak in my
>> configuration to prevent this?
>>
>> Thanks,
>>
>> Dave
>>
>>
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.08421 seconds