Community
Participate
Working Groups
Background: Eclipse Virgo currently runs in a multi-region environment implemented with the help of the recently introduced framework hooks. In both regions it includes SpringDM and Virgo's kernel depends on Spring DM. When refreshing PackageAdmin gathers all bundles with equal symbolic name and refreshes them all because of https://bugs.eclipse.org/bugs/show_bug.cgi?id=169593. This behaviour is fine in a single region framework. Also PackageAdmin has a global view in a multi-region enviroment as its provided by the framework which too has global view of the system. Problem: In Virgo refreshing Spring DM in the USER region, actually refreshes Spring DM also in the KERNEL region and with this a whole lot more of kernel bundles. I would expect that refreshPackages doesn't span across regions, but work by regarding each region as a separate "refresh area" as was with the old implementation of RFC 138 with two frameworks and two package admins respectively.
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.
Commit ID. http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=11091b631e46f08f0ff362785a37a5295b05f9ff
*** Bug 404859 has been marked as a duplicate of this bug. ***
