Community
Participate
Working Groups
When running from a shared install, the list of update sites available in the update manager is blank. This does not happen when not running from a shared install. Setting osgi.configuration.cascaded to true has no effect.
You mean read-only vs. non-read-only shared installs, right?
Yes. Sorry, I'm not familiar with all the supported kinds of installs.
The set of repos are stored in preferences which are "not" cascaded in a shared install. This is a known limitation however it's not clear that we would always want to cascade the values from the parent.
Trying osgi.configuration.cascaded was just an idea I had. I think cascading may be the ideal solution because if the list is merely copied for new users and that user subsequently updates to a later version of Eclipse, they will still have the old update site instead of the new one.
Hi Simon,, Could we work around this particular issue in Linux distributions somehow? Thanks, Andrew
Hmm... have we never had a situation where we want to share a set of initial preferences. It's a more general issue so I'd be hesitant to do something custom here.
(In reply to comment #6) > Hmm... have we never had a situation where we want to share a set of initial > preferences. It's a more general issue so I'd be hesitant to do something > custom here. Okay, I'd rather not diverge so we'll have to just tell users how to add repos themselves. Thanks for the info.
This problem is still preventing a P2-enabled version of Eclipse from being officially included in Gentoo. Any news on it? How are the other distros handling this?
(In reply to comment #8) > How are the other distros handling this? We just suck it up. It's not the end of the world IMO.
*** Bug 267926 has been marked as a duplicate of this bug. ***
*** Bug 282740 has been marked as a duplicate of this bug. ***
*** Bug 288021 has been marked as a duplicate of this bug. ***
*** Bug 288688 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Could we work around this particular issue in Linux distributions somehow? Before P2, I used to copy the default /usr/local/eclipse/configuration dir to ~/.eclipse manually(or by a script), and pass it in by '-configuration'. This worked, as far as I remember. Would this still be the only workaround?
I had considered copying via a script but the default configuration directory is always suffixed with a code that is generated in quite a complex way within the Java source. I didn't know about the -configuration option though so maybe that would work.
*** Bug 298708 has been marked as a duplicate of this bug. ***
We continue to get regular traffic on IRC about this. Please consider addressing this for 3.6 (probably too late for that) or 3.7.
Niels Thykier, a Debian Eclipse maintainer, suggested a wrapper script for /usr/bin/eclipse that sets this up in the user's configuration area if it's not already set up.
*** Bug 325463 has been marked as a duplicate of this bug. ***
Definitely not JDT related.
Ian, any thoughts on this one? This is a bit of a PITA for us.
Move all 3.8 bugs to Juno.
*** Bug 327955 has been marked as a duplicate of this bug. ***
(In reply to comment #17) > We continue to get regular traffic on IRC about this. Please consider > addressing this for 3.6 (probably too late for that) or 3.7. Not there in 3.7. Any chance for 3.7.2? :) Until then, can/do we have an official list of update sites, somewhere visible on eclipse.org near downloads? Even better, an importable 'bookmarks.xml' would be a great painkiller for this. The most useful source so far has been Ekke's blog: http://ekkescorner.wordpress.com/eclipse/update-sites, but there is no guarantee it will be always updated (it doesn't seem and not easy to find either). BTW, just out of curiousity: is this a difficult bug to fix? BTW2, I agree with those annoyed by it; to me it means Un*x is not a first class platform (if installed in the normal way).. "we just suck it up" - would windows users suck it up to?
I'm sorry that this did not get fixed, but we have all been busy on other aspects of p2 and working on commercial products (not related to p2) for our respective employers... and you are right I'm not using linux so it is not an itch to scratch. Code wise it is probably not very hard, but there is few details to get right. The key piece of code where the list of repositories are being stored and restored are AbstractRepositoryManager#restoreRepositories and saveToPreferences in bundle org.eclipse.equinox.p2.repository. The most forward way to fix this is probably to change the loading code to find repositories in the shared install, add them to the list of repos, but not persist them in the local list. Looking forward for a contribution.
Launching eclipse -configuration foo also shows an empty list of pre-configured repositories, so this might be the simplest test case.
Same problem with Indigo on Windows x64, non shared install.
Same issue here with Eclipse 4.2M2 64bit, on a Windows 7 64bit machine when eclipse is installed into the 'Program Files' folder. A work around to get the initial software sites list loaded: 1. Temporarily copy the eclipse folder to your desktop. 2. Run eclipse from this temporary folder and open 'Help' > 'Install New Software' area. 3. Click on 'Available Software Sites', select all entries and export the list. 4. Run you eclipse installed in 'Program Files' folder, go to 'Available Software Sites' area again and import. 5. Delete your temporary eclipse. Or see http://wiki.eclipse.org/IRC_FAQ#How_come_my_list_of_update_sites_is_completely_empty_when_other_people_says_theirs_has_stuff_in_it.3F
CQ:WIND00326634 This is an important issue to look at. With an empty list of repos, people easily try installing software from an incorrect repository. This leads to very awkward error messages that don't help understanding what's going wrong. In our case, our product is based on Indigo but people tried getting JDT from Helios. They probably read some instructions asking to get JDT from Helios or probably didn't know that our product is now on Indigo. Result was Eclipse complaining about conflicting dependencies of pde.runtime ... not helpful at all. I think it's really important getting a proper list of repos preconfigured even in the shared install case. The data should exist in the master configuration, so why can't eclipse initialize the local config area properly ?
(In reply to comment #3) > The set of repos are stored in preferences which are "not" cascaded Are these "normal" Preferences which we could initialize in our product with a plugin_customization.ini file ? Then this would be an acceptable workaround for us as product builders.
(In reply to comment #30) > Are these "normal" Preferences which we could initialize in our product with a > plugin_customization.ini file ? Then this would be an acceptable workaround for > us as product builders. Unfortunately the plugin_customization mechanism is only used to initialize defaults whereas these preferences are actually stored in the real location. (in the "profile" scope) The equivalent to set them from a file would be to do a preference import but we don't offer that ability from the command-line.
On windows x64 with UAC enabled and eclipse in the "C:\program files" directory, experienced this. Followed the workaround from comment 28 (move eclipse folder to a non-UAC directory and exported/imported the bookmark list). Was expecting the software to find this in (or save this information to) a user profile directory or other uncontrolled folder (app data or home dir). This works fine for me when UAC is disabled. Me-too the comments about being confused and manually entering the wrong update site by hand (which was what I was doing before I found this bug).
Where exactly are those preferences stored?
Just theorizing: ProfileScope depends on a profile, and updates sites are stored next to profile data in .data folder. In a shared configuration profile depends on a parent profile, but preferences are stored only next to parent profile, while ProfileScope looks for them next to user profile (f.e. in ~/.eclipse/someuniquepath/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/.data/.settings). I think that each profile has a reference to a parent profile. Maybe getting location of a parent profile and reading preferences that are next to it will not be that hard.
Created attachment 215461 [details] Fix proposition
Created attachment 215462 [details] mylyn/context/zip
Pascal, I'd appretiate if you could review the patch, even if it is not going into Juno, because Fedora is ready to ship it anyway :-).
CQ:WIND00327834 This issue continues bugging us, since shared installs are rather common and having no update sites at all (or invalid ones contributed from feature.xml files) is a bad problem. It happens just too easily that somebody either doesn't find an addon to install, or installs a wrong version from an invalid repo ! I filed bug 380633 asking the Platform to fix their outdated feature.xml files but that would still not get proper sites enabled. Given that a patch is attached here, could that patch please be reviewed by a knowledgeable person ?
This was not done for Juno. I'll put this on kepler since we have a patch.
Any chance for review? It's good time now, as there will be plenty of time to revert it...
Hi Krzysztof, is there a particular reason why you chose to approach this by registering an additional service rather than directly changing the actual preference loading code?
It's hard to say now :-( - I probably wanted to avoid any changes in the API, as I hoped to get this patch into Juno. Changing ProfileScope to support two locations (readonly master and writable local) requires changes in AbstractScope interface (imo), and probably somewhere else. The solution with service is a rather simple one...
Pragmatism works :) Based on your contrib, I'll take this work from here to completion.
A patch for this has been released. It will be available in the next I build.
This bug is far away from being fixed. I have installed 4.2.2 today and changed my config.ini with > osgi.configuration.area=@user.home/.eclipse A newly created workspace does not contain any update site. In other words, site list is all empty.
This bug has *not* been fixed for juno (which is 4.2.2) but only for kepler
(In reply to comment #46) > This bug has *not* been fixed for juno (which is 4.2.2) but only for kepler Thanks for this update. Can this be verified in the current 4.3 milestone?
(In reply to comment #47) > (In reply to comment #46) > > This bug has *not* been fixed for juno (which is 4.2.2) but only for kepler > > Thanks for this update. Can this be verified in the current 4.3 milestone? Yes, this has been in since 4.3 M4 (iirc) but I encourage you to try out 4.3 M6 (http://download.eclipse.org/eclipse/downloads/drops4/S-4.3M6-201303141330/) which also includes support to assist with the migration of plugins (http://www.rapicorp.com/2013/03/shared-installs-just-got-better.html).
(In reply to comment #48) > (In reply to comment #47) > > (In reply to comment #46) > > > This bug has *not* been fixed for juno (which is 4.2.2) but only for kepler > > > > Thanks for this update. Can this be verified in the current 4.3 milestone? > > Yes, this has been in since 4.3 M4 (iirc) but I encourage you to try out 4.3 > M6 > (http://download.eclipse.org/eclipse/downloads/drops4/S-4.3M6-201303141330/) > which also includes support to assist with the migration of plugins > (http://www.rapicorp.com/2013/03/shared-installs-just-got-better.html). Pascal, verified. Default two update site are available now!
Could this fix be backported to Juno SR2+ for LTS ? For product builders it's really a massive problem that my product's update sites are not enabled by default when my product is installed into a read-only location or into C:\Program Files . Shall I just file a new bug for tracking the backport ?
(In reply to comment #50) > Could this fix be backported to Juno SR2+ for LTS ? > > For product builders it's really a massive problem that my product's update > sites are not enabled by default when my product is installed into a > read-only location or into C:\Program Files . > > Shall I just file a new bug for tracking the backport ? From an LTS point of view, the process to follow to get this fixed in Juno is unclear. LTS has the concept of "maintenance committers" who gets paid by an LTS member company to do the work, however the process to get this started is unclear. All I know is that at this point Ericsson has no plan to backport this bug.
If I did the backport and provided it as a patch / pullrequest / Gerrit , would it be considered for checkin to the Juno maintenance branch ? Which contribution form do the p2 committers prefer ?
Then I can commit the patch but w/o guarantees :) Yet it is unclear how the LTS git repo would obtain this patch.
(In reply to comment #53) > Then I can commit the patch but w/o guarantees :) > Yet it is unclear how the LTS git repo would obtain this patch. The public Juno maintenance branch is no longer being used for builds. There is nothing further for you to do here Pascal. If a maintenance committer wants this fix, they can cherry-pick it into the appropriate LTS branch and run their private build.
