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.
Build #53 of the ergonomics clone. 1. Create a Java SE project (Java features will be enabled) 2. Create a Groovy file in this project (Groovy features will be enabled) 3. Delete the Groovy file that was just created => Groovy panel is displayed in the Project properties of the project, through which I can disable the Groovy support, which cleans up build-impl and removes libraries 4. Shut down the IDE and start it with a fresh user dir (this simulates passing the project to another user) 5. Open the Java SE project that was created previously => Groovy panel in Project properties is missing, so there is no straightforward way to disable Groovy in this project.
Petr, I am able to reproduce this behaviour with regular Java SE IDE build on Dec 16. As such it seems like a common behaviour of Groovy. And actually I am not sure whether it is behaviour or misbehaviour, it all sounds logical to me. But I let groovy guys evaluate the scenario based on your steps: 0a. download Java SE IDE (the one that does not have groovy) 0b. install it 0c. make all its directories read only 1. Create a Java SE project 2a. Use Tools/Plugins and get Groovy support (should be installed in userdir, as shared install is read only) 2b. Create a Groovy file in this project 3. Delete the Groovy file that was just created => Groovy panel is displayed in the Project properties of the project, through which I can disable the Groovy support, which cleans up build-impl and removes libraries 4. Shut down the IDE and start it with a fresh user dir (this simulates passing the project to another user) 5. Open the Java SE project that was created previously => Groovy panel in Project properties is missing, so there is no straightforward way to disable Groovy in this project.
You are right that this problem is reproducible also with Java SE IDE, and technically existed also in NB 6.5. However, in this scenario is is really easy for the user to figure out what the problem is - if I have a different set of plugins than my coworkers (or than I had when creating the project), I can not expect things to work the same way. And the remedy is obvious - just install the missing modules. In the original scenario I reported, the remedy is very non-obvious: both users downloaded the same bits, and they are seeing different results, and it is not clear why. This is a much more serious problem than what you describe. So before the "ergonomics" changes, this was a P4 problem, now it is a P2. I think the fix should be to make it much more obvious to the user that some features are disabled, and make it very easy to enable them - or even force the user to make the choice about which features to enable. See also the UI spec: http://wiki.netbeans.org/FitnessForeverUISpec. This is an analogous case to issue 155030.
From the "ergonomics" point of view this is dupe of 155030. Fixed in ergonomics#a43491db21a2 Leaving open as P3 in a hope that one day users of Java SE edition will be warned when they open groovy extended project.
*** Issue 156910 has been marked as a duplicate of this issue. ***
*** Issue 157116 has been marked as a duplicate of this issue. ***
Integrated into 'main-golden', will be available in build *200901250201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/a43491db21a2 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #155032: Recognize groovy extension point
I'm closing this one as WONTFIX. No-one ever complain about this behavior and it's here for almost 4 years. And actually I don't even think, that we should want user everytime when opening java-with-groovy project. BTW: In the current dev build, there is no way to disable Groovy in project properties.