Community
Participate
Working Groups
Build Identifier: Our product sets the configuration area to ~/.eclipse-<hash>. Doing so cripples the links (and dropins) functionality when running from UNC paths, somewhere in the shadowing of the bundles.info file plugins are not correctly found by osgi, even though p2 can correctly install them and the simpleconfigurator correctly adds them to <shared>/bundles.info Reproducible: Always Steps to Reproduce: 1. Install Eclipse into \\<computer>\<share>\eclipse 2. Extract any project into \\<computer>\<share>\eclipse\dropins 3. Fire up Eclipse using -configuration %USERPROFILE%\testme, check whether the project is correctly loaded
CQ:WIND00224870 *setting version to 3.7* All, I've seen a few bugs around UNC paths, some of them in "WORKSFORME", tried to make this new one as clear as possible with a very detailed steps to reproduce, please let me know what you think! :) Helmut
I setup a shortcut on my Desktop to run Eclipse from \\machinename\share\eclipse and then tried the following: 1). started up with -configuration C:/Users/dj/testme This worked ok for me. My bundles which were in the dropins folder were in Eclipse when it started. To verify this I also started with -console and did an "ss" to find my bundle. I did note that an artifacts.xml file was create in /Users/dj. 2). started with -configuration %USERPROFILE%/testme This didn't work for me, I received a launcher error and it created a %USERPROFILE% folder on my desktop.
(In reply to comment #2) > I setup a shortcut on my Desktop to run Eclipse from > \\machinename\share\eclipse and then tried the following: > > 1). started up with -configuration C:/Users/dj/testme > This worked ok for me. My bundles which were in the dropins folder were in > Eclipse when it started. To verify this I also started with -console and did an > "ss" to find my bundle. I did note that an artifacts.xml file was create in > /Users/dj. > > 2). started with -configuration %USERPROFILE%/testme > This didn't work for me, I received a launcher error and it created a > %USERPROFILE% folder on my desktop. Thanks for looking into this, DJ! :) Your findings are interesting indeed, looks like you uncovered a workflow that actually picks up the dropped-in content... In order to make sure I retried to reproduce the issue, and again find the same problem: The plug-ins seem to be detected, the "Installed Software" tab of the "Installation Details" view shows as much. However, neither of the other views shows any trace of the RXTX plug-ins and features I dropped into the dropins folder. Here is the steps I used: 1.) Start from scratch to get a pristine configuration area 2.) Extract eclipse-SDK-3.7.1-win32.zip into folder <share> 3.) Extract RXTX drop into <share>\eclipse\dropins 4.) Fire up eclipse from cmd.exe: \\<host>\share\eclipse\eclipse.exe -configuration C:\temp\helmuth\test 5.) Check installation details view Hm, maybe me using a pristine eclipse was the difference? I definitely did not use %USERPROFILE% either, so that can't be the problem... I've recorded some screens for you to review... Let me know what you think, Helmut
Created attachment 208561 [details] Installation Details when dropping RXTX into a UNC-path directory
Ok, I am able to reproduce your problem now. It appears to be a problem when running with -configuration and perhaps unrelated to UNC paths. I first installed the RXTX features from the UI in a normal install and everything worked ok. (wanted to confirm that the package was installable) Then I ran with -configuration /Users/dj/test-config and did an install. When I restarted the bundles.info was updated but some of the branding things in the About were not present. (and the bundles weren't in the system when I did an "ss" in the console) The bundles and features themselves were on the file-system at /Users/dj/features and /Users/dj/plugins. (test-config/../features and plugins most likely) The feature.xml file in /Users/dj/test-config/org.eclipse.update listed the features correctly so the branding should work.
(In reply to comment #5) > Ok, I am able to reproduce your problem now. It appears to be a problem when > running with -configuration and perhaps unrelated to UNC paths. Thanks for investigating, DJ! :) You're definitely onto something here, I confirm that using the "-configuration" command-line option dropins and links are not correctly picked up, I was able to reproduce that over here as well, even with local, non-UNC paths. Also, I did some further testing to see why we seem to have special problems with UNC paths and found something odd: Specifying the configuration area via "config.ini" behaves differently than specifying it via command-line. As said above, using the -configuration option a bug occurs that seems to be generic, independent of UNC paths. However, when using config.ini with something like this, osgi.configuration.area=@user.home/.workbench-3.3.2.20111028-1147_@install.hash/configuration Eclipse will be able to pick up the content from dropins and extension locations. However, in that scenario UNC paths don't work, the same installation accessed via "C:\Inst" and "\\server\Inst" behaves differently. So, summarizing I think we've found two bugs, one generic, one UNC-path (and windows-) only. I suggest either to look at both of them as a unity, or to create a separate bug for the generic -configuration bug and fix them in two tasks.. What do you think, DJ? Helmut
We should track them as 2 separate issues in different bug reports. Please open a new report with your findings w.r.t. UNC paths. I am wondering if the problem of things not appearing when running with -configuration might be related to relative path computation. I set up the scenario again yesterday and it seemed to work but most of my data folders were co-located.
(In reply to comment #7) > We should track them as 2 separate issues in different bug reports. Please open > a new report with your findings w.r.t. UNC paths. > > I am wondering if the problem of things not appearing when running with > -configuration might be related to relative path computation. I set up the > scenario again yesterday and it seemed to work but most of my data folders were > co-located. Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=367210
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.
