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.
Sometimes NetBeans fails to detect any packages in my Maven projects - the only package displayed in the Project tab is <default package> for both Test and Source packages. If I look under the Files tab the folder structure seems absolutely correct and all files are shown as expected. The only way to get the IDE to detect the packages seems to be to restart it, right-clicking the project and selecting reload does not seem to clear the issue.
Created attachment 63479 [details] Log
Created attachment 63480 [details] Screenshot
nothing wrong in the log file. do you have a custom sources location or you go with the default src/main/java? any other details that could help? I've never noticed that myself.
We use for example <path to project>\src\main\java and <path to project>\src\test\java What other info would be helpful to you in figuring it out? There are no error messages or anything odd shown in the interface as far as I can see.
operating system, java version, is there a space in path? do you declare the source root valu or you go with the default? does the project compile when you encounter the issue?
OS: Win XP Java: 1.6.0_06 No spaces in the path. The build fails with an exception: [#verify] [WARN]Attempting to build MavenProject instance for Artifact (org.codehaus.groovy.maven:gmaven-plugin:1.0-rc-3-20080513.065802-3) of type: maven-plugin; constructing POM artifact instead. [groovy:execute] [WARN] Failed to load provider from: org.codehaus.groovy.maven.runtime.loader.artifact.ArtifactProviderLoader@18f73c9 java.lang.NullPointerException org.codehaus.plexus.DefaultPlexusContainer.construct(DefaultPlexusContainer.java:306) org.codehaus.plexus.DefaultPlexusContainer.<init>(DefaultPlexusContainer.java:196) org.codehaus.plexus.aspect.CompatibilityAspect.ajc$interMethod$org_codehaus_plexus_aspect_CompatibilityAspect$org_codehaus_plexus_PlexusContain er$createChildContainer(CompatibilityAspect.aj:69) org.codehaus.plexus.DefaultPlexusContainer.createChildContainer(DefaultPlexusContainer.java:1) org.codehaus.plexus.aspect.CompatibilityAspect.ajc$interMethodDispatch1$org_codehaus_plexus_aspect_CompatibilityAspect$org_codehaus_plexus_Plex usContainer$createChildContainer(CompatibilityAspect.aj) org.codehaus.plexus.aspect.CompatibilityAspect.ajc$interMethod$org_codehaus_plexus_aspect_CompatibilityAspect$org_codehaus_plexus_PlexusContain er$createChildContainer(CompatibilityAspect.aj:28) org.codehaus.plexus.DefaultPlexusContainer.createChildContainer(DefaultPlexusContainer.java:1) org.codehaus.groovy.maven.runtime.loader.artifact.ArtifactProviderLoader.findContainer(ArtifactProviderLoader.java:127) org.codehaus.groovy.maven.runtime.loader.artifact.ArtifactProviderLoader.load(ArtifactProviderLoader.java:78) org.codehaus.groovy.maven.runtime.loader.artifact.ArtifactProviderLoader.load(ArtifactProviderLoader.java:72) org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.load(DefaultProviderSelector.java:192) org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.discover(DefaultProviderSelector.java:154) org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.register(DefaultProviderSelector.java:98) org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.select(DefaultProviderSelector.java:47) org.codehaus.groovy.maven.runtime.loader.DefaultProviderManager.select(DefaultProviderManager.java:91) org.codehaus.groovy.maven.plugin.ProviderMojoSupport.provider(ProviderMojoSupport.java:116) org.codehaus.groovy.maven.plugin.ComponentMojoSupport.doExecute(ComponentMojoSupport.java:58) org.codehaus.groovy.maven.plugin.MojoSupport.execute(MojoSupport.java:69) org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:580) org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498) org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265) org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191) org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149) org.codehaus.mevenide.netbeans.embedder.exec.MyLifecycleExecutor.execute(MyLifecycleExecutor.java:72) org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223) org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304) org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904) org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304) org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) org.codehaus.mevenide.netbeans.execute.MavenJavaExecutor.run(MavenJavaExecutor.java:215) org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:151) [ERROR]The following mojo encountered an error while executing: [ERROR]Group-Id: org.codehaus.groovy.maven [ERROR]Artifact-Id: gmaven-plugin [ERROR]Version: 1.0-rc-3-SNAPSHOT [ERROR]Mojo: execute [ERROR]brought in via: POM JUnit test cases can not be executed (as single files) - it fails with the message "Class XXX does not have a main method".
The build exception seem to occur when the project is correctly loaded as well, so that's probably not related to this. The difference seems to be that after restarting the IDE it does a scan of the project when expanding the package nodes - this does not happen when only the default package is shown.
I've switched to using an external Maven install (2.0.9) instead of the embedded version and I have not seen the problem since. It may be that our project POM's doesn't play nice with Maven 2.1-SNAPSHOT.
well, the embedded vs. command line maven options will only affect the build execution of the project. the project loading (including the resolution of source roots/test source roots) is always done by the embedded version (as it need to be done in the IDE's JVM)
could you provide a sample project with gmaven-plugin setup?
Using dev 200808210201 I had the same behaviour for all old projects I opened. New created opened fine. Strangely now after restarting several times all projects open fine. I'll attach my log file. Bart
Created attachment 68091 [details] logfile
Each opened project(not new ones) is missing the sources. This adds to the logging: INFO [org.netbeans.modules.java.hints.WrongPackageSuggestion]: source cp is either null or does not contain the compiled source cp= If I add a new package to the sources of a defect project, the package is shown. But if I add a Class to that package, it opens in the editor but it's not shown under the package in the project window. I'll add 3 screenshots. First project and the opened class in editor, second the projects and the favorites window. The third one is taken some moment after. The newly created package is disappeared again, only default stays. Some of the projects show the packages, but not the classes. Bart
Created attachment 68093 [details] a missing class in the editor
Created attachment 68094 [details] missing classes in favorites
Created attachment 68095 [details] package dissapeared
are you guys using a version control system? which one? bartvdc: next time please attach the pictures with correct mimetype. you also mention that a new project shows packages while existing ones don't? after restarting the IDE, the "new project" also shows the empty packages?
I'm using subversion. That's also a difference between the new project and the defect ones. The new one is not versioned. The new project stays good all the time.I'll try to put it on subversion. Sorry for the wrong mime type. Shall I resend? Bart
I added the new working project on subversion and it keeps on working. Also after restart, close and reopen.
my gut feeling is that this is not primarily caused by maven projects but by something in the code that constructs the package view.. if you switch to tree view, stuff can be seen normally (to switch, right-click outside on the empty space within the projects view and switch the "View Java Packages as" to Tree view. Thanks.
Changing to tree view does not help for me. The problem stays. I can continue working from the files or favourites window.
I'm using SVN as well, if that's any help.
I upgraded 6.1 and now I have the same behaviour randomly. Restarting fixes it.
I'm trying daily 20080917 now and the problem remains. Also, when a search is done (Ctrl-I) when the sources are gone in projects, the classes are not found. Thus they also disappear in the path used by the search.
Forgot to mention that I also have disappearing sources on local projects, not on svn.
yes, search is most probably iterating the projects view, which is missing the files. I'm still clueless in terms of what could cause the issue. I have maven projects in svn at codehaus.org and never encountered the issue, however I'm using linux+macosx. The problem could be at multiple levels 1. something in maven projects that excludes the files from sources of the project (*if* the package view is sensitive to it) 2. something in svn support that hides these files as "unimportant" 3. the node layer could be responsible as well, see http://www.netbeans.org/issues/show_bug.cgi?id=147709 as an example. 4. something completely different. I'll look into the maven code if I could exclude no 1. from consideration by adding some debug messages that you could turn on..
> 2. something in svn support that hides these files as "unimportant" - svn hides only folders which are versioned by svn and removed localy - never heard about this in relation with an not maven project
I tried to tackle this but still cannot reproduce. I can get a similar state but not the same. I can make the source root content to disappear completely if I either make the <build><directory> folder to equal to src/main/java, or if I create a java ant project for the src/main/java folder (as external source root) and then install maven and open the maven project. That way I get empty <Default package> node under sources. However you get the packages there according to screenshot. Other possible way to simulate your problem, was to add java files to the global ignore list, however the stuff would not be maven specific nor would it help to restart. I will definitely need help from you in terms of describing your project setup or creating a sample project that demonstrates the problem, describe the settings you changed in the IDE, what plugins you installed, attach the messages.log file etc.
The packages are not there, only if you add a new one. I did try to make normal netbeans projects out of it but that was with an other installation. Perhaps I copied too much in the userdir. What part of the userdir keeps track of the sources, what should I delete ? I'll continue tomorrow.
I just had the same with a new installed daily 20080924 with an fresh userdir. But you're right, it is only for the projects which source I once used in a regular ant project. When I open a class from favourites or files and hit ctrl-shift-1 , nb asks to open that other project. I never opened that project with this installation and the userdir has nothing imported. Where does nb keeps the info, what should I delete to fix it?
you should delete the ant project completely. It's possible that it's referenced by other projects you have opened. And actually in 6.5 it's not even necessary to open the project to get it loaded, having it shown in the filechooser when selecting projects is enough. (As the icon is provided by the project, it needs to be loaded). A fresh userdir is also necessary as the external source roots are cached on IDE exit and used on restart until the projects get loaded.
I've deleted the var folder of the userdir, renamed nbproject folder, build.xml and build-profiler.xml in the ant project. Now all goes well. For me, ideally, it should be possible to use the source under an ant and a maven project. Or maven support should change.We had a discussion on the mailing list about this (http://www.nabble.com/worsening-request-maven-support-td17399588.html#a17399588). I'm still a believer of maven as a cross-IDE build tool but it's too heavy to use it for constant edit, compile, build and run. Certainly now with the compile on save feature of 6.5 that doesn't work for maven projects (correct me if I'm wrong). Currently I'm evaluating ivybeans. I'll keep the maven projects but build outside NB(or with ant shortcut)for final deploy and to put on svn. But maybe this should be discussed on the mailing list , not here. One last question: What is the minimum to delete to fix this? What makes a folder an nb project ? Thanks for the fix, Bart
I've added an empty node with a warning and link to this issue whenever the sources source root is not owned by the maven project. http://hg.netbeans.org/main/rev/e8cc135aa452 re: what's the minimum? I think you basically did the minimum, delete/rename of nbproject is essential, the ~/.netbeans/<version>/var directory removal might be optional. I consider the issue fixed. In terms that it should be obvious to future users what is the problem.
Certainly CoS-style quick runs *ought* to work on Maven projects. I think it just has not been implemented yet. Based on my experience with automatic projects, it should not be difficult.
Integrated into 'main-golden', will be available in build *200809270201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/e8cc135aa452 User: Milos Kleint <mkleint@netbeans.org> Log: #138310 whne the sources/test sources are not owned by the maven project, show the warning in project's view.
Milos, Is it possible to clean up the error message further? Ideally it should read "Source folder owned by another project: <name>. See issue #138310 for more information". It's not obvious from the existing error message that simply having another project on disk (even if it doesn't seem to be opened) could be the source of a conflict. The error message should be more explicit about this.
I have seen this error message come up when it shouldn't. The "owned by" project is the very same project! Project X "Source folder owned by another project: Project X. See issue #138310 for more information" NB 7.1 Closing and re-opening the project fixed it. Initially (before noticing this error message) NB complained that it couldn't open the project, but I just selected "Reload POM" and thought that it had worked.
(In reply to comment #37) > The "owned by" project is the very same project! Had you just renamed the project? If so, there might be a bug in the rename handler which ought to be filed separately.
No. No renames. The project name has been the same forever.
Then I have no clue why that would happen. If you manage to reproduce, file a bug.
We just had this issue in one of our projects. I was looking for the solution for days and finally I managed to find out the cause: there was an extra pom.xml in the src/main directory. Probably, I accidentally copied it the wrong dir (instead of the project root dir) and forgot to delete. Hope that helps.
Out of curiosity, *why* can't Maven and Netbeans projects share the same source/test directories? I understand that simply viewing a project in the file chooser is equivalent to opening it but from a usability point of view this doesn't make sense. I think it's quite reasonable (from a usability point of view) for two projects to share the same source/test directories so long as only one project is open at a time (viewing the project name in file chooser should not count as opening the project). Should I file a separate enhancement request for this?
Experienced this problem with multiple JVMs on NetBeans 7.4 on OS X 10.9. Cleared the cache and application support files and started NetBeans again and everything worked. Incidentally was also getting an issue with the Fix Imports context menu failing to complete when invoked, meaning a force quit had to be actioned. That also went away with the clearing of the cache and application support files.
(In reply to genericprodigy from comment #43) > Cleared the cache and application support files and started NetBeans again > and everything worked. I have the same problem as well. What do you mean exactly by "the cache and application support files"? Any specific location? Cheers, --Florent
(In reply to fgeorges from comment #44) > (In reply to genericprodigy from comment #43) > > > Cleared the cache and application support files and started NetBeans again > > and everything worked. > > I have the same problem as well. What do you mean exactly by "the cache and > application support files"? Any specific location? http://wiki.netbeans.org/FaqWhatIsUserdir
The same error message "Source folder owned by another project: Project X" appears if you've opened a subfolder in an existing project a second time by NetBeans, meaning you have a nbproject folder in the root of the project, and then a second nbproject in a subdir somewhere. The error only appears if you close the project and then try to reopen it.
For users of NB 8.1 , this is an issue again : https://netbeans.org/bugzilla/show_bug.cgi?id=256175
Both on Windows 10 and Ubuntu 14.10 with NetBeans IDE 8.1 (Build 201510222201) Java: 1.8.0_66; Java HotSpot(TM) 64-Bit Server VM 25.66-b17 and bundled Maven deliverd by default with Netbeans The problem is still available
same issue here, just cleared everything with nb8.1
I can consistently reproduce this issue when creating a new module in AgroSense (https://bitbucket.org/limetri/agrosense) using NetBeans 8.1 and external maven 3.3.3. Did not happen in 8.0. NetBeans restart solves the problem (although it is a workaround, not very convenient to have to restart NetBeans after every new module added). Product Version: NetBeans IDE 8.1 (Build 201510222201) Java: 1.8.0_66; Java HotSpot(TM) 64-Bit Server VM 25.66-b17 Runtime: Java(TM) SE Runtime Environment 1.8.0_66-b17 System: Linux version 3.16.0-38-generic running on amd64; UTF-8; en_US (nb) Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T13:57:37+02:00)
One thing I noticed: After creating a new module, right clicking on that module's project node shows "Close 2 projects" instead of "Close project". When deleting that new module, it will first ask confirmation to remove the newly created module, secondly it will ask permission to remove the parent as well. Could the parent project somehow end up in the new module's project node's lookup and causing this issue?
I've just reported issue 257978 and made it P2. We probably don't need both issues and can close one of them. The one that stays open would however deserved to be P2. The behavior described in bug 257978 is an annoying regression.
the last few reports very likely address a regression fixed in issue #256175
(In reply to _ gtzabari from comment #42) > Out of curiosity, *why* can't Maven and Netbeans projects share the same > source/test directories? I understand that simply viewing a project in the > file chooser is equivalent to opening it but from a usability point of view > this doesn't make sense. I think it's quite reasonable (from a usability > point of view) for two projects to share the same source/test directories so > long as only one project is open at a time (viewing the project name in file > chooser should not count as opening the project). > > Should I file a separate enhancement request for this? I have this same question. We have a web service project that we want to do kind of a soft fork with - that is, we want to have two projects which share the same sources and everything, just have different names and web contexts so they can be deployed as two different projects. To accomplish this, we set up the second project with only src/main/webapp/META-INF/context.xml and a pom.xml file which points to the source directory of the first project. In doing so, we can no longer browse the source packages from the first project as it just shows the aforementioned message about the source packages being owned by the second project. Relevant details: Product Version: NetBeans IDE 8.1 (Build 201510222201) Updates: NetBeans IDE is updated to version NetBeans 8.1 Patch 1 Java: 1.8.0_77; Java HotSpot(TM) 64-Bit Server VM 25.77-b03 Runtime: Java(TM) SE Runtime Environment 1.8.0_77-b03 System: Linux version 3.13.0-83-generic running on amd64; UTF-8; en_US (nb) second project was created by another developer in svn. the message is displayed on the first project's Source Pakcages node after updating and opening the second project.