Community
Participate
Working Groups
Build ID: 20090619-0625 Steps To Reproduce: 1. Run eclipse 2. select Build Path / Add Library / JUnit / JUnit Library version 3 or 4 3. Current Location and Source Location is null More information: It happens when current user has no write premissions to Eclipse installation directory (/opt/eclise). chown -R user /opt/eclipse solves that problem but it is not acceptable for multiuser installation of Eclipse.
It does not look like an Eclipse issue to me. Installing eclipse on Linux is just untar the provided gz file... So, change the access rights on the created 'eclipse' directory sounds like a "normal" administrative task to do after... Move to Platform to decide how to close this bug (or to continue the discussion if I missed some important point here...)
Simon, do you have any advice on this?
Frederic, any reason why this would fail when it is read-only? I can reproduce easily. In my standard eclipse the Junit 4 library shows up in the package explorer and .classpath has: <classpathentry kind="con" path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/> In my multi-user install the .classpath has: <classpathentry kind="con" path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/> However, the package explorer does not show "JUnit 4" under "JRE System Library". Is JDT setting up JUnit 4 in a preference, maybe in the ConfigurationScope? PW
Shared install is my day-to-day development environment only on windows. I just tried this out and had no problems e.g. could add JUnit and had the relevant current and source locations set correctly. I'll check with one of the folk using Linux.
(In reply to comment #3) > Frederic, any reason why this would fail when it is read-only? Just some more information. If you go Properties>Java Build Path "JUnit 4" is listed under Libraries ... but it contains no useful information (which is I guess the original problem description). PW
(In reply to comment #4) > Shared install is my day-to-day development environment only on windows. Simon, it has to be a read-only shared install. See bug 282944 for the windows version that doesn't work. PW
Yes, Paul I know ;) I was able to reproduce on Windows from a clean install. As soon as I installed something though I was then able to add JUnit normally. When a shared install comes up a bundles.info is not written and we instead rely on the bundles.info in the shared install. Once we've done an install of anything we then write out the user specific bundles.info. Perhaps the lookup mechanism used to find the JUnit jars is not cascading??
AFAICT this is done in org.eclipse.jdt.internal.junit.buildpath.BuildPathSupport.JUnitPluginDescription.getLibraryEntry() which calls into p2 methods from org.eclipse.jdt.internal.junit.buildpath.P2Utils PW
The code in P2Utils readBundles (or it's caller) needs to check the shared area if the user's bundle info is not present. There's similar code in org.eclipse.pde.internal.core.PluginPathFinder.getPluginPaths. Obviously it would be a good thing if simple configurator exposed some API here rather than have everyone implement this logic however short term we need to fix this lookup.
(In reply to comment #9) > Obviously it would be a good thing if simple configurator exposed some API here > rather than have everyone implement this logic however short term we need to > fix this lookup. Is there a bug to track this? The PDE team would love this API addition.
(In reply to comment #10) > > Is there a bug to track this? The PDE team would love this API addition. bug 269496 PW
*** Bug 282944 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > (In reply to comment #3) > > Frederic, any reason why this would fail when it is read-only? > > Just some more information. If you go Properties>Java Build Path "JUnit 4" is > listed under Libraries ... but it contains no useful information (which is I > guess the original problem description). > > PW > I do not see any, but as now this bug is in JDT/UI inbox, I'm sure you'll get more lights on this rapidly...
FYI: bug 276111 contains a patched jdt.junit JAR for 3.5. *** This bug has been marked as a duplicate of bug 276111 ***
