New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IDE loads projects which are not open #25

Closed
basiliscus opened this Issue Nov 17, 2012 · 28 comments

Comments

Projects
None yet
4 participants
@basiliscus
Contributor

basiliscus commented Nov 17, 2012

The first day I started playing with the plugin, I created a test project.
After some experiments I closed the project and forgot about it.

Now, while working on a real project, I am constantly notified about errors in that closed test project.
The errors themselves are correct, but I expect IDE would not try to load the closed projects. It is likely to cause performance issues, if the closed project is large or if there is a number of them.
I tried to clear the cache in netbeans userdir folder, but that didn't help.

The exception I unexpectedly get is as follows:

Failed to load Gradle project: Ecwid-gradle
org.gradle.tooling.BuildException: Could not fetch model of type 'IdeaProject' using Gradle installation '/usr/share/gradle'.
at org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:53)
at org.gradle.tooling.internal.consumer.async.DefaultAsyncConnection$3.run(DefaultAsyncConnection.java:81)
at org.gradle.messaging.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.gradle.api.internal.LocationAwareException: Build file '/Users/basil/Ecwid-gradle/gradle-run-tasks/build.gradle' line: 31
A problem occurred evaluating project ':gradle-run-tasks'.
at org.gradle.initialization.DefaultExceptionAnalyser.transform(DefaultExceptionAnalyser.java:85)
at org.gradle.initialization.MultipleBuildFailuresExceptionAnalyser.transform(MultipleBuildFailuresExceptionAnalyser.java:47)
at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:115)
at org.gradle.initialization.DefaultGradleLauncher.getBuildAnalysis(DefaultGradleLauncher.java:92)
at org.gradle.tooling.internal.provider.BuildModelAction.run(BuildModelAction.java:70)
at org.gradle.tooling.internal.provider.DelegatingBuildModelAction.run(DelegatingBuildModelAction.java:44)
at org.gradle.tooling.internal.provider.ConfiguringBuildAction.run(ConfiguringBuildAction.java:95)
at org.gradle.launcher.exec.InProcessGradleLauncherActionExecuter.execute(InProcessGradleLauncherActionExecuter.java:39)
at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:45)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:42)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:24)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.StartStopIfBuildAndStop.execute(StartStopIfBuildAndStop.java:33)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.ReturnResult.execute(ReturnResult.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:70)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:68)
at org.gradle.util.Swapper.swap(Swapper.java:38)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:68)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:60)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:59)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:45)
at org.gradle.launcher.daemon.server.DaemonStateCoordinator.runCommand(DaemonStateCoordinator.java:186)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy.doBuild(StartBuildOrRespondWithBusy.java:49)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.HandleStop.execute(HandleStop.java:36)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.CatchAndForwardDaemonFailure.execute(CatchAndForwardDaemonFailure.java:32)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.DefaultDaemonCommandExecuter.executeCommand(DefaultDaemonCommandExecuter.java:48)
at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.handleCommand(DefaultIncomingConnectionHandler.java:155)
at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.receiveAndHandleCommand(DefaultIncomingConnectionHandler.java:128)
at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.run(DefaultIncomingConnectionHandler.java:116)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
... 3 more
Caused by: org.gradle.api.GradleScriptException: A problem occurred evaluating project ':gradle-run-tasks'.
at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:54)
at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:127)
at org.gradle.configuration.BuildScriptProcessor.evaluate(BuildScriptProcessor.java:38)
at org.gradle.configuration.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:43)
at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:463)
at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:75)
at org.gradle.configuration.ProjectEvaluationConfigurer.execute(ProjectEvaluationConfigurer.java:23)
at org.gradle.configuration.ProjectEvaluationConfigurer.execute(ProjectEvaluationConfigurer.java:21)
at org.gradle.api.internal.Actions$CompositeAction.execute(Actions.java:67)
at org.gradle.api.internal.Actions$TransformingActionAdapter.execute(Actions.java:96)
at org.gradle.api.internal.project.AbstractProject.configure(AbstractProject.java:439)
at org.gradle.api.internal.project.AbstractProject.allprojects(AbstractProject.java:434)
at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:32)
at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:142)
at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:113)
at org.gradle.initialization.DefaultGradleLauncher.getBuildAnalysis(DefaultGradleLauncher.java:92)
at org.gradle.tooling.internal.provider.BuildModelAction.run(BuildModelAction.java:70)
at org.gradle.tooling.internal.provider.DelegatingBuildModelAction.run(DelegatingBuildModelAction.java:44)
at org.gradle.tooling.internal.provider.ConfiguringBuildAction.run(ConfiguringBuildAction.java:95)
at org.gradle.launcher.exec.InProcessGradleLauncherActionExecuter.execute(InProcessGradleLauncherActionExecuter.java:39)
at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:45)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:42)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:24)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.StartStopIfBuildAndStop.execute(StartStopIfBuildAndStop.java:33)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.ReturnResult.execute(ReturnResult.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:70)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:68)
at org.gradle.util.Swapper.swap(Swapper.java:38)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:68)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:60)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:59)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:45)
at org.gradle.launcher.daemon.server.DaemonStateCoordinator.runCommand(DaemonStateCoordinator.java:186)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy.doBuild(StartBuildOrRespondWithBusy.java:49)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.HandleStop.execute(HandleStop.java:36)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.CatchAndForwardDaemonFailure.execute(CatchAndForwardDaemonFailure.java:32)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:126)
at org.gradle.launcher.daemon.server.exec.DefaultDaemonCommandExecuter.executeCommand(DefaultDaemonCommandExecuter.java:48)
at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.handleCommand(DefaultIncomingConnectionHandler.java:155)
at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.receiveAndHandleCommand(DefaultIncomingConnectionHandler.java:128)
at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.run(DefaultIncomingConnectionHandler.java:116)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
Caused by: org.gradle.api.tasks.TaskInstantiationException: Could not create task of type 'NodeExec'.
at org.gradle.api.internal.project.taskfactory.TaskFactory$1.call(TaskFactory.java:115)
at org.gradle.api.internal.project.taskfactory.TaskFactory$1.call(TaskFactory.java:110)
at org.gradle.api.internal.AbstractTask.injectIntoNewInstance(AbstractTask.java:126)
at org.gradle.api.internal.project.taskfactory.TaskFactory.createTaskObject(TaskFactory.java:110)
at org.gradle.api.internal.project.taskfactory.TaskFactory.createTask(TaskFactory.java:70)
at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory.createTask(AnnotationProcessingTaskFactory.java:93)
at org.gradle.api.internal.project.taskfactory.DependencyAutoWireTaskFactory.createTask(DependencyAutoWireTaskFactory.java:39)
at org.gradle.api.internal.tasks.DefaultTaskContainer.add(DefaultTaskContainer.java:50)
at org.gradle.api.internal.project.AbstractProject.task(AbstractProject.java:916)
at org.gradle.api.internal.BeanDynamicObject$MetaClassAdapter.invokeMethod(BeanDynamicObject.java:216)
at org.gradle.api.internal.BeanDynamicObject.invokeMethod(BeanDynamicObject.java:122)
at org.gradle.api.internal.CompositeDynamicObject.invokeMethod(CompositeDynamicObject.java:147)
at org.gradle.groovy.scripts.BasicScript.methodMissing(BasicScript.java:83)
at build_2hcnggaahfk5o8cl8cipp2ddug.run(/Users/basil/Ecwid-gradle/gradle-run-tasks/build.gradle:56)
at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:52)
... 55 more
Caused by: groovy.lang.MissingPropertyException: Could not find property 'ecwid.db.user' on project ':gradle-run-tasks'.
at org.gradle.api.internal.AbstractDynamicObject.propertyMissingException(AbstractDynamicObject.java:43)
at org.gradle.api.internal.AbstractDynamicObject.getProperty(AbstractDynamicObject.java:35)
at org.gradle.api.internal.CompositeDynamicObject.getProperty(CompositeDynamicObject.java:94)
at org.gradle.api.internal.project.DefaultProject_Decorated.getProperty(Unknown Source)
at JettyExec.copyProperty(/Users/basil/Ecwid-gradle/gradle-run-tasks/build.gradle:31)
at JettyExec.(/Users/basil/Ecwid-gradle/gradle-run-tasks/build.gradle:15)
at NodeExec.(/Users/basil/Ecwid-gradle/gradle-run-tasks/build.gradle)
at NodeExec_Decorated.(Unknown Source)
at org.gradle.api.internal.DependencyInjectingInstantiator.newInstance(DependencyInjectingInstantiator.java:62)
at org.gradle.api.internal.ClassGeneratorBackedInstantiator.newInstance(ClassGeneratorBackedInstantiator.java:36)
at org.gradle.api.internal.project.taskfactory.TaskFactory$1.call(TaskFactory.java:113)
... 69 more

