search

kelemen / netbeans-gradle-project

This project is a NetBeans plugin able to open Gradle based Java projects. The implementation is based on Geertjan Wielenga's plugin.
172 stars 57 forks source link

"No projects in this build have project directory" error #308

Closed asleson closed 7 years ago

asleson commented 7 years ago

Hi,

I'm a longtime NetBeans user but I'm fairly new to Gradle.

I have a bunch of Gradle projects open in NetBeans. All the projects I have open are in the same directory, so something like this:

rootProjectDir
    -> project1
    -> project2
    -> etc

In many of my projects I have a run task defined in the build.gradle file, so when I have that project's build.gradle file as the active file in the editor, or any file from that project as the active editor, I can just hit F6 to do a build.

The problem I consistently see is I get an error like this:

Executing: gradle :cbr-runtime:run
Arguments: [-PcmdLineArgs=, -PcbrTomcatClasspathBase=/Users/asleson/dev/cbr-tomcat-classpath-base, -c, /Users/asleson/dev/github/hc-cbr/cbr-component-recognitionpoc/settings.gradle]

FAILURE: Build failed with an exception.

* What went wrong:
No projects in this build have project directory '/Users/asleson/dev/github/hc-cbr/cbr-runtime'.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 0.045 secs

Build failure (see the Notifications window for stacktrace): gradle :cbr-runtime:run

The problem is that I have the build.gradle file for the cbr-runtime project open in the editor, but you can see from the Arguments line, it's trying to use the settings.gradle file from another project named cbr-component-recognitionpoc. The cbr-runtime and cbr-component-recognitionpoc projects have the same parent directory as shown above.

I try right-clicking on the cbr-runtime project and selecting Reload but it doesn't help. However, if I close NetBeans and reopen it, and then hit the F6 button again, then the build runs properly.

It's almost as if the parts of a previous build are incorrectly reused in a subsequent build, even when the later build is a different project entirely.

Is there something I'm doing wrong, or is this a bug? Having to close and reopen NetBeans all the time is a real productivity killer.

According to the NetBeans plugin manager, I have version 1.3.9.2 installed, and is apparently up to date.

Thank you!!!

Ryan

kelemen commented 7 years ago

I think you are experiencing the same as in #307. If so, there are two workaround at the moment (see the mentioned issue). In short, the cause is that when you load a project, the plugin checks if the guessed root project contains it as a subproject. If the project you are loading was created after the root project have been loaded, the plugin will think that it is not part of that build but a new separate one. The simplest thing to do is to always reload the root project (it will reload everything anyway).

asleson commented 7 years ago

OK, thanks for the comment. As I said I'm new to Gradle, and I think I have a web of project dependencies that I need to unwind that should help. I'm working on that now.

kelemen commented 7 years ago

I have added a fix to master which should work in the vast majority of the cases. It would be nice if you could build the plugin from the sources and verify if it solves your issue.

asleson commented 7 years ago

Thank you! Sorry for the late reply. I did some refactoring of my projects (making the projects depending on outputs that were put into Maven local rather than depending on other projects) so the problem mostly went away. I'll try to grab the source code soon and build it and give it a try and let you know. Thank you!!

asleson commented 7 years ago

OK, quick question: I downloaded the master branch zip and ran the build task. It look like there are a few directories with build outputs: netbeans-gradle-default-models and netbeans-gradle-plugin. Do I only need to uninstall my current Gradle plugin, and then install the netbeans-gradle-plugin-1.3.9.2.0.1.jar file? Or do I need to do something with the output in the models directory? Just want to make sure I don't blow up my current NetBeans installation.

kelemen commented 7 years ago

You have to install the nbm from netbeans-gradle-plugin/build/nbm as with any other plugin (in Tools/Plugins). NetBeans won't let you downgrade a plugin, so if you already have the same plugin with a higher version number, you are forced to uninstall the plugin first, otherwise uninstall is not needed.

asleson commented 7 years ago

Hi, apologies for the late reply as the holidays got in the way. I installed the .nbm that I build from master (1.3.9.2.0.1) and so far I haven't had any problems. As I said earlier, I actually unwound a bunch of my projects (they now rely on artifacts from my local Maven repository rather than on other projects) so many of the problems I was seeing went away.

Thank you so much for the reply and fixes!!!

asleson commented 7 years ago

Not sure if this is the Gradle plugin update or something else, but sometimes when I reload a different project, Netbeans says there an error. These are the error details:

