This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In JDev we came across the following scenario: 1) jdeveloper/netbeans/bridge/var/cache is installed in a shared, read-only file location. The entire Jdev & NB is installed not locally but on a shared server. We can't delete var/cache . The .lastModified file under it (the file we're supposed to touch to invalidate the caches) is also read-only. 2) We start JDev with autodiscovery on, the first time, and because of auto-discovery in our bootstrapping code we determine that we must invalidate the caches. But because of 1) can't really do that, we simply proceed and (the way things currently work) call launchNBMain() 3) org.netebans.Stamps.findFallbackCache() then finds and loads the pre-built caches, as it does not know that the caches are (or rather must be) invalid. Because the caches' contents are wrong, but not broken, the IDE does start, only without doing any of the scanning that comes with auto-discovery. We want the fallback cache to be ignored, but outside a system property we, on the IDE side, can't communicate to the NB startup code to ignore the cache. I've told our client to delete the cache, but assuming that may not always be possible for a given user (e.g. say the user does not have permission to do it) or desired (e.g. for other clients, who didn't have auto-discovery on, and for whom the cache is valid), can the NB code handle this case differently? It can either rely on a system property, for example, or we can pass in a parameter to MainImpl.main() maybe? I can send a patch where this works with a system property, let me know if that's OK, and if so what do you want that system property name to be (e.g. more in line with NB's standards).
You can probably influence the behavior by pre-pending empty directory to "netbeans.dirs" property. Then dirs()[0] will be empty and no fallback cache will appear at all. But I agree, new property is cleaner way... Let's name the new property "netbeans.fallback.cache" and by default set it to dirs()[0]"/var/cache" to keep consistency with existing behavior. If set to "none", let's ignore the fallback cache all-together.
OK, I agree. So here is the new org.netebans.Stamps.findFallbackCache(String cache): private static File findFallbackCache(String cache) { String fallbackCacheLocation = System.getProperty("netbeans.fallback.cache"); // NOI18N if ("none".equals(fallbackCacheLocation)) { // NOI18N return null; } if (fallbackCache == null) { fallbackCache = new File[0]; if (fallbackCacheLocation != null) { File fallbackFile = new File(fallbackCacheLocation); if (fallbackFile.isDirectory()) { fallbackCache = new File[]{ fallbackFile }; } } if (fallbackCache.length == 0 && dirs().length >= 1) { File fallback = new File(new File(new File(dirs()[0]), "var"), "cache"); // NOI18N if (fallback.isDirectory()) { fallbackCache = new File[]{ fallback }; } } } if (fallbackCache.length == 0) { return null; } return new File(fallbackCache[0], cache); }
Y01 The best way to produce diff is to use $ hg diff and attach the resulting file. this Y02 api changes like introduction of new property are subject to review Y03 missing description in module's arch.xml Y04 missing test
Proposal for review: https://hg.netbeans.org/ergonomics/rev/b922e98fdfa8
Looks good. I am not sure if I should do anything more to fully review the transaction (e.g. set status, add tag), but it all looks good from my side.
OK, let's propagate the change into main code line then.
Integrated into 'main-silver', will be available in build *201407160001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/b922e98fdfa8 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #244990: Support for netbeans.fallback.cache property