Bug 202150 - many plugins incorrectly installed into shared folders on OSX
many plugins incorrectly installed into shared folders on OSX
Status: REOPENED
Product: platform
Classification: Unclassified
Component: Plugin Manager
7.1
PC Mac OS X
: P2 with 1 vote (vote)
: 7.1
Assigned To: Libor Fischmeistr
au-issues
:
Depends on: 202388
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-14 21:49 UTC by athompson
Modified: 2014-02-10 14:15 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description athompson 2011-09-14 21:49:15 UTC
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.
Comment 1 Jiri Rechtacek 2011-09-15 12:33:12 UTC
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.
Comment 2 athompson 2011-09-15 18:43:34 UTC
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?
Comment 3 Jiri Rechtacek 2011-09-16 08:01:25 UTC
(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.
Comment 4 athompson 2011-09-16 14:41:08 UTC
(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!
Comment 5 Jiri Rechtacek 2011-09-16 15:18:58 UTC
(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?
Comment 6 athompson 2011-09-16 16:38:30 UTC
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.
Comment 7 athompson 2011-09-20 17:38:52 UTC
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).
Comment 8 athompson 2011-09-20 17:49:46 UTC
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.
Comment 9 Jiri Rechtacek 2011-09-21 07:07:26 UTC
(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.
Comment 10 Jiri Rechtacek 2011-09-21 07:16:14 UTC
(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.
Comment 11 Jiri Rechtacek 2011-09-21 07:59:39 UTC
(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.
Comment 12 athompson 2011-09-21 15:44:08 UTC
(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...


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo