Bugzilla – Full Text Bug Listing
| Summary: | [pkgAdmin] refreshPackages incorrectly spans regions | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Borislav Kapukaranov <b.kapukaranov> | ||||||
| Component: | Framework | Assignee: | Thomas Watson <tjwatson> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | b.kapukaranov, eg, glyn.normington, jwross, katya.stoycheva, tjwatson | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | Juno M1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 352484 | ||||||||
| Attachments: |
|
||||||||
|
Description
Borislav Kapukaranov
I can think of three options: 1) Stop doing this altogether and never pull in bundles with the same symbolic name. With old eclipse update it was very common that you would end up with many versions of the same bundle installed. This hack in the framework really was to work around this poorly designed management agent. If we did this I would probably want to add a configuration property that could be used to enable the old behavior. 2) Stop doing this if there are any resolver hooks installed. If resolver hooks are installed then we can probably assume the framework is no longer flat. I don't really like this option because it adds unpredictable behavior to the framework. 3) Add a configuration option that disables this behavior, but we leave the default as enabled. I think we should go for option 1) in Juno. We may need to go with option 3) if this is needed in Indigo SR1. We can use the same configuration property if needed, but have the default be enabled in Indigo SR1 (3.7.1) and disabled in Juno. Proposed configuration property: equinox.refresh.duplicate.bsn = (false|true) Indigo SR1 (3.7.1) default value is true Juno (3.8) default value is false Sounds good. This fix is needed most crucially for Virgo 3.5 with its p2 support. 3.5 should be later this year and hopefully can use Equinox 3.7.1. Also, if this bug becomes a problem in the field for Virgo 3.0, we could ship a Virgo 3.0.1 which can use Equinox 3.7.1 (or a hot fixed version of 3.7 if 3.7.1 is not yet available when 3.0.1 is needed). Sounds good to me too. I'm only concerned that a property configuring this could be changed during runtime. And this leads to a totally different behaviour, kind of like the bsnversion property at the moment. Have you thought on how to prevent that or if its really a problem from your perspective? Apart from that 1) for Juno and 3) for Indigo SR1 is great. I can prepare a patch for 3) if thats ok? (In reply to comment #3) > Sounds good to me too. > > I'm only concerned that a property configuring this could be changed during > runtime. And this leads to a totally different behaviour, kind of like the > bsnversion property at the moment. > > Have you thought on how to prevent that or if its really a problem from your > perspective? Typically configuration properties are read once and stored into a final field upon startup. This way if they are changed at runtime it has no effect. > > Apart from that 1) for Juno and 3) for Indigo SR1 is great. > I can prepare a patch for 3) if thats ok? That would be great! Note we have moved to the git repo (just yesterday) located at http://git.eclipse.org/c/equinox/rt.equinox.framework.git/ Created attachment 199840 [details]
patch with the fix for 3.7.1
Here is the patch with the new property and the respective changes in the PackageAdmin/FrameworkWiring implementation. I've tested that on the Virgo-p2 prototype and its working fine.
I've formatted this as a git patch using Egit. In the past I've seen problems with that so if you encounter them, let me know to format a new patch with cygwin (works much better usually).
For a test case I imported the tests project from the git repo and they require an unresolved dependency - org.eclipse.core.tests.harness.CoreTest. Any ideas how to get these running? I was planning to extend the PackageAdmin test suite.
(In reply to comment #5) > For a test case I imported the tests project from the git repo and they require > an unresolved dependency - org.eclipse.core.tests.harness.CoreTest. Any ideas > how to get these running? I was planning to extend the PackageAdmin test suite. You'll need the following three projects: org.eclipse.core.runtime.compatibility.registry org.eclipse.core.tests.harness org.eclipse.test.performance As far as I know, they're only available from the CVS repo at :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse. (In reply to comment #6) > (In reply to comment #5) > > For a test case I imported the tests project from the git repo and they require > > an unresolved dependency - org.eclipse.core.tests.harness.CoreTest. Any ideas > > how to get these running? I was planning to extend the PackageAdmin test suite. > > You'll need the following three projects: > > org.eclipse.core.runtime.compatibility.registry > org.eclipse.core.tests.harness These two projects are located in the git repo: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/ > org.eclipse.test.performance > > As far as I know, they're only available from the CVS repo at > :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse. org.eclipse.test.performance still lives in CVS at this moment. We are still in transition to git so this is going to be awkward until everything has moved over. Sorry. Created attachment 199914 [details]
Fix for Juno + testcase
Here is the fix for Juno with test case. I will create a separate bug for 3.7.1.
Patch released to Juno. Note that right not the default value is still false in Juno. *** Bug 404859 has been marked as a duplicate of this bug. *** |