@kelemen

This comment has been minimized.

Owner

kelemen commented Nov 17, 2012

Despite what one might think NB loads projects even if they are not open. This is necessary for it for different reasons. For example, if you open a file, then it tries to figure out what is the encoding of the file. For this, NB first looks up the project containing it then asks the encoding. However, if NB only asks the plugin for the encoding it will not trigger a full load of the project, so there must be something else.

What are you editing while this happens? That is, what you edit is in waht relation with this project?

@kelemen

This comment has been minimized.

Owner

kelemen commented Nov 17, 2012

Regadless, do you know what you did which might have triggered the load of the project model? Preventable project model loads should be avoided. That is, I check at a lot of places if I can get away without loading the model.

@basiliscus

This comment has been minimized.

Contributor

basiliscus commented Nov 17, 2012

Ok, I've found 2 patterns which cause the project loads:

  1. When the "File -> Open recent file" menu item gets active (without even touching any files in that menu).
  2. When a node, containing the project, becomes visible in Favorites.
@kelemen

This comment has been minimized.

Owner

kelemen commented Nov 17, 2012

Maybe I shouldn't have try it in a folder containing lots of Gradle projects :) Yes, it seems I can reproduce this one. I will see why the model loading occurs.

@kelemen

This comment has been minimized.

Owner

