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.
In the Projects and Files navigation areas (see attached image), projects show their name, not the directory name. This makes it very difficult to find a project, like say, a maven project or a module project, which has a name that is very different from the directory name where it resides. This is especially true if you have 50 of those open. I was not able to find a way in the IDE to change the described way of viewing projects. If there is, i think it should be at least available under Tools-Options. The workaround now is to mouse slowly over each one in the list until you see the directory name you where looking for. It would be nice if an option were available, under the View menu for example, that allowed the user to "view by directory name" and not by display name all projects that are open. Same applies to the Files tab, where it should probably be the default (because "Files"). This for example is the way projects are displayed by default in tools like Intellij.
Created attachment 83000 [details] screen shot of Projects
Hello, i can do this fairly easily in code and submit a patch for review, but before doing that, i would like to agree on a use case, if I may. How about adding a project display option at the bottom of the Maven tab under Miscellaneous in the Options window (SettingsPanel.java, see attachment)? It would show a JLabel saying something like "Plugin Display Name in Projects:" and then three radio buttons saying: o Project Name o Artifact Id o Project Directory Name The first one is the current one (default), the second one would show the artifact name and the third the directory name.
Created attachment 84421 [details] SettingsPanel changed with additional display option
Raising priority on this one, as it is currently the reason why we do not use NetBeans at my company. I would like to submit a patch, but i have questions about the code, which was changed recently. Also, i cannot provide a new nbm to my coworkers internally either as NB 6.7.1 currently does not compile giving some cryptic ergonomics1 not found error.
"Raising priority on this one, as it is currently the reason why we do not use NetBeans at my company" You can't even imagine how often I heard similar claims with various features of the IDE or maven integration Now to your proposal: There is no way to make everyone happy. We pick a name that is the most descriptive name of the project. Within these constraints you have freedom to do whatever you want, eg. you can put artifactId or even the directory in there. <name>text ${project.artifactId} ${basedir}</name> often projects have navigational patterns like <name>Geronimo :: Framework :: CLI</name> with just having folders or artifactId as project name you very fast end up with duplicate project names ("core", "util" and so on being the most common) it's considered good practice to have artifactId match the folder name, otherwise you might end up with weird problems in the scm/release/site generation area.. On a technical note: all other project types (ant based) have a project name equal to the name of the folder, you can change it though to whatever you want. I'm not convinced we need a maven setting. The Files tab being different from Projects tab is most probably not clearly achievable in maven modules space only (but would need global project changes) Also in the proposed UI we would probably end up with the setting not to be visible in the options dialog (but in offline ScrollPane area) I might consider to apply the patch if you don't expose any UI, but only have it controllable by Preferences settings, but I'm still convinced you don't really need it..
"...You can't even imagine how often I heard similar claims with various features of the IDE or maven integration" Heard quite the contrary overall, as there are currently no tools (as far as i know) as good as NB in supporting Maven. "Now to your proposal: There is no way to make everyone happy." Yes, but options or advanced options are normally accepted. I agree that we have weird naming conventions here, but it should be somehow possible to visualize the way you want (i was able to recompile after changing method getDisplayName() and provide a new nbm for the moment). "it's considered good practice to have artifactId match the folder name, otherwise you might end up with weird problems in the scm/release/site generation area.." Going to suggest that, sounds good to me. Always good to know about conventions. "The Files tab being different from Projects tab is most probably not clearly achievable in maven modules space only (but would need global project changes)" Ok, point taken, this is difficult to do and has little to do with Maven projects. Going to submit a request about the Files tab. To me "Files" means the file system, anything different than that would go into "Projects", the project view. "I might consider to apply the patch if you don't expose any UI, but only have it controllable by Preferences settings, but I'm still convinced you don't really need it.." Preference settings sounds good to me. It would be hidden, but that would do it (better than me recompiling for new nbm's each time there is an update). Going to attempt a patch. Thanks for your feedback and prompt reply.
Reassigning to default owner.
After some time, few comments: 1. I feel Milos Kleint is probably right about not adding more preferences. By just following good practices in Maven like he says, you give the artifact id as the name, and problem solved. 2. I still think however that the Files view in general in NetBeans should show just files, literally so. So, if the root directories corresponding to maven projects have the name of projects, i am arguing that that is what a user would expect to see. I would expect to see the directory name, because to me, what i am looking at is the filesystem. Not sure if the Files view was meant to do anything different than that, like being a hybrid between Projects view and the OS Filesystem, but maybe someone can further comment on that.
I think I agree with mkleint's assessment. <name> is the field designated by Maven for the label of a project that is most natural to its developers; if a navigational path in the folder hierarchy (relative to reactor root) is the way you normally differentiate your modules, then make <name> mirror that. Remember that mvn output (such as reactor summaries) uses <name> in the same way. And a global preference may be quite inappropriate for people working on projects from multiple sites. Visible preferences should be reserved for things that users fundamentally need to do differently, since every option adds conceptual weight to the UI. Invisible preferences are rarely used by anyone except the patch submitter, never get adequately tested by developers making changes years later or quality assurance engineers, and eventually tend to fall into complete disrepair. So we put a fairly high bar on new options. (In some cases - not this one, I think - a plugin can implement functionality needed by a minority of users.) The comments about the UI of the Files window are interesting but fall outside the scope of this issue. Any changes would need to be considered carefully in terms of usage across all project types (including mixtures of project types open at once). There are a few reasons why the top-level nodes in Files are currently labeled with project display names: 1. To mirror the sorting and structure of the Projects tab, so it is clear that this is only an alternate view of open projects. (The exception is projects which use external source roots, which show up as additional top-level nodes.) 2. Complete file paths are likely to be rather longer than project display names, and our tree component does not yet have the ability to compact long labels into e.g. "C:\Dcmnts&Sttngs\...\Projects\Stuff\Sub Module" to fit within the currently allotted horizontal space (adjusted on the fly after resizes). 3. The Favorites tab is always available for cases when you are looking for something more like an operating system file browser. Files is intended mainly for looking at structure *within* a project directory, e.g. build products, or miscellaneous files like READMEs that the Projects view does not know anything about and does not display. I filed bug #189446 for one relatively simple change that might address your points, though I am not sure it is a good approach.
Agree on all points, thanks.