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.
Steps to reproduce: - delete .netbeans folder, delete .nbi folder - install JavaSE NB pack - start NB - uninstall JAvaSE pack - install Mobility pack - start IDE NetBeans Mobility projects will not be available Work around: - close IDE - delete user dir (.netbeans) - restart IDE
This is reproducible for other packs as well. For example, if I do the steps from above but install Mobility first and Ruby then - there will be no prjects available at all
I can reproduce the same issue but with different steps: 1) remove .netbeans 2) extract full netbeans zip 3) comment several clusters in etc/netbeans.conf (leave only the ones related to JavaSE) 4) start ide, invoke new project wizard, close it and the IDE as well 5) uncomment all the clusters 6) start IDE,invoke new project wizard The result is the same as at point 4. If remove close ide, remove .netbeans and then start again then all kinds of project would appear. Reassigning to autoupdate, but probable core is more approriate component for such a bug. Increasing to priority to P2.
this scenario worked in 6.0.1 -> marking as regression
I don't understand why autoupdate is randomly assigned to problem like this. None steps talks about Autoupdate/Plugins. Reassigned back to original component, please assign to correct component. Thanks
passing to Jarda. This is definitely caused by the chache. OTOH, this is probably expected behavior. You modified externally a file and therefore the cached FS cannot known about the changes you had done.
I agree this is a bug and it needs to be fixed. The original report by mikk is caused by issue 126036. I am mentioning this as a proof that we knew about this problem since begining. The usecase described in "from dlipin Wed Mar 5 14:19:10 +0000 2008" is imho unsupported or P5, so it is really not fair to use that as the main reason for moving the bug to core. If user mangles manually with config files, the he is on his own, imho. Now to the possible fix. We really need .lastModified file to be created in the root of each cluster. Issue 126036 was OK with having this file newer than any other file in the cluster. However to fix the problem reported by mikk, we need the .lastModified file to have timestamp at the time of creation of the cluster (and modification of netbeans.cluster file). I guess this can be guaranteed only by installer. Is it possible to change the installer to, after unzipping a cluster, create empty .lastModified file in its root?
> The usecase described in "from dlipin Wed Mar 5 14:19:10 +0000 2008" is imho unsupported or P5, so it is really not > fair to use that as the main reason for moving the bug to core. If user mangles manually with config files, the he is > on his own, imho. Maybe. You might also say that there are no much of such users. And also that we don`t support the minority. But that feature has been working for a long time. And I have used it much with big pleasure. I have been happy to simply disable/or enable features that I don`t want to work at the moment or suddenly feel a need for. For me it`s P3 and a normal usecase. OK, now I am on my own. Cross fingers to let me stay alone with that trouble. > Now to the possible fix. We really need .lastModified file to be created in the root of each cluster. > Issue 126036 was OK with having this file newer than any other file in the cluster. However to fix the problem reported by mikk, we need the .lastModified file to have timestamp at the time of creation of the cluster (and modification of netbeans.cluster file). Jarda, to be honest: this file was not mentioned in the issue 126036, right? > I guess this can be guaranteed only by installer. Installer is already a big bung for a number of NetBeans/GlassFish/whatever issues. I don`t want installer to take care of one more. Imagine that you don`t like installer but use zip installation. Personally I always use zip not installers in my development. Should we force such users to touch .lastModified file in each cluster that they enable? Should we state this feature (I would certainly call it the bug, but to be polite, I won`t) in netbeans.clusters file? Should we write a wiki topic about this? What else should we do instead of fixing the problem? > Is it possible to change the installer to, after unzipping a cluster, create empty .lastModified file in its root? The thing is that it already exist after installation since it exists in each cluster zip file [1]. It has the same timestamp as was set during cluster zip creation done by BE. To be fair and not to start a holy war: yes, it can be simply workarounded on installer side by "touching" .lastModified file in each cluster that installer adds. After that I would move the issue to core and make it P3. To be honest, my usecase is the almost same as mikk mentioned. One thinks that it is P3, another thinks it is P5.. I could imagine the following "zip" usecase very close to the one described by mikk: 0) remove .netbeans 1) take javase-netbeans zip [2] and mobility-netbeans zip [3] 2) extract javase to one directory, mobility to the other 3) run javase IDE, exit 4) run mobility IDE. I guess, the result would be prettry much the same: no mobility projects. If anyone can see here the installer trace here, please speak up. [1] http://bits.netbeans.org/download/trunk/nightly/latest/zip/moduleclusters/ [2] http://bits.netbeans.org/download/trunk/nightly/latest/zip/netbeans-trunk-nightly-<build>-ruby.zip [3] http://bits.netbeans.org/download/trunk/nightly/latest/zip/netbeans-trunk-nightly-<build>-javase.zip
Workarounded on installer side http://hg.netbeans.org/main/rev/419ae094a8a9 Passing back to core.
Thanks for your change. I'll think about ways to improve the cache invalidation during startup. The only constrain that I have is to not touch disk at all. As every disk read slows down cold IDE startup significantly. Re. "workaround". The big idea behind caches in 6.1 is that the user can only modify its user directory and that any changes to the install directory with all clusters can only be done by automated tools. And that these tools can properly cooperate. Autoupdate does that, by creating the right file. I am glad to see installer does that as well. This was always the plan and I am glad we are finally where we wanted to be.
changeset: 75367:cd061b4b1d9e tag: tip parent: 75362:8ec8dcc86301 parent: 75366:6c76bc25d120 user: Jaroslav Tulach <jtulach@netbeans.org> date: Wed Mar 26 16:58:41 2008 +0100 summary: #129288: Caches remember the location of clusters they are created for and if this changes, they get invalidated