kelemen commented Nov 17, 2012

It seems that NetBeans attempts to query the classpath for anything seen in the project window or the "Open recent file". From the callstack, I believe it does this to show an error badge if required. I believe this due to this stacktrace:

org.netbeans.gradle.project.query.GradleClassPathProvider.findClassPath(GradleClassPathProvider.java:480)
org.netbeans.modules.java.project.ProjectClassPathProvider.findClassPath(ProjectClassPathProvider.java:73)
org.netbeans.api.java.classpath.ClassPath.getClassPath(ClassPath.java:628)
org.netbeans.modules.parsing.impl.indexing.errors.ErrorAnnotator$1.run(ErrorAnnotator.java:315)
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1452)
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2032)

I have applied a minor hack which prevents loading the model in some cases (i.e.: I will assume that there is no classpath for the project directory itself). This prevents the project to be loaded if you do not unfold its directory.

@basiliscus

This comment has been minimized.

Contributor

basiliscus commented Nov 18, 2012

  1. When a node, containing the project, becomes visible in Favorites.

Confirm, this issue is resolved.
The load still triggers if a project node is expanded. Perhaps, that is expected behaviour (although undesirable).

  1. When the "File -> Open recent file" menu item gets active (without even touching any files in that menu).

This issue still remains unfortunately.
However, knowing what causes the problem, I think I can live with it :)

@kelemen

This comment has been minimized.

Owner

kelemen commented Nov 18, 2012

This is not a complete solution but I don't think I can make it any better. However, I reported the issue to NetBeans, so they might fix the issue: http://netbeans.org/bugzilla/show_bug.cgi?id=222330

@kelemen kelemen closed this Nov 18, 2012

@kelemen

This comment has been minimized.

Owner

kelemen commented May 19, 2013

I'm in the process of a major refactoring to allow other plugins extend Gradle Support. Being extensible however will bring this issue back (I simply could not find a way to solve it). I have also reopened the issue reported to NetBeans developers asking them to reconsider the issue.

@kelemen kelemen reopened this May 19, 2013

@shevek

This comment has been minimized.

shevek commented Dec 14, 2013

I hit this in the file-open dialog with plugin 1.2.8 and gradle 1.9

@kelemen

This comment has been minimized.

Owner

kelemen commented Dec 14, 2013

