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.
When a new project is created, the layer.xml and Bundle.properties (which provides localization for manifest) are by default generated under <code-name-base>/ folder. I would suppose these are generated under the <code-name-base>/resources folder.
+1 from me. I'm rewritting those two fields everytime in the same manner. Please consider and reassign.
A nice thought but no. If we do that, there will be nothing in the "main" package, meaning that when the user first goes to create a new class, or something from a wizard, the default package that gets selected in the dropdown will be "code.name.base.resources" (since only nonempty packages are presented as choices). Many users will not see our logic in using a "resources" subfolder, so they will just leave the default unedited and wind up putting everything in this package, which would be bad.
+1 from me. Jesse, I don't agree with your explanation. It's developer based, not user based. From user POV, it's expected to have "empty" package "code.name.base", but to have bundle and layer.xml in correct "code.name.base.resource" place. From implementation POV, it's easy to handle: 1) with simplest flag on empty "code.name.base" folder (remember, that it was created from wizard) or 2) not finish module wizard, but continue with the "add new Module Developement Element" (for example propose to add something as in File->New File->Netbeans Module Developement), because it's strange to stop on the creating only modules folder with bundle and layer files. It's usual user scenario to continue then with File->New File->Netbeans Module Developement or 3) even creating useless class in "code.name.base" is more user friendly than current behavior, because you need to delete only one file, while in current solution you have to "move two files in different package"
Radim once expressed opinion that we have too many useless subpackages in our sources.
I don't think any of the proposed solutions are safely implementable. The arguments may be "developer based" but we can't solve every user problem without compromise - there is a cost. Re. #1 - we do not want to keep magical hidden info about a project that does not correspond to what is on disk. The package view needs to show a predictable view based solely on what folders and files actually exist. Otherwise we get into tangled semantic arguments about what different actions should mean. Re. #2 - inconsistent with other project types, and not necessarily what the user wanted anyway: perhaps one of the wizards is desired, but perhaps regular Java coding is wanted for now. Also we discourage putting too many steps into a single wizard unless they are clearly related, as the user will get distracted and overwhelmed. Re. #3 - strange. Would likely confuse people. Anyway I am not convinced that this RFE is of much value to the average external module developer, which is our primary audience. The .resources package naming convention is just a historical precedent in NB module sources, but it has no great value for module development. (In fact, I would argue that layer.xml is significant enough to be found in a "main" package normally, and for a one-package module which will have various localized strings it is often more convenient to have a single Bundle.properties.) Finally, it is not very difficult to insert "resources/" into the text fields for the locations of layer.xml and Bundle.properties in the project creation wizard, if this is what you want to do. It does not seem to me that saving this short step for those developers who wish to follow the .resources convention is worth the possible problems introduced by a solution.