Details
-
Type:
Bug
-
Status:
Resolved
-
Resolution: Fixed
-
Affects Version/s: 1.0-milestone-3, 1.0-milestone-4
-
Fix Version/s: 1.0-milestone-7
Description
Problem
To support reporting and output listeners, gradle does advanced manipulation of logging, e.g. resets the java logging and replaces standard streams, etc. This approach is fine if gradle owns the process (e.g. running gradle from console, running against daemon, etc.). However, when gradle is embedded via tooling api then it shouldn't really manipulate the jvm-global logging commodities.
Resolution
Gradle does not manipulate jvm-global logging commodities when embedded (e.g. when Tooling Api used).
Symptoms
When tooling-api is used inside of the NetBeans container (e.g. in gradle NetBeans plugin) then NB editors break and stop showing contents. Reported initially by geertjan.wielenga@oracle.com
Steps to reproduce:
- Install NetBeans IDE 7.0.1.
- Checkout sources of the gradle NB support (Geertjan can provide access or attach the sources zip to this issue) and open the project in NB
- Bump the memory settings to avoid permgen errors. Add following line to the platform.properties file:
run.args.extra=-J-XX:MaxPermSize=512m
- Right-click the module in 7.0.1 and choose Run. A new instance of NetBeans starts up, with the module installed.
- If the project does not build you need to re-add some library dependencies. In my case I needed to delete Project UI Api library and add it again.
- Go to the "Tools" menu in the main menu bar and choose "Options". (On Mac options are at apple+i)
- Click the "Gradle" tab and set the location of your Gradle distribution on disk. (Do not use the optional section for verifying the Gradle location, because that is going to do a Gradle build, which will create the problem too soon.). I was able to reproduce with M3, M4 and master.
- Now go to the New Project dialog (Ctrl-Shift-N) and then Java | Java Application. Click Next and then click Finish.
- Right-click "Gradle Project Files" (or the Gradle project node or any node except Libraries) and choose New | Desktop. Click Finish.
- If the Navigator isn't open (Window | Navigating | Navigator), open it, and when you select the Gradle file in "Gradle Project File", you will see all the tasks. And, from now onwards, all the documents you create in the IDE will be blank in the editor.
Expected behavior: editors show file contents.
It appears that when we do connection.getModel(...) and effectively tell the daemon to do something (regardless if the deamon was already started or has just been started) then editors in NB stop showing any content (tested with couple various editors, e.g. java,html,etc). You can click on a java file but the editor is blank (even though the file has contents - checked outside NB).
(DEPRECATED We used to think that the problem is due to the daemon) Potential resolutions/next steps:
- Provide a switch in tooling-api to work in daemon-less way. Geertjan is very keen on that. This could help diagnosing the problem. (Szczepan) I'm ok with that switch, it's even consistent with our main api, where such switch already exists.
- Show that issue to some NetBeans overlord who knows the nitty-gritty behind loading the editor contents in NB. E.g. what can possibly go wrong, if contents do not load then where is the stack trace, etc.
- Do some further debugging with NB + local versions of tooling api/gradle. This way we can find out what exactly the problem is, though it might take time.
We should start with option 1, as such a switch already exists as DefaultGradleConnector.embedded(boolean). (don't specify the distribution to use - leave it as the default).
If things work with embedded(true), we should dig to find out why embedded(false) does not work. And of course, if things don't work with embedded(true), we should also dig to find out why neither of them work. ie, we should do 3 as well as 1.