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.
[200512281900] I moved content of public package of a netbeans module project to the other project. The package is still marked as public in project xml but is not shown in public packages list in Api Versioning category of project customizer. Because the package is empty.
Yes, reproduced. Should offer the same packages like Project View - so also empty packages.
I would disagree - the customizer should *not* show empty packages, nor for that matter packages with only binary resources. It is meaningless to expose a package with no .class files in it (i.e., when dealing with sources, a package with no .java files in it). IMHO the current behavior is not a bug. However it would be nice if when changes to the public package list are made in the customizer, any previously included packages which are in fact now known to be empty should be quietly discarded. That would at least have the effect of "cleaning up" the public package list at an appropriate time. It is not acceptable to make any changes to the public package list just because the customizer is opened or this panel is displayed; the user must make some kind of edit.
It will be nice to be able to edit these package. The empty public package should be market by other color in public packages list. BTW Repackaging during stabilization api is done quite often. It will be also nice to show warning message during building.
If and when we have a general UI convention for marking potential or real problems in a project's configuration - something Jano was supposed to be working on - empty yet declared public packages can be alerted there. We should avoid introducing ad-hoc UI tricks for this sort of thing. Especially displaying empty packages in the public package list just so you can uncheck them - this is not something you should "edit" (e.g. we do not want to permit them to be readded!); it is a misconfiguration that can optionally be corrected.
So I would go this way: whenever the user ivnokes properties dialog and then presses OK I'll do usual think + do a "clean-up". Probably doesn't matter whether some properties were edited or not - the user presses OK button, not Cancel. I'll do it silently until Jano comes with some appropriate way to handle discrepancies. Are you both agree?
Prefer to not make any changes to <public-packages> unless user has clicked on at least one checkbox there. Just because you made a change to your module's spec version does not mean you want some silent clean-up. Agreed that this is a temporary fix until there is a standardized UI for resolving configuration issues. BTW if a rename refactoring on a package fails to update <public-packages> accordingly, probably that is an RFE for apisupport/refactoring.
Ok. My point was that I would get rid of those redundant incorrect public packages ASAP. So the user will have a lesser chance to see them in the project.xml --> since as soon as the user sees them he will go to project's properties to remove them and file a bug like this one :)
So there is actually nothing to fix since it behaves exactly in that way. But we all had at least a good discussion ;) Feel free to reopen with new ideas. Probably best to wait to general ability for solving project's discrepancies.
Why not to add comment into list with public packages? For example: x package1 (empty - excluded on building) x package2 package3 User can unselect the empty package.
And then it may be checked again? It would be imho confusing. Or we could disable the checkbox as soon as the user unchecks it? :) Maybe some kind of warning would help. Not sure now exactly which one. Ideas are welcomed.
Still prefer to leave this as is until we have a proper UI for displaying and then resolving configuration problems.
Finally I agree with wontfix.