Community
Participate
Working Groups
Created attachment 140798 [details] P2 Installer log Build ID: P2 Installer 1.0.100.v20090528 Steps To Reproduce: 1. Launch a freshly downloaded copy of P2 Installer 3.5. I used equinox.p2.installer-3.5-win32.win32.x86.zip from http://download.eclipse.org/equinox/drops/R-3.5-200906111540/index.php 2. Enter any empty valid product install directory 3. Select stand-alone or shared install 4. Click Install It should display "Installing ..." then "An error occurred while collecting items to be installed" More information:
Created attachment 140799 [details] Screenshot of P2 Installer when failure message is displayed
Created attachment 140800 [details] P2 Installer properties
Created attachment 140801 [details] P2 Installer Fiddler session Attached HTTP session recorded with Fiddler.
Created attachment 140810 [details] Fixes artifact repo disablement and starts framework admin bundles Hi guys, I managed to find out what the problem was. It was a concurrency issue quite hard to pin point. The artifact repositories defined in installer.properties are registered in the ArtifactRepositoryManager with the isEnabled flag set to true but in some cases, if the artifact repository URI is also declared as a referenced repository in the transitive closure of loaded XML metadata files, a RepositoryEvent will concurrently be published to the ProvisioningEventBus with the isEnabled flag set to false. If the event is dispatched to the ArtifactRepositoryManager before the URI gets registered with isEnabled set to true, then the repository will end up being disabled. Therefore, in the collect phase, the repository will be discarded by the DownloadManager during repository selection before fetching artifacts thus yielding the error "An error occurred while collecting items to be installed". This patch simply registers the artifact repositories defined in installer.properties to the ArtifactRepositoryManager before it loads it. Additionally, the FrameworkAdmin bundles are programmatically started because they are needed later to lookup the Manipulator. Regards, Cédric Vidal
Thanks Cedric, I'll take a look.
(In reply to comment #5) > Thanks Cedric, I'll take a look. > You're welcome. I forgot to mention that this issue is a blocker since it makes the P2 Installer frontend fail in most cases with the galileo update site. Cheers, Cédric
*** Bug 238908 has been marked as a duplicate of this bug. ***
*** Bug 282212 has been marked as a duplicate of this bug. ***
Hi Cedric, I'm curious why you're starting frameworkadmin.equinox. This bundle is already automatically started by default -- e.g. see the product file and bundles.info. The other part of your patch looks good though.
Created attachment 141549 [details] Fixes artifact repo disablement Hi Simon, Sorry for replying so late. You are right, I wasn't using the product definition. Starting the framework admin bundle in code is not necessary at all when correctly using the product definition. The attached patch fixes artifact repo disablement but doesn't start framework admin bundles. Regards, Cédric Vidal PS: Trying to post the attachment using Mylyn with context attached. I apologize if something goes wrong.
Created attachment 141550 [details] mylyn/context/zip
+1 for this latest patch for Galileo SR1 (comment #10).
Created attachment 141908 [details] tweak of previous patch Thanks Cedric. I've added this tweaked version of your last patch to HEAD. -- This is a tweak on the previous patch that also uses the same "add" logic for metadata repos and modifies the loop to always do add and then load instead of two loops.
Hum. Not sure adding and loading inside a single loop is safe. Here is a scenario that I think breaks: Let's take two artifact repositories A and B where B's URI is declared as a referenced repository in A's transitive closure of loaded XML metadata files: - A gets added - A gets loaded and B gets lazily registered in the ArtifactRepositoryManager with the isEnabled flag set to false - B gets added but is already registered has being disabled so B's addition has no effect on B's enablement in the ArtifactRepositoryManager - B gets loaded Eventually, A is enabled but B is disabled. I think it is safer to add all artifact repositories in a first loop then load all repositories in a second loop. What do you think ? Regards, Cédric
I forgot to +1 applying the same add/load strategy to metadata repositories ;)
Created attachment 141912 [details] tweak of tweak of previous patch This patch made against CVS HEAD applies the same logic to metadata and artifact repositories but does the adding and the loading in separate loops
Created attachment 141913 [details] mylyn/context/zip
Thanks John. I've also applied the patch to the maintenance branch, bumped versions and tagged. -- re: comment 14 The "add" is spec'ed to enable a site if it is already present but disabled so this should be ok. I re-looked at the code in AbstractRepositoryManager and it looks safe to me. It of course still a good plan to try this out while we have plenty of time to make a change.
(In reply to comment #18) > The "add" is spec'ed to enable a site if it is already present but disabled so > this should be ok. I re-looked at the code in AbstractRepositoryManager and it > looks safe to me. Indeed, you're right, I overlooked AbstractRepositoryManager's add method ^^
