Bug 64150 - Generate layer.xml&Bundle.properties into resources folder
Generate layer.xml&Bundle.properties into resources folder
Status: RESOLVED WONTFIX
Product: apisupport
Classification: Unclassified
Component: Project
5.x
All All
: P1 (vote)
: 5.x
Assigned To: Jesse Glick
issues@apisupport
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-12 16:56 UTC by Jan Lahoda
Modified: 2005-12-02 21:35 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Lahoda 2005-09-12 16:56:34 UTC
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.
Comment 1 Martin Krauskopf 2005-09-12 17:18:53 UTC
+1 from me. I'm rewritting those two fields everytime in the same manner. Please
consider and reassign.
Comment 2 Jesse Glick 2005-09-12 22:58:12 UTC
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.
Comment 3 Vladimir Voskresensky 2005-12-02 12:23:18 UTC
+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"
Comment 4 Jaroslav Tulach 2005-12-02 13:26:45 UTC
Radim once expressed opinion that we have too many useless subpackages in our 
sources. 
Comment 5 Jesse Glick 2005-12-02 21:35:05 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo