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.
Recently, I've noticed that the editor doesn't seem to be able to resolve some required projects. This has wide consequences. For instance: I open project G and tell the dialog to open the required projects as well. The IDE CORRECTLY opens all the required projects, so I end up with: Projects A, B, C, D, E, F, G open - let's imagine that: B depends on A D depends on C E depends on A, B, D F depends on A, B, D, E G depends on A, F Now it happens that G compiles correctly (all is ok on the Ant side) but: - The editor keeps telling me that class XYZ (from F) used in a G file doesn't exist - When I tell a file in F to implement all the abstract methods of the E interface that it implements, the method definitions don't use the argument names found in E, so I end up with public foo(Bar arg0, boolean arg1) instead of public foo(Bar desiredBar, boolean certify) - When I try to navigate to a file defined in a required project, it won't (plays the sound), just as if it were defined in a jar for which I had no source. - When I try to refactor a method's name of an E class from within F, it says it can't refactor it because the project (E) isn't open (even though it of course is - though I should it mention is was opened recursively by G, not directly by F or me) - On refactoring a method's name of an E class from E, it raises an exception - something to do with 'Spring'(?) - and refactoring isn't reflected on usages of the method in F. Probably there are more side effects - the underlying thing is that the IDE doesn't figure out the relationship between the open projects - even though it opened them as 'required'. Sometimes, a complete build of G will solve problems temporarily - but only sometimes, and if I just build, say E, F doesn't seem to take notice. This problem has been around only recently. I should perhaps mention that I have setup all projects build and dist directories to subdirs of a central location, but that was quite a while ago and didn't break anything at the time. I should also mention that I've setup the projects to use a 'shared library'. This seems to have made it worse. Before, some of these problems happened, but if I opened the unrecognised files in the editor, they did become recognised, with all their current API. Notice that the required projects are added as such, having nothing to do with the shared library thing. Finally, G is a web project, for which the IDE didn't allow the use of a'shared library' (last time I looked), so I added the library's definition directly into its project.xml. BTW, if projects use shared libraries, it's more than likely that a web project will depend on one of those projects and so need access to it as well... and why is it, also, that one can't create shared libraries at will - only through a project - and can only include libs from one library at a time? I think these issues are major, at least for anyone who has to use projects with dependencies.
The E, F and G are wrongly set up, missing dependency on C, but I don't know if it's a case of this bug.
I should correct myself: 1 - E, F & G do not need C to compile - they just need it to run, but they only 'run' inside G 2 - G depends on all of them, not only A and F - it only needs A/F to compile, but needs all of them to run because of point 1.
Created attachment 57098 [details] Example projects to reproduce the problem.
I have found a problem that is quite likely the root cause for the problems described here. Steps to reproduce: 1. download the attached package, unpack. 2. do *not* build the projects 3. start an IDE, open the projects - the reference to a.A in b.Main is marked as unresolvable 4. build the projects - the reference becomes resolvable, but an attempt to rename it fails (~"the project is not open") 5. restart the IDE - the everything works OK now. 6. clean the projects and restart the IDE - everything is back to 3 again. The root cause of this problem is that the projects have dist folder defined outside there project dir, and the build artifacts do not exist at the time the IDE starts up. The SourcesHelper does not mark non-existing external roots as being owned by the given project (uses FileObjects instead of URIs). The Java infrastructure asks the SourceForBinaryQuery (which delegates to ProjectSourceForBinaryQuery) to find sources for the project output jar. FileOwnerQuery is used to find owning Project, but it is (obviously) not found. This in turn results into inability to resolve the reference to a.A. Please note that the SFBQ itself works over URLs, and can therefore handle non-existing files/folders. I think that there are at least two places where this needs to be fixed: -SourcesHelper must use URI to register the external roots instead of FileObjects -although there is FileOwnerQuery.getOwner(URI), I do not think it can work for a URI that denotes a file that is itself non-existent, and whose parents are either non-existent, or not owned by the same project as the file itself. A workaround is to keep the projects built (especially during IDE startup).
*** Issue 85348 has been marked as a duplicate of this issue. ***
This issue is not new, it works this way since new ant based projects were introduced. This issue can only be reproduced if user modifies property 'dist.dir' in project.properties file by hand and also if those projects in question are not built during IDE startup. Workaround can be either have those projects built before starting IDE or don't let clean target to delete the ${dist.dir} folder, but only its content. It could be done by adding following snippet into build.xml of the project: <target name="-post-clean"> <mkdir dir="${dist.dir}"/> </target> Due to these facts I'm lowering priority to standard P3. Setting TM to future, because fix will require changes in very core parts of projects infrastructure, which will not be done for 6.1 release.
Changes to external root registration logic are too risky for 6.9.
still reproducible.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss