Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Plugin Development Environment (PDE) » Long delay + UI locked when saving MANIFESTs
Long delay + UI locked when saving MANIFESTs [message #53271] Thu, 02 April 2009 13:47 Go to next message
dave irving is currently offline dave irving
Messages: 6
Registered: July 2009
Junior Member
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
Re: Long delay + UI locked when saving MANIFESTs [message #53301 is a reply to message #53271] Thu, 02 April 2009 14:01 Go to previous messageGo to next message
Stefan   is currently offline Stefan
Messages: 316
Registered: July 2009
Senior Member
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

Hope that helps,
Stefan.

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
>
>
Re: Long delay + UI locked when saving MANIFESTs [message #53345 is a reply to message #53301] Thu, 02 April 2009 15:31 Go to previous messageGo to next message
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
>>
>>
Re: Long delay + UI locked when saving MANIFESTs [message #53370 is a reply to message #53301] Thu, 02 April 2009 16:09 Go to previous messageGo to next message
dave irving is currently offline dave irving
Messages: 6
Registered: July 2009
Junior Member
Hi Stefan,

Yeah - we're using bnd to OSGI-up a whole bunch of (non OSGI) 3rd party
dependencies - and have thousands of uses constraints.

I tried the osgi.resolver.usesMode=ignore trick - and it works like a
treat!

Fortunately, we use multiple versions of the same bundle in our target
platform - so I think this will work nicely for us.

Many thanks on helping me cure an increasingly tiresome head-ache!!

Dave
Re: Long delay + UI locked when saving MANIFESTs [message #53397 is a reply to message #53370] Thu, 02 April 2009 16:13 Go to previous messageGo to next message
dave irving is currently offline dave irving
Messages: 6
Registered: July 2009
Junior Member
dave irving wrote:

> Fortunately, we use multiple versions of the same bundle in our target
> platform - so I think this will work nicely for us.

Errrr, that should be "we _don't_ use multiple versions of the same
bundle..."

> Dave
Re: Long delay + UI locked when saving MANIFESTs [message #53475 is a reply to message #53345] Fri, 03 April 2009 08:16 Go to previous message
Stefan   is currently offline Stefan
Messages: 316
Registered: July 2009
Senior Member
Eric,

you're right, this is definetely not very practical but a workaround for
this problem. I hope, that this issue is addressed very soon
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=216934) to make this hack
obsolete...

Regards,
Stefan.

Eric Rizzo schrieb:
> 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
Re: Long delay + UI locked when saving MANIFESTs [message #594525 is a reply to message #53271] Thu, 02 April 2009 14:01 Go to previous message
Stefan   is currently offline Stefan
Messages: 316
Registered: July 2009
Senior Member
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

Hope that helps,
Stefan.

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
>
>
Re: Long delay + UI locked when saving MANIFESTs [message #594543 is a reply to message #53301] Thu, 02 April 2009 15:31 Go to previous message
Eric Rizzo is currently offline Eric Rizzo
Messages: 2252
Registered: July 2009
Senior Member
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
>>
>>
Re: Long delay + UI locked when saving MANIFESTs [message #594552 is a reply to message #53301] Thu, 02 April 2009 16:09 Go to previous message
dave irving is currently offline dave irving
Messages: 6
Registered: July 2009
Junior Member
Hi Stefan,

Yeah - we're using bnd to OSGI-up a whole bunch of (non OSGI) 3rd party
dependencies - and have thousands of uses constraints.

I tried the osgi.resolver.usesMode=ignore trick - and it works like a
treat!

Fortunately, we use multiple versions of the same bundle in our target
platform - so I think this will work nicely for us.

Many thanks on helping me cure an increasingly tiresome head-ache!!

Dave
Re: Long delay + UI locked when saving MANIFESTs [message #594558 is a reply to message #53370] Thu, 02 April 2009 16:13 Go to previous message
dave irving is currently offline dave irving
Messages: 6
Registered: July 2009
Junior Member
dave irving wrote:

> Fortunately, we use multiple versions of the same bundle in our target
> platform - so I think this will work nicely for us.

Errrr, that should be "we _don't_ use multiple versions of the same
bundle..."

> Dave
Re: Long delay + UI locked when saving MANIFESTs [message #594580 is a reply to message #53345] Fri, 03 April 2009 08:16 Go to previous message
Stefan   is currently offline Stefan
Messages: 316
Registered: July 2009
Senior Member
Eric,

you're right, this is definetely not very practical but a workaround for
this problem. I hope, that this issue is addressed very soon
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=216934) to make this hack
obsolete...

Regards,
Stefan.

Eric Rizzo schrieb:
> 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
Previous Topic:Building "umbrella" features that include multiple pre-built child features
Next Topic:Leveraging OSGi and dynamic bundle loading
Goto Forum:
  


Current Time: Tue Sep 23 02:35:45 GMT 2014

Powered by FUDForum. Page generated in 0.09342 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software