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.
Mobility project properties are based on VisualPropertySupport. This support is not sufficient for more complicated data structures. The ideal solution would be to use org.netbeans.spi.project.ui.support.ProjectCustomizer.Category which allows to register OK button listener. When OK button is pressed a specific save method can be called to store panel properties. See org.netbeans.modules.javawebstart.ui.customizer.JWSCompositeCategoryProvider which shows how the listener is registered. If it is complicated to reimplement all Mobility customizers to use org.netbeans.spi.project.ui.support.ProjectCustomizer, something similar which would allow to call specific save panel method would be enough.
I built a test project with a fake project type, to get to know org.netbeans.spi.project.ui.support.ProjectCustomizer.Category last night. Now, with ProjectCustomizer, you do something like (from my toy project which just edits a serializable Pojo with a concept of categories) this to show a project properties dialog: I see how category.setOkButtonListener() and friends can help you do custom saving of stuff. But this only helps you if you are adding categories (subnodes of the categories are not created from info in the layer - although I suppose a way could be found to do that). In other words, at first glance, it looks like you'd end up with less, not more, control via layers over what is in the customizer, if we switched to using ProjectCustomizer. Only top-level categories would be in the layer, and you couldn't hook an existing category, you'd only be able to add your own; also you wouldn't be able to add/remove items from the subcategories in the customizer, which currently you can do. Probably we should migrate to using this infrastructure at some point, but it's not obvious to me how it will help you. There is also the problem that I see no way (other than manually hacking a component into the dialog returned by createCustomizerDialog) to show the configuration chooser in such a situation. We'd probably need an API change from projectui to do this in a non-hackish way. Tell me what specific things you want to do here. You mentioned needing to store more complicated data structures. What are they? Where are they visible/edited? How do you currently store them? How do you currently find out when to store them?
> this to show a project properties dialog: (sorry, I deleted my example since I decided it wasn't that useful, but forgot to delete the preceding sentence)
According to email from Radko, there is a workaround in place for the SDK, and sounds like indeed, switching to VisualPropertySupport would not help anything. So closing this issue as Later. Note we do want to improve the customizer infrastructure - particularly there are other bugs relating to validation, which is pretty much not handled at all - so I'm not going to forget about the requirements here, but some cooperation will be needed to come up with something better than both what we currently have and VisualPropertySupport.