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.
I have made a module that effectivly adds the functionality of org.openide.loaders.FileEntry.Format to PropertiesFileEntry. This allows troperty file templase to contain replaceable macros. I do this by subclassing PropertiesDataLoader, and if the FileObject is from a template, I use my new FileEntry.Format. Sublassing PropertiesDataLoader required me to remove the "final" from its declaration. However, the comment for this class says: * This class is final only for performance reasons, * can be unfinaled if desired. So I think it should be no problem to make this chage in the trunk.
There is a problem. PropertiesDataLoader is not part of any official API. It is part of a "friend" API between modules Properties and I18n and is declared as such (see file properties/arch/arch-properties.xml). So the only acceptable reason for making an API change (and removing a 'final' token is an API change) would be if it was required for cooperation between these two "friend" modules. Or I could declare your module as another "friend" and then make the API change... The truth is that even the unofficial API of these two modules (Properties, I18n) is kind of messy and should be cleaned up. What about adding the new functionality to the current PropertiesDataLoader class?
I’m investigating just adding the tag-replace functionality to the “Resource Bundles” module, and while it is technically simple, I think it would be a bad idea to hard-code my replaceable tags into the module. For example, my tag __MFFE_FULL_NAME__ is of no interest to any other module. Making the list of tags dynamic can be done many ways, but all the techniques I can think of require SOME kind of public interface for communication, even if it is using Lookup. For example a good way to specify tags would be for my patch to lookup tag providers via Lookup.getDefault().lookup(new Lookup.Template(ReplaceableTagProvider.class)) This requires either A) ReplaceableTagProvider to be defined as a public interface in Resource Bundles module. B) ReplaceableTagProvider to be defined in a separate module, and Resource Bundles depends upon it. Which is preferable? Are there other options? CH