That one is triggered if you click on a node (not on the unfold "+" sign) because NB tries to enumerate the subprojects, even though I do not support that query, I load the project if extensions do. Altough, if I assumed that extensions do not provide such queries as well (and they certainly don't at the moment), I can hack around this issue. I'll see if I can solve this before the next release.

@shevek

This comment has been minimized.

shevek commented Dec 14, 2013

It's not as much of an issue for me as some of the other issues. It only happens when I open a project. I spend far more time editing and building than opening, so I'm happy for opening to be slow/buggy as long as once it's open, building is fast, reliable and convenient. I'd rather focus on the things I spend more time doing!

@kelemen

This comment has been minimized.

Owner

kelemen commented Dec 28, 2013

This issue should now be fixed in master once again.

@kelemen kelemen closed this Dec 28, 2013

@eskatos

This comment has been minimized.

Contributor

eskatos commented Feb 16, 2015

Not-opened projects are still loading when browsing files/folders in the Favorites view. This can slow Netbeans a serious amount of time depending on the projects you encounter while looking for the simple file you want to open.

In my case, I use the Favorites view extensively and face the issue daily using Netbeans 8.0.2, Gradle Support 1.3.2 and Gradle 2.1.

I'm not sure if this issue is what I describe. Tell me if I need to open another one.

@kelemen

This comment has been minimized.

Owner

kelemen commented Feb 16, 2015

What do you mean on "browsing files"? Do you unfold project folders?

@eskatos

This comment has been minimized.

Contributor

eskatos commented Feb 16, 2015

@kelemen no, I simply "pass over" them using the keyboard

@kelemen

This comment has been minimized.

Owner

kelemen commented Feb 16, 2015

Can you send me your messages.log (log of NetBeans) after this "automatic project loading" happens? The log should be in ~/NetBeans/8.0/var/log/messages.log. You can send it in a pastebin link or e-mail, whatever you prefer.

@eskatos

This comment has been minimized.

Contributor

eskatos commented Feb 16, 2015

Here is what gets written to messages.log when focusing a node of a folder that contains a gradle project in the favorites view: https://gist.github.com/eskatos/c703631f03438f27ec7c

It does not matter if the node is focused using keyboard or pointer-click. So it seems the load trigger without expanding the node.

Maybe I should have mentioned that earlier: I'm on a mac.

@kelemen

This comment has been minimized.

Owner

kelemen commented Feb 16, 2015

It seems I have to add an exception for org.netbeans.spi.project.ProjectConfigurationProvider the same way as it is done with ProjectInformation in ProjectLookupHack. (hopefully nothing else is needed).

@eskatos

This comment has been minimized.

Contributor

eskatos commented Feb 16, 2015

Good. Let me know when you need me to try upcoming changes.

@kelemen

This comment has been minimized.

Owner

kelemen commented Feb 17, 2015

I have updated master to no longer cause the project to be fully loaded in the above case (though of course, NB might request something else which cause the project to be loaded, so it must be verified that this exception is enough).

@eskatos

This comment has been minimized.

Contributor

eskatos commented Feb 18, 2015

Building ... Running .... project loading still trigger but for new types.

I first added org.netbeans.gradle.project.java.JavaExtension, then org.netbeans.spi.queries.SharabilityQueryImplementation2 but then one request type is still triggering project load: org.netbeans.modules.web.browser.spi.ProjectBrowserProvider

Unfortunately this one is not in netbeans-gradle-plugin dependencies so I can't add it's class to the black-list. ProjectBrowserProvider comes from the netbeans web module.

I have the gut feeling that depending on what modules are installed in the IDE this black list won't be enough to get predictable behaviour. Sadly I don't know Netbeans APIs well so I'm a bit stuck here.

Shouldn't it be possible to reverse the thing going for a white list instead?

@kelemen

This comment has been minimized.

Owner

kelemen commented Feb 18, 2015

I cannot whitelist them because I have no idea (i.e., I don't want to have) what an extension of this plugin might need. I will add those then to check by name rather than Class instance.

@eskatos

This comment has been minimized.

Contributor

eskatos commented Feb 18, 2015

Fair enough. I can work on this using names rather than Class instances and propose a PR if that's ok for you?

@kelemen

This comment has been minimized.

Owner

kelemen commented Feb 18, 2015

I will gladly accept such pull request.

@eskatos

This comment has been minimized.

Contributor

eskatos commented Feb 18, 2015

Ok, let's go.

@eskatos

This comment has been minimized.

Contributor

eskatos commented Feb 18, 2015

Cool.

Now about loading projects when the project-folder node is unfolded. Is there a rationale to it or could we prevent this loading to happen?

@kelemen

This comment has been minimized.

Owner

kelemen commented Feb 18, 2015

It cannot be easily done because the reason it is loaded is that NetBeans queries the class path for the directories listed. It is however indistinguishable for the plugin why NB asks for the class path (e.g., the editor does so as well for unopened dependencies), so in general the plugin must respond to the best of its abilities. I have asked NB developers that NB should not ask for the class path for each directory listed in favorites. I can't remember the reason why they chose not to do it.

@eskatos

This comment has been minimized.

Contributor

eskatos commented Feb 18, 2015

Ok, I can live with that. Thanks for your support @kelemen!
Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment