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 the last week or so, many of the plugins I use are no longer being installed into the user plugins folder, but rather the shared plugins folder. This list includes most of the "Java Web and EE" plugins and the PHP plugins. This creates big problems for the extremely common use-case where users are upgrading from one daily build to another. Now, users have to reinstall all of these plugins every time they upgrade to a newer daily build, which is a ridiculous restriction for people with limited bandwidth or time. Since this is a relatively new development, I assume what's happening is that Netbeans is just assuming that these plugins are built in to the IDE (and therefore installed into the shared plugins folder), which is not the case if you download the "Java SE" version of netbeans to minimize download size. From a broader perspective, I've seen the overly-complicated scheme involving "target clusters" that netbeans currently uses for determining where plugins go. Wouldn't the following logic be much simpler and perfectly adequate? 1. If there is already a (earlier) version of the plugin in the shared plugins folder, install the plugin into the shared plugins folder by default. Fall back to the user plugins folder if the shared folder is not writeable. 2. Otherwise install the plugin into the user plugins folder by default. If you want to get fancy you can give the user the option to install the plugin into the shared folder, but it's probably not worth the effort.
It was Arch decision while designing new Plugin Manager for NetBeans 6.0. Just a quick summary: New plugin which declares own target cluster goes to install dir to declared cluster, new plugin w/o target cluster goes to userdir. There are some exceptions - if a plugin declares nbm.is.global=true goes to install dir (in 'extra' cluster) in any case and vice versa. And, if the install dir is in read-only mode, then userdir is the fallback. In addition, all updates replace original installation if writable. No plan to change this design in the near future. As a easy workaround install your builds as the root (run IDE installer as root) to keep your build clean w/o modification.
Sorry, but I have to reopen and mark as defect for a couple of reasons: 1. The behavior is inconsistent on different platforms. On Windows, the aforementioned plugins install into the user plugins folder and on OSX the plugins install into the shared plugins folder. 2. This behavior on OSX just recently changed (in the last week or so) from the same as how it works on Windows and other platforms to the current behavior. 3. Even if it were decided years ago that the behavior you describe above should be how NB6 plugins work, that behavior hasn't been embraced for years. At this point I would argue that behavior on Windows and other platforms (including OSX until recently) has become the de facto standard, and any deviation at this point would require further discussion and warning. Additionally, the behavior should be applied consistently across platforms unless there is a *very* compelling reason not to do so. Actually, I think I vaguely remember discussions on NB6 plugin behavior from years ago, and I thought the previous behavior (and the current behavior on Windows) was decided. Is there a document somewhere which specifies this stuff?
(In reply to comment #2) > Sorry, but I have to reopen and mark as defect for a couple of reasons: > > 1. The behavior is inconsistent on different platforms. On Windows, the > aforementioned plugins install into the user plugins folder and on OSX the > plugins install into the shared plugins folder. Depends on state if shared plugins are writable or not. > 2. This behavior on OSX just recently changed (in the last week or so) from the > same as how it works on Windows and other platforms to the current behavior. Lack of details. If you see any scenario which causes install/update doesn't work on OSX, file it as separate issue with detailed steps to reproduce. > 3. Even if it were decided years ago that the behavior you describe above > should be how NB6 plugins work, that behavior hasn't been embraced for years. > At this point I would argue that behavior on Windows and other platforms > (including OSX until recently) has become the de facto standard, and any > deviation at this point would require further discussion and warning. > Additionally, the behavior should be applied consistently across platforms > unless there is a *very* compelling reason not to do so. As I wrote above, no plan to change this design in the near future. Please, don't reopen it again. > Actually, I think I vaguely remember discussions on NB6 plugin behavior from > years ago, and I thought the previous behavior (and the current behavior on > Windows) was decided. Is there a document somewhere which specifies this > stuff? 5 years ago, I cannot find appropriate mails or wikis. The www.netbeans.org infrastructure was switch from collabnet to kenai and some links didn't work now.
(In reply to comment #3) > Depends on state if shared plugins are writable or not. Huh? What does that even mean? I can do a fresh, standard install on all three major platforms right now and then try to install the "Java Web Apps" plugin. It will install to the user folder on XP, Vista, 7, and Linux, and install to the shared folder on OSX. How is this inconsistent behavior not a bug, especially since a couple of weeks ago it installed to the user folder on every platform? If you want, I'll split this portion off into another bug report but it really needs to be fixed. POLA, man, POLA!
(In reply to comment #4) > (In reply to comment #3) > > Depends on state if shared plugins are writable or not. > > Huh? What does that even mean? I can do a fresh, standard install on all > three major platforms right now and then try to install the "Java Web Apps" > plugin. It will install to the user folder on XP, Vista, 7, and Linux, and > install to the shared folder on OSX. How is this inconsistent behavior not a > bug, especially since a couple of weeks ago it installed to the user folder on > every platform? Check file privileges in all of your platforms. It should show any differences between Linux and OSX. My files show: [jirka@jirka-laptop netbeans-7.0.1]$ ll total 2236 drwxr-xr-x 6 root root 4096 2011-08-25 11:38 apisupport drwxr-xr-x 2 root root 4096 2011-08-25 11:37 bin -rw-rw-r-- 1 root root 6726 2011-07-28 23:42 CREDITS.html -rw-rw-r-- 1 root root 1770 2011-07-28 23:42 DISTRIBUTION.txt drwxr-xr-x 7 root root 4096 2011-08-25 11:38 enterprise drwxr-xr-x 2 root root 4096 2011-08-25 11:37 etc drwxr-xr-x 10 root root 4096 2011-08-25 11:38 harness drwxr-xr-x 8 root root 4096 2011-08-25 11:37 ide drwxr-xr-x 9 root root 4096 2011-08-25 11:38 java -rw-rw-r-- 1 root root 2117 2011-07-28 23:42 LEGALNOTICE.txt -rw-rw-r-- 1 root root 79586 2011-07-28 23:42 LICENSE.txt -rw-rw-r-- 1 root root 34115 2011-07-28 23:42 moduleCluster.properties drwxr-xr-x 8 root root 4096 2011-08-25 11:37 nb -rw-rw-r-- 1 root root 15822 2011-07-28 23:42 netbeans.css drwxr-xr-x 8 root root 4096 2011-08-25 11:37 platform drwxr-xr-x 8 root root 4096 2011-08-25 11:38 profiler -rw-rw-r-- 1 root root 5500 2011-07-28 23:42 README.html drwxr-xr-x 3 root root 4096 2011-08-25 11:37 ruby -rw-rw-r-- 1 root root 200778 2011-07-28 23:42 THIRDPARTYLICENSE.txt -rwxr-xr-x 1 root root 1862656 2011-08-25 11:37 uninstall.sh drwxr-xr-x 5 root root 4096 2011-08-25 11:37 websvccommon Could you attach your output?
We obviously know that OSX is writeable (I actually have a separate bug on this because the files are installed with the wrong owner on OSX). I'll check it on Linux when I get home, but this isn't relevant for two reasons: 1. The owner and permissions on OSX have been consistent the entire time, yet before the plugins were installed into the user folder and now they're installed to the shared folder. 2. The whole point is the behavior is inconsistent across platforms. The end user doesn't care about the underlying mechanics of the inconsistency; he just cares that it's inconsistent. If all the other platforms do things one way, then OSX should do things that way as well. It doesn't matter that all the other platforms do it that way because the shared folder isn't writeable. Honesty, the current plugin logic is meant to solve a non-existent use-case. I have been a developer over 20 years and I have never seen a developer share their development box with another developer. Would you? If this causes problems for real developers then it's instantly not worth it.
I know you're not liking me for reopening this, but there's another problem caused by this change in addition to the ones mentioned above: If you installed a plugin with an earlier build that installed to the user folder, or if you force a plugin to be installed into the user plugins folder (by temporarily making the app folder read-only), and then upgrade the plugin, Netbeans will actually remove the plugin from the user folder and install it into the shared folder. This causes Netbeans to fail to start on a subsequent Netbeans upgrade due to unsatisfied plugin dependencies. For example, you install plugin A which depends on plugin B, then plugin B gets upgraded via the standard update process, and then upgrade Netbeans, Netbeans won't start. This is because plugin A (which is still in the user folder) depends on plugin B (which is now gone because it got moved to the previous shared folder).
I'd like to point out that this behavior violates the defined behavior you spelled out in comment #1 (all updates replace original installation if writable), so even by that standard this is a valid bug.
(In reply to comment #8) > I'd like to point out that this behavior violates the defined behavior you > spelled out in comment #1 (all updates replace original installation if > writable), so even by that standard this is a valid bug. I'll check it. If it's true I track it as separate issue.
(In reply to comment #7) > I know you're not liking me for reopening this, but there's another problem > caused by this change in addition to the ones mentioned above: If you > installed a plugin with an earlier build that installed to the user folder, or > if you force a plugin to be installed into the user plugins folder (by > temporarily making the app folder read-only), and then upgrade the plugin, > Netbeans will actually remove the plugin from the user folder and install it > into the shared folder. This causes Netbeans to fail to start on a subsequent > Netbeans upgrade due to unsatisfied plugin dependencies. For example, you > install plugin A which depends on plugin B, then plugin B gets upgraded via the > standard update process, and then upgrade Netbeans, Netbeans won't start. This > is because plugin A (which is still in the user folder) depends on plugin B > (which is now gone because it got moved to the previous shared folder). IMHO it doesn't make sense. NetBeans should start correctly even though the module B moved from userdir to shared dir. Module System loads module regardless of its placement. It might be the problem if and only if a user shared the same userdir with different IDE installation, moreover forward and backward. But, it's not a supported use-case. Correct me if I missed something.
(In reply to comment #9) > (In reply to comment #8) > > I'd like to point out that this behavior violates the defined behavior you > > spelled out in comment #1 (all updates replace original installation if > > writable), so even by that standard this is a valid bug. > > I'll check it. If it's true I track it as separate issue. Filed as issue 202388.
(In reply to comment #10) > IMHO it doesn't make sense. NetBeans should start correctly even though the > module B moved from userdir to shared dir. Module System loads module > regardless of its placement. It might be the problem if and only if a user > shared the same userdir with different IDE installation, moreover forward and > backward. But, it's not a supported use-case. Correct me if I missed something. Module B would no longer exist. It was moved to the shared folder, and then you upgraded Netbeans so it went away (it's in the old shared folder, not the new one). But you're right, I can't reproduce the most recent problem again with yesterday's build so I'll have to figure out what the heck is going on...