Community
Participate
Working Groups
I'm make a big guess here, entering this under "buckminster core", but the issues primarily seems to involve "modeling related" features, many of which I think are built with buckminster, so ... I'm thinking maybe buckminster is the place to start. If unrelated to buckminster, feel free to move (and apologies for assuming related). In testing IndigoRC4, I often try installing "everything" from staging repo and when I've tried that using a "shared install" I've noticed, in my log, messages similar to the following: !ENTRY org.eclipse.equinox.p2.touchpoint.natives 4 0 2011-06-11 13:19:54.576 !MESSAGE org.eclipse.equinox.internal.p2.touchpoint.natives.actions.UnzipAction error unzipping zipfile: /home/davidw/.eclipse/org.eclipse.platform_3.7.0_710143710/p2/org.eclipse.equinox.p2.core/cache/binary/org.eclipse.xtext.sdk_root_2.0.0.v201106070531destination: /usr/local/eclipseSDKRC4 This seems to imply something is trying to be installed into the read-only shared install location (which is what /usr/local/eclipseSDKRC4 is, installed there by "untarring" eclipse SDK as root ... well, using sudo, in unbuntu). I've noticed many of these modeling projects have a touchpoint in metadata that say, unzip(source:@artifact, target:${installFolder}); So ... a) not sure if something is wrong, or if these merely extra log messages b) if "installFolder" is incorrectly set? Or if there's a better choice? c) if there's anything harmful that happens, or "merely" missing some SDK related artifacts being installed? Just wanted to get this open so it could be understood before release. Thanks for any insights.
Created attachment 197839 [details] console log from one example run This is the whole console log, from one example test session. To reproduce, untar eclipseSDK into /usr/local as root (or, using sudo) so that it is not writable by normal users. Then, as normal user, start eclipse, add repo to software sites, such as http://download.eclipse.org/releases/staging then, as in this example test session, in "install new software" select "XText" feature to install. (In this test, I just selected the one feature ... rest mentioned in log were "dragged" in).
If it helps, I invoke this shared install from a script with no particular special flags for "configuration" area or anything ... ${ECLIPSELOCATION}/eclipse -showlocation ${LOCATIONNAME} -nosplash -console -debug -data ${DATAWORKSPACE} -vm ${DEV_JRE} -vmargs ${DEV_JRE_ARGS} And, normally, new plugins I install go into my ~/.eclipse/ directory, such as into ~/.eclipse/org.eclipse.platform_3.7.0_710143710/ I am "just testing" different things, and do not use a shared install normally, so hope I'm not "missing" some obvious step that is common knowledge. Much thanks,
I'm moving this to p2 since I don't think Buckminster is the culprit. We use PDE-build and p2 to publish and create touch points.
These look like root files being contributed by features. These could be things like readme/text/license files, that don't affect anything at runtime, or they couldd also be binaries or other things that will be broken if they aren't in the root. There is a general problem of what to do with root files in a shared install situation, the user would not have permission to install anything into the root of the install. I'm not really sure what the answer is here. Should the files be instead be installed somewhere under the ~/.eclipse? Do we require the feature to be installed by the admin user?
I'm adding at least one of the modeling people to CC, as seems this occurs for xtext, and mwe ... but, I think others too. :: Well, couldn't after all, in b3aggrcon file, xtext contact is alle-ki@itemis.de but that's not resolved here in bugzilla. But pretty sure these aren't binaries. But, I do not know what is in these "root" contributions. I'd guess they could all go into .eclipse ... but I am just guessing ... so let's say they could ... what would the p2.inf specify then, other than ${installFolder} to get into users .eclipse folder?
(In reply to comment #5) > I'm adding at least one of the modeling people to CC, as seems this occurs for > xtext, and mwe ... but, I think others too. > > :: Well, couldn't after all, in b3aggrcon file, xtext contact is > alle-ki@itemis.de but that's not resolved here in bugzilla. > > But pretty sure these aren't binaries. But, I do not know what is in these > "root" contributions. I'd guess they could all go into .eclipse ... but I am > just guessing ... so let's say they could ... what would the p2.inf specify > then, other than ${installFolder} to get into users .eclipse folder? Long time ago, the time of CBI and shell scripts, I've used the feature template to create xtext features see http://wiki.eclipse.org/Modeling_Project_Releng/Releng_Module The example feature project contains a rootfiles folder with contains notice.html and epl-v10.html. This files are now in org.eclipse.xtext.sdk_root_2.0.0.v201106070531. So the murder is out. :)
People who use license feature with rootfiles folder in it (i.e. EMF and CDO ), should have the same problem. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=306818. So how should the feature structure look like? Is rootfiles folder still neccessary?
Summary of the situation. Any IU can contribute "root files". Usually those root files go in the eclipse install folder (next to the eclipse.exe) and are typically things like executables, license files, etc. The problem with root files is that when the eclipse install folder is read only, the files can not be written where they should which produces the error mentioned by David in commen #0, but yet does not fail the installation. The fact that the installation does not fail can be a good or bad thing depending on the nature of the file. For example, license files are not really an issue from a runtime point of view, however dlls or other type of mandatory files will cause problems. The solution is two fold: 1) Allow for actions modifying the installFolder (e.g. unzip) to take flag indicating whether the install should fail or not if the operation can't be performed. 2) Handling of installFolder in shared install For this there are several possibilities: - When p2 runs in shared install, the value of installFolder could be automatically changed to point to a place in the configuration folder. This could work but could also cause problems if the action is making a reference to a file actually located in the installFolder - Allow for an alternate location to be passed as a parameter to certain actions. However note that both of these possibilities will require the plugin author to be aware that the files may not be in the install folder.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