java.lang.ClassCastException: java.io.File cannot be cast to java.lang.String
    at java.util.Properties.store0(Properties.java:834)
    at java.util.Properties.store(Properties.java:818)
    at org.netbeans.gradle.project.DefaultGlobalSettingsFileManager$2.run(DefaultGlobalSettingsFileManager.java:171)
    at org.netbeans.gradle.project.DefaultGlobalSettingsFileManager$2.run(DefaultGlobalSettingsFileManager.java:149)
    at org.netbeans.gradle.project.DefaultGlobalSettingsFileManager$Locker.doWrite(DefaultGlobalSettingsFileManager.java:366)
    at org.netbeans.gradle.project.DefaultGlobalSettingsFileManager.persistSettingsDefsNow0(DefaultGlobalSettingsFileManager.java:149)
    at org.netbeans.gradle.project.DefaultGlobalSettingsFileManager.persistSettingsDefsNow(DefaultGlobalSettingsFileManager.java:130)
    at org.netbeans.gradle.project.DefaultGlobalSettingsFileManager.access$000(DefaultGlobalSettingsFileManager.java:36)
    at org.netbeans.gradle.project.DefaultGlobalSettingsFileManager$1.run(DefaultGlobalSettingsFileManager.java:123)
    at org.jtrim.concurrent.GenericUpdateTaskExecutor$PollAndExecuteTask.execute(GenericUpdateTaskExecutor.java:119)
[catch] at org.jtrim.concurrent.Tasks.executeTaskWithCleanup(Tasks.java:272)
    at org.jtrim.concurrent.InOrderTaskExecutor$TaskDef.doTask(InOrderTaskExecutor.java:198)
    at org.jtrim.concurrent.InOrderTaskExecutor.dispatchTasks(InOrderTaskExecutor.java:68)
    at org.jtrim.concurrent.InOrderTaskExecutor.access$100(InOrderTaskExecutor.java:19)
    at org.jtrim.concurrent.InOrderTaskExecutor$3.execute(InOrderTaskExecutor.java:153)
    at org.jtrim.concurrent.AbstractTaskExecutorService$FunctionWrapper.execute(AbstractTaskExecutorService.java:270)
    at org.jtrim.concurrent.AbstractTaskExecutorService$TaskOfAbstractExecutor.execute(AbstractTaskExecutorService.java:340)
    at org.jtrim.concurrent.Tasks$RunOnceCancelableTask.execute(Tasks.java:342)
    at org.jtrim.concurrent.ThreadPoolTaskExecutor$ThreadPoolTaskExecutorImpl$QueuedItem.runTask(ThreadPoolTaskExecutor.java:1213)
    at org.jtrim.concurrent.ThreadPoolTaskExecutor$ThreadPoolTaskExecutorImpl$Worker.executeTask(ThreadPoolTaskExecutor.java:1049)
    at org.jtrim.concurrent.ThreadPoolTaskExecutor$ThreadPoolTaskExecutorImpl$Worker.processQueue(ThreadPoolTaskExecutor.java:1153)
    at org.jtrim.concurrent.ThreadPoolTaskExecutor$ThreadPoolTaskExecutorImpl$Worker.run(ThreadPoolTaskExecutor.java:1182)
    at org.jtrim.concurrent.ThreadPoolTaskExecutor$ThreadPoolTaskExecutorImpl$Worker$1.run(ThreadPoolTaskExecutor.java:998)
    at java.lang.Thread.run(Thread.java:745)
kelemen commented 7 years ago

Can you update the project? I believe that this issue was solved.

psimonazzi commented 7 years ago

Hi, I'm starting to get this error since v1.4.0. I have several projects at the same dir level, and one of them includes the others (using the include directive in its settings.gradle), so it's not a "traditional" Gradle tree with one root dir and subdirs. After updating the plugin, when I open the projects in Netbeans it fails with this error, and I can see in the output log "Arguments: " that it is trying to use the settings.gradle of another project (random?). It seems like it fails to guess the "root" project.

I tried to load just one project at a time, and reopening Netbeans, but it fails anyway. I actually opened the exact same projects on another PC with the same version of the plugin, and there it works correctly.

Thanks

kelemen commented 7 years ago

@psimonazzi If you are getting this issue since v1.4.0 it is not the same issue. Can you open another issue? In that issue, please write down the exact directory structure of your projects. It would be even better if you could share a project with which I can reproduce the issue with. As a workaround, you can try disabling the "Load root project first" in the global settings: Misc/Gradle/Build script parsing.

psimonazzi commented 7 years ago

For now I solved by deleting all .nb-gradle directories in all projects. Now when I open a project that includes another one, it is correctly identified as [root]. Sometimes I get the issue again, maybe depending on the order in which I open projects in Netbeans. I will look into creating a minimal test case.

kelemen commented 7 years ago

A directory layout would still be good because it doesn't surprise me that the issue is non-deterministic (given how NB trys to load projects). Hopefully that would be enough for me to realize what is going on.