Community
Participate
Working Groups
Build Identifier: I20100429-1549 If you run Eclipse from a read-only location, then it selects an alternate location to store configuration data (typically $HOME/.eclipse). Everything ends up there including p2 profiles. It seems to me that the problem is in BuildTimeSiteContentProvider: File configurationFolder = new File(installedBaseURL, "configuration"); //$NON-NLS-1$ if (configurationFolder.exists()) { try { Properties config = AbstractScriptGenerator.readProperties(configurationFolder.getAbsolutePath(), "config.ini", IStatus.OK); //$NON-NLS-1$ String dataArea = config.getProperty("eclipse.p2.data.area"); //$NON-NLS-1$ String profileName = config.getProperty("eclipse.p2.profile"); //$NON-NLS-1$ if (dataArea != null && profileName != null) { int idx = dataArea.indexOf("@config.dir"); //$NON-NLS-1$ if (idx != -1) dataArea = dataArea.substring(0, idx) + configurationFolder.getAbsolutePath() + dataArea.substring(idx + 11); File profileArea = new File(dataArea, "org.eclipse.equinox.p2.engine/profileRegistry/" + profileName + ".profile"); //$NON-NLS-1$ //$NON-NLS-2$ This only reads the configuration/config.ini file to look for properties, and it assumes various things about the layout of the Eclipse installation. Compare this with org.eclipse.equinox.p2.core.Activator's start method, which uses BundleContext's getProperty method to find the configuration directory. That finds the correct copy of the profile. Reproducible: Always Steps to Reproduce: 1. Download and unpack the Eclipse SDK from 3.6M7 2. Make the SDK read-only (on Linux, chmod -R a-w eclipse) 3. Attempt a headless build of the CDT: java -cp eclipse-3.6M7/plugins/org.eclipse.equinox. launcher_1.1.0.v20100419.jar -Dosgi.install.area=eclipse-3.6M7 org.eclipse.core.launcher.Main -application org.eclipse.ant.core.antRunner -DjavacFailOnError=true -DdontUnzip=true -DbaseLocation=eclipse-3.6M7 -Dpde.build.scripts=eclipse-3.6M7/plugins/org.eclipse.pde.build_3.6.0.v20100428/scripts -DskipFetch=true '-Dconfigs=linux,gtk,x86 & win32,win32,x86' zips The exception is: java.lang.IllegalStateException: Profile not locked due to exception: eclipse -3.6M7/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/.lock (Permission denied) at org.eclipse.equinox.internal.p2.engine.ProfileLock.lock(ProfileLock.java:106) at org.eclipse.equinox.internal.p2.engine.SimpleProfileRegistry.restore(SimpleProfileRegistry.java:428) at org.eclipse.equinox.internal.p2.engine.SimpleProfileRegistry.getProfileMap(SimpleProfileRegistry.java:274) at org.eclipse.equinox.internal.p2.engine.SimpleProfileRegistry.internalGetProfile(SimpleProfileRegistry.java:235) at org.eclipse.equinox.internal.p2.engine.SimpleProfileRegistry.getProfile(SimpleProfileRegistry.java:165) at org.eclipse.pde.internal.build.AbstractScriptGenerator.getAssociatedRepositories(AbstractScriptGenerator.java:621) at org.eclipse.pde.internal.build.AbstractScriptGenerator.getSite(AbstractScriptGenerator.java:329)
That was a bit unclear: this is a bug because PDE falls over, unable to lock the profile. You can't call getProfile on a read-only directory.
Created attachment 168055 [details] proposed patch I'm not sure we can do much about this in general. If the profile area is in the currently running eclipse, then we can get the correct configuration area. However, if the profile is for some other eclipse install which happens to be read only, I'm not sure that we will be able to figure out the correct config location. The (currently untested) attached patch will check to see if we are talking about the running install. If so, we get the proper configuration area. Otherwise we protect against the IllegalStateException and carry on.
Created attachment 168255 [details] catch the exception I'm still thinking about what to do for this, but we are running out of time. I would like to go ahead with the change to catch the exception and keep the other half of the patch for more thought.
Created attachment 168257 [details] catch the exception
Comment on attachment 168257 [details] catch the exception Darin, can you review this please.
Comment on attachment 168257 [details] catch the exception +1
I have released the exception patch for RC1.
Thanks, Andrew. Just so I understand: this will result in PDE continuing, but not loading the profile? So it won't build against any jars found in the platform? IMO this is going to be very confusing, especially with no log output. Headless build is already full of pitfalls like this, where a misconfiguration silently causes a seemingly unrelated build error :-( I'd have to debug platform again to figure out why my plugin didn't build, this time without the benefit of a stack trace.
Any build setup that worked previously should continue to work now that we have caught the exception. This profile support is new in 3.6, if the baseLocation is an eclipse install, then we find the profile and use it as a source of metadata. In 3.5, sources of metadata needed to be specified using the "p2.context.repos" property. In particular, we are loading the profile to find additional artifact repositories that are associated with it. So here we are just failing to find additional artifact repositories. This could cause a build to fail if it was relying on those artifact repositories being found, but this is new support so I would not expect any existing build setups to be in this situation. Looking at this closer, I notice that the ProfileMetadataRepository, loads the profile differently than how build is doing it. This is allowing the publisher to successfully use the profile as a metadata repo despite its being readonly. I will look at doing something similar, although this may require the use of p2 internals. As well, this doesn't help us find the user's configuration and profile in the case of shared install, we would only be able to read the locked root profile, not the users profile which may have additional items installed in it.
Created attachment 168989 [details] patch to read readonly profiles
Darin, what do you think about this patch, it is starting to feel a bit big for RC2.
moving out to 3.6.1
Created attachment 173701 [details] new patch New patch after initial review with DJ: 1) extractProfileInformation didn't handle profile.gz files 2) There were some cases where the profile registry could still require a lock so we changed to use SimpleProfileRegistry directly to avoid this. This is comparable to what is done with ProfileMetadataRepository. 3) I added some protection if listProfileTimestamps returns an empty array
done, also ported the mentioned review changes to the code already in head.
