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.
This makes it very hard to set up development computers consistently. The only consistent (and likely only legitimate) dep is "JavaScript Debugger". These are some of the other plugins JWA has depended on in the last few days alone, with a different mix every time: - Struts (This one just showed up today. Why?) - Tomcat 5.0 (?!) - Identity Management - Glassfish v1, 2.x (?!) - Facelets (But not JSF) Others have included IBM Websphere, REST, Identity Management, JSF, etc. Especially vexing is that most clearly aren't needed for basic webapp development.
Actually, it seems to be random every time. When I started this bug report, the deps were Struts, Tomcat 5, and JS debugger. I restarted the IDE and now the deps are Facelets, IBM Websphere, and JS Debugger.
Now JS debugger and Struts. It's like a slot machine!
Now Facelets and JS Debugger!
IBM, JS Debugger, JSF, PrimeFaces. This is fun!
Glassfish v1, Identity Management, JS Debugger, JSF, Primefaces, SOAP web services. To be clear, the only thing I'm selecting to install is "Java Web Applications".
Back to JS debugger and Struts. Random every time.
I should mention that I'm starting with a clean Java SE install. Just hitting the "Reload Catalog" button causes a new random set of deps to appear. Happens on multiple computers across multiple OSs, with multiple daily builds. I didn't really investigate before, but it's been happening for a long time. Product Version: NetBeans IDE Dev (Build 201103150400) Java: 1.6.0_24; Java HotSpot(TM) 64-Bit Server VM 19.1-b02 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb) Userdir: C:\Users\athompson\.netbeans\dev
Up to Java Web developers to investigate their dependencies...
Project dependencies of web.kit module looks sane. Why autoupdate shows only their subset?? And keep changing the subset?
I don't know and to be honest, I really don't care. If there is no interest from your side to find out what is wrong, then this is probably not important issue.
Excuse me, but *I* care. That's why I took the time to submit this bug report.
(In reply to comment #10) > If there is no interest from your side Do you mean me? I do care as well. But it looks like AutoUpdate problem at this stage so AutoUpdate owner should evaluate.
All I understand is that the AU UI shows different list of plugins from time to time. Fine with me, it shows some subset. I don't see any complain about functional problems, about layout of files being wrong on disk, etc. Thus I don't see a reason why somebody from AU should investigate the problem. Closing as invalid. If Java Web guys feel this is issue for them, they can provide more details and explain what is wrong in AU behavior (beyond randomized UI)..
(In reply to comment #13) > ... and explain what is wrong in AU behavior (beyond randomized UI). Randomized UI (and therefore buggy looking) is all what this issue is about (IMO). Why do we bother showing any dependency in first place when only (random) subset is shown? I'm missing what's the value to user. Just remove it completely and replace it with text "There are some dependencies which will be installed as well".
First of all, why the hell was this bug marked as invalid? If it involves a different component, move it there! This bug has actually gotten worse in recent weeks due to dependency changes. It's ridiculous to expect users to hit the "Reload Catalog" button and try again literally 30 times like I just had to just to install one damned plugin, especially since I have to do this every day due to issue #202150. Most users don't even realize the supplied dependencies are wrong. Comment 14 is a ridiculous solution. Instead of fixing the problem, just cover it up? Seriously? Let me reiterate: The problem is that when installing the "Java Web Applications" plugin, a random set of unnecessary "dependencies" are required as well. This is not just a display problem; the dependencies are installed and trying to uninstall them will also uninstall the "Java Web Applications" plugin. This isn't rocket science and I thought I made this perfectly clear the first time. Currently, there are only two legitimate dependencies for the "Java Web Applications" plugin: - Java EE Specifications Support - JavaScript debugger
(In reply to comment #15) > Comment 14 is a ridiculous solution. Instead of fixing the problem, just cover > it up? Seriously? athompson, you got the wrong end of stick. #14 is response to #13 - showing a random subset of dependencies is wrong. It does not provide any value to end user. I agree with you that it should be fixed. But if Jarda think it is perfectly OK then I would argue that not showing anything is better UI than current state. > This is not just a display problem I cannot remember since when we concluded (mistakenly) that this is just a UI issue. Jarda, I still think that this is an AutoUpdate issue - if there is a mistake in Java Web Project dependencies then outcome after AutoUpdate installation should be always the same error state. Why is it random??
(In reply to comment #16) > athompson, you got the wrong end of stick. #14 is response to #13 - showing a > random subset of dependencies is wrong. It does not provide any value to end > user. I agree with you that it should be fixed. But if Jarda think it is > perfectly OK then I would argue that not showing anything is better UI than > current state. If anything it's showing a random *superset* of dependencies; the only required dependencies are "Java EE Specifications Support" and 'JavaScript Debugger"
And I have to repeat yet again: Netbeans is not just *showing* a random set of dependencies. Those are the dependencies that actually get downloaded and installed. Netbeans will actually install a different set of plugins every time you install "Java Web Applications". So the deps it displays are the deps it resolved.
Reproducible on latest daily builds, investigating an real impact of users to classify the priority and ways how to fix it.
All plugins which are randomly joined to installation of Java Web Applications are eager modules, need to debug how eager module are tracked in AU. Eager modules inherently cannot break loading modules in IDE because no module can depend on eager modules. Eager module is loaded if and only all modules on what a eager depends on are loaded. If any of them is not present/enabled, the eager module won't be loaded. AU should do as same logic as module system, but it does unpredictable.
core-main/rev/29fec6d4ef5a (after branching 7.1Beta)
Jirka, what was the problem? Was it just a UI issue or was different set of modules loaded each time?
I guess I'll find out tomorrow, but this change looks like it will always require the eager modules to be installed...
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/29fec6d4ef5a User: Jiri Rechtacek <jrechtacek@netbeans.org> Log: #196737: "Java Web Applications" plugin deps are random every time
As I thought, this "fix" forces all eager modules to be installed.
(In reply to comment #22) > Jirka, what was the problem? Was it just a UI issue or was different set of > modules loaded each time? The reported (random) behavior was caused relation between plugins RECOMMENDS<->PROVIDES. PM selected one of all available providers (regardless it's eager or not), as a result different set of depending plugins was offered users to install. After the fix all providers are offered, like in IDE full build. This problem is more or less specific to Web and JEE feature because there are 5 different providers for Web frameworks (JSF, Struts, WebSphere etc.) To limit count of providers let's reconsider if all providers of "framework" token are really providers of that feature.
(In reply to comment #25) > As I thought, this "fix" forces all eager modules to be installed. Right, that's correct. PM has to work in as same way as module system does. Module system loads all installed providers if at least one other plugins NEEDS, REQUIRES or RECOMMENDS such provider.
Well then if you think this is adequate behavior on your part, please transfer this bug to whoever is in charge of the Java Web Applications plugin, because it's ridiculous and unacceptable to be required to install the entire j2EE stack and a bunch of useless plugins I'll never use like "Glassfish 1", "IBM Websphere", and "SJAS Identity Management" just for simple web applications. Could you also provide a link to the the documentation you're referring to which prevents you from making the recommended plugins optional?
(In reply to comment #26) > The reported (random) behavior was caused relation between plugins > RECOMMENDS<->PROVIDES. PM selected one of all available providers (regardless > it's eager or not), as a result different set of depending plugins was offered > users to install. After the fix all providers are offered, like in IDE full > build. This problem is more or less specific to Web and JEE feature because > there are 5 different providers for Web frameworks (JSF, Struts, WebSphere > etc.) To limit count of providers let's reconsider if all providers of > "framework" token are really providers of that feature. I do not think there is anything wrong with web frameworks. The thing is that nobody depends on these modules and therefore they would never get automatically installed/enabled if only direct dependency graph was used. And that's where Provides<->Recommends come into play. Meaning all Providers should be enabled because we do not know which one might be needed by user. And based on what athompson says the same happens (I guess) for server plugin implementations - each plugin providing some server support gets enabled because we do not know which one user may needed. On the other hand installing some obsolete old plugins like GlassFish 1.0 does not make much sense and whatever module closure AutoUpdate comes up with should be restricted to some list of "life" modules. But that's just a general thought - my knowledge of AU is none.
The problem random set of deps was fixed. File separate issue to plugin which shouldn't be installed and write up a justification why it shouldn't fixed. That's for you report what describes in some cases PM install random set of deps. It's fixed now. Do not open until it is random again.
(In reply to comment #29) > And based on what athompson says the same happens (I guess) for server plugin > implementations - each plugin providing some server support gets enabled > because we do not know which one user may needed. That's the point, AU cannot know what plugins are needed and what plugins are not needed anymore. The base paradigm of AU is plugins owners have to model real relations between plugins. > On the other hand installing some obsolete old plugins like GlassFish 1.0 does > not make much sense and whatever module closure AutoUpdate comes up with should > be restricted to some list of "life" modules. It's easy, just replace old token e.g. web.framework to web.framework.new and Java Web Application can recommends web.framework.new only. Or remove providing web.framework from obsolete plugins. Again, it's up to you, AU cannot know more than plugins owners.
(In reply to comment #28) > Well then if you think this is adequate behavior on your part, please transfer > this bug to whoever is in charge of the Java Web Applications plugin, because > it's ridiculous and unacceptable to be required to install the entire j2EE > stack and a bunch of useless plugins I'll never use like "Glassfish 1", "IBM > Websphere", and "SJAS Identity Management" just for simple web applications. A good place for RFE - enhance PM Install Plugin wizard with kind of UI (e.g. checkboxes) what allow users to choose what of recommends plugins should install or what shouldn't. > Could you also provide a link to the the documentation you're referring to > which prevents you from making the recommended plugins optional?
Yeah, that's a good solution. I'll put in an RFE.
yup
(In reply to comment #29) > I do not think there is anything wrong with web frameworks. The thing is that > nobody depends on these modules and therefore they would never get > automatically installed/enabled if only direct dependency graph was used. Why should they get automatically installed? It's rare that people need them. Remember the typical definition of "recommends" for dependency management, which is that "Item A recommends Item B if all 'typical' installations of Item A requires Item B". This is clearly not the case here.
(In reply to comment #35) > (In reply to comment #29) > > I do not think there is anything wrong with web frameworks. The thing is that > > nobody depends on these modules and therefore they would never get > > automatically installed/enabled if only direct dependency graph was used. > > Why should they get automatically installed? To make them available to IDE users out of the box. I do not know which frameworks users are using and giving users more options does not cost us anything in terms of performance so why not? I agree that better UI workflow would be to have button "Download Additional Webframeworks from AU" in framework chooser but AU does not provide API to perform module queries of this type. > It's rare that people need them. > Remember the typical definition of "recommends" for dependency management, > which is that "Item A recommends Item B if all 'typical' installations of Item > A requires Item B". I do not follow your definition. According to Module API Javadoc "[...] there is also OpenIDE-Module-Recommends which is even weaker version [of OpenIDE-Module-Provides] as it creates a conditional dependency - e.g. enables the module providing the token only if it is available, however if it is not, no dependency is broken."
> To make them available to IDE users out of the box. I do not know which > frameworks users are using and giving users more options does not cost us > anything in terms of performance so why not? I agree that better UI workflow > would be to have button "Download Additional Webframeworks from AU" in > framework chooser but AU does not provide API to perform module queries of this > type. Why can't they just go to "Tools>Plugins" to get them if they need them like everyone else?
(In reply to comment #37) > Why can't they just go to "Tools>Plugins" to get them if they need them like > everyone else? Because that's a very poor user experience IMO.
But that's the experience that you must go through to install other plugins. So now (by your definition) you have a poor *and* inconsistent user experience. And "poor" is a matter of opinion; I think that deciding what plugins you get to install instead of having the choice taken from you is the better way to go, and I'm sure others do too. This is not an iPhone so limiting choice is not a good option (i have an iPhone--they're great but I don't program on it). The one thing in a user experience that most people can objectively agree is "poor" is inconsistency.
Sorry but I'm losing track what we are discussing here. What I'm after is that out of the box NetBeans web development support contains some frameworks and some servers. I would not want to force users to go to a Plugin Central and search there through hunderds of plugins to find what they need.
I imagine you're talking about if people download the J2EE version of netbeans. I'm talking about people who download the SE version and then install what they need. As I mentioned before, those of us who are actually trying to help netbeans by downloading the daily builds and submitting bugs should not be punished by being forced to download and extra 80MB every day to get plugins we don't need.
(In reply to comment #41) > I'm talking about people who download the SE version and then install what > they need. As I mentioned before, those of us who are actually trying to help > netbeans by downloading the daily builds and submitting bugs should not be > punished by being forced to download and extra 80MB every day to get plugins we > don't need. I see. I do support and agree that it is important making it easier for you to download IDE and test it. I appreciate your effort. On the other hand because it is not a standard or common "use" of the IDE and its plugin portal I would argue that tweaking something for a particular corner case is not a good idea generally speaking.
It's a pretty important corner case, unless people around there think that they can develop Netbeans without help from the community.
(In reply to comment #43) > It's a pretty important corner case, unless people around there think that they > can develop Netbeans without help from the community. Text comments/emails are missing non-verbal part of communication and so perhaps mistakenly my feeling is that we are in a permanent disagreement here. :-) I think I clearly said that community help is extremely helpful and appreciated. How a software product is developed and tested on the other hand should never impact how the final product works. What you are asking for is a process change to allow you get daily binary changes without downloading whole distribution and without installing all modules which are not part of the final product binaries. That can be solved in many ways but it is way beyond "Java Web Applications plugin dependencies problem" this issue was about.
(In reply to comment #44) > How a software product is developed and tested on the other hand should never > impact how the final product works. You're arguing *my* point here. These recent changes to how Netbeans builds has broken 2 important pieces of existing functionality. First, users are no longer able to select which optional plugins they want; they're forced to get all of them and they can't even uninstall the unwanted ones later. Second, users are no longer able to install plugins into their private folder instead of the shared folder. I find it surprising that you're making this statement now, because in your previous comment you justified removing this functionality by calling it a "corner case". > What you are asking for is a process change > to allow you get daily binary changes without downloading whole distribution > and without installing all modules which are not part of the final product > binaries. That can be solved in many ways but it is way beyond "Java Web > Applications plugin dependencies problem" this issue was about. I'm not asking for a process change. I'm asking that you please restore functionality that *your* process change broke.
(In reply to comment #45) > These recent changes to how Netbeans builds > has broken 2 important pieces of existing functionality. I'm not sure which changes you are referring to but talk directly to the people who did the change. This issue is about random dependencies and as such it was resolved.
This issue was about a random set of *required* dependencies, and the "fix" made was to force users to install all dependencies, even if they aren't required. This broke existing functionality where the user could choose which optional plugins they wanted.
In fact, I marked this bug as "verified" because I was under the impression that either the messed up dependencies part would be addressed by the plugins themselves removing all but required dependencies from their dependency lists or a UI would be added allowing you to select which optional dependencies to install. Since the former can't happen since you now use that dependency information to decide what gets packaged into the J2EE build, and the latter, well, just never happened, I need to reopen this. IMO it's not acceptable to "fix" a bug that a user reported by simply taking away the functionality that contains the bug. I know I'm being a pain and I know you guys want to move on to more interesting tasks, but with a little more effort I'm sure that you can come up with a way to fix this problem without taking away existing functionality at least some people find important.
Sorry, but this issue was resolved. The defect was that dependencies are random and that was solved and now dependencies are not random and contain all dependent modules. There is not much to dispute about it - it was a defect in the code. I understand that you would like to either #1) make customizable which optional dependencies gets installed or #2) remove some of the (dated) optional dependencies from AU completely. These are two separate issues which can be filed.
David, please read this carefully. I am the one who filed this bug. The operation of Netbeans before this bug came about was that if you tried to install a plugin, only the plugins that *were required by* the plugin you want to install were automatically selected to be installed as well. That was how Netbeans operated. With the bug, sometimes other plugins (in addition to the ones required by the plugin you wanted to install) were randomly selected as well. The additional plugins that were randomly selected to be installed all happened to require the plugin you want to install. This was a coincidence. After this "fix", all plugins that *require* the plugin you want to install are selected to be installed as well. To summarize: - before the fix, the operation of Netbeans was that those plugins that *were required by* the plugin you want to install were selected to be installed as well - after the fix, the operation of Netbeans is that those plugins that *require* the plugin you want to install are selected to be installed as well It does not take a rocket scientist to understand that "A is required by B" is not the same thing as "A requires B". Since the conditions before this bug occurred have not been restored, this bug us not fixed. If you or anyone else wants to change how Netbeans works, this bug report is not the appropriate place to do it.
(In reply to comment #50) > To summarize: > - before the fix, the operation of Netbeans was that those plugins that *were > required by* the plugin you want to install were selected to be installed as > well > - after the fix, the operation of Netbeans is that those plugins that *require* > the plugin you want to install are selected to be installed as well > > It does not take a rocket scientist to understand that "A is required by B" is > not the same thing as "A requires B". Since the conditions before this bug > occurred have not been restored, this bug us not fixed. If you or anyone else > wants to change how Netbeans works, this bug report is not the appropriate > place to do it. Not true, if you want to install B, "A requires B" doesn't cause A to be installed as well. As a prove, add the attached updates.xml into your IDE. It contains 4 modules: A recommends token 'stuff', provides token 'foo' B requires token A C1 provides token 'stuff' C2 provides token 'stuff' If you want to install A, then C1, C2 will be installed as well (that's a matter of this bug), B will not be installed. If you want in install B, then A and C1, C2 will be installed as well. Let's do not waste one more time with this issue.
Created attachment 113107 [details] a prove it was fixed
This has nothing to do with what the "updates.xml" file says. This has to do with Netbeans *does*. before the fix, selecting "java web applications" to be installed required the following additional plugins to be installed as well: - javascript debugger after the fix, selecting "java web applications" to be installed requires the following additional plugins to be installed as well: - facelets - glassfish v1, v2.x - IBM websphere application server - identity management - java EE specifications support - javascript debugger - JSF - primefaces - SOAP web services - spring web MVC - struts Since NB was not restored to the operation it had before the bug, you cannot mark the bug as fixed. Jiri, one of the first things I checked was what the "updates.xml" file says, both before and after the fix. If you use the version you supplied, it would likely work fine in previous versions of netbeans with the bug, because that's not how the other deps were added. The reason I know this is because *I actually looked at the code to find the problem*. That's how I knew that this fix was incorrect before the daily build came out (check the previous comments). What netbeans was trying to do before the fix does not match what it's trying to do after the fix.
athompson, to be honest with you this is becoming quite a frustrating issue. I feel like I wasted quite a lot of time trying to explain this with no effect. Here is my another attempt which will be my last one if we do not move on from this communication deadlock and start making some constructive progress towards resolving this issue: (In reply to comment #50) > David, please read this carefully. I am the one who filed this bug. The > operation of Netbeans before this bug came about was that if you tried to > install a plugin, only the plugins that *were required by* the plugin you want > to install were automatically selected to be installed as well. That was how > Netbeans operated. With the bug, sometimes other plugins (in addition to the > ones required by the plugin you wanted to install) were randomly selected as > well. The additional plugins that were randomly selected to be installed all > happened to require the plugin you want to install. This was a coincidence. Let's use the same NetBeans terminology. Have a look at <http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#how-vers> and read please paragraph talking about "OpenIDE-Module-Provides and OpenIDE-Module-Requires". Let's also talk about one concrete example. For example Web Frameworks. In NetBeans there is a module named org-netbeans-modules-web-kit.jar (that is "Java Web Applications") which defines following dependency: "OpenIDE-Module-Recommends: org.netbeans.modules.web.project.framework". It is not OpenIDE-Module-Requires, nor OpenIDE-Module-Needs, but OpenIDE-Module-Recommends. And that dependency is in above API document described as "OpenIDE-Module-Recommends [] is even weaker version as it creates a conditional dependency - e.g. enables the module providing the token only if it is available, however if it is not, no dependency is broken". Then there is bunch of modules which are concrete implementations of individual web frameworks, eg. Spring, Struts, JSF, etc. and each of these modules defines in its manifest "OpenIDE-Module-Provides: org.netbeans.modules.web.project.framework". Now let's assume that user has NB IDE only with modules supporting Java SE development. Our argument is about which of these modules which provides "...framework" token should get downloaded and enabled when org-netbeans-modules-web-kit.jar (that is "Java Web Applications") module is marked for installation in AutoUpdate. After Jirka's fix what happens is that all modules which "OpenIDE-Module-Provides: org.netbeans.modules.web.project.framework" gets automatically installed. Before the fix it was only *one* of these modules and selection of that single module was random and that's why you filed this issue. And that's why we fixed it. What you seem to request is to NOT install any modules providing this token and let user go through the plugins list and pick up their dependencies by hand. I oppose that because installing "Java Web Applications" should result into something very similar to what user gets when they download and install Java EE edition of NetBeans - when installing basic blocks from which NB is composed (Java SE support, Java EE support, etc.) user should not have to handpick individual plugins. Now, I agree that there is lots of crap on AU which should not be there and that should be filed as separate issue and fixed. Agreed. If there is really a big need for users to fine tune and hand pick which optional plugins provided by AU should NOT be installed then OK let's file another issue to enhance current AU UI to allow that. But insisting that none of these dependencies should be installed is not an option. It may suit you for your particular case but I cannot imagine why somebody who wants "Java Web Applications" would not want to get automatically also JSF and GlassFish plugins for which NetBeans Java Web Applications support is optimized. As you yourself confirmed this requirement to fine tune what gets downloaded from AU is mainly motivated by your daily testing of NetBeans and desire to save download bandwidth. So as such it is not a common usecase of NetBeans IDE users. It is a testing usecase. It is a special use case of people like you who daily test NB. And it is in our best interest to support people like you and appreciate your generous help and time and effort and find some solution for your obstacles. Perhaps not in the product itself but for example in how product is distributed, eg. custom build collection of modules which give you what you need for testing, etc. There must be dozens of other (and better) solutions for your particular problem. I personally do not care if I must daily download 80MB or 200MB - it is no difference. But we all are different and have different habits which we desire to be full filled. Fine, that's understandable. :-) I mean this email with best intentions to resolve this and move on. Thanks.
I filed issues 205061 to clean up AutoUpdate center from relics.
athompson, in Comment #33, you are saying you will file an RFE for UI that will allow to unselect optional dependencies. Was this filed, and what is the number of this RFE? Thanks.
(In reply to comment #56) > athompson, in Comment #33, you are saying you will file an RFE for UI that will > allow to unselect optional dependencies. Was this filed, and what is the number > of this RFE? Thanks. A filed Bug 202757 right afterwards that same day (27 Sep). AFAICT it hasn't been touched.
Thanks.
This has since been fixed properly.