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.
Currently, there is framework in the core IDE that allows renaming serialized classes, so old settings can be read using classes with new names. This is achieved using mappings specified in META-INF/netbeans/translate.names. It would be useful if this file also allowed to specify that the old setting does not have an equivalent any more, and that it can be safely ignored (i.e. map old names to null). This would be useful for compiler types, executors, debugger types, but also for other settings, e.g. dataloaders.
For data loaders this would be useful.... though I think loaders.ser won't store old loaders explicitly unless they were customized (which is possible but unusual). For services (e.g. CompilerType's), AFAIK nothing amiss should happen if you have some old *.settings files, so long as nobody is actually asking Lookup for CompilerType - the InstanceCookie.Of should not try to load the class unless someone wants it. Right? Anyway services were generally stored in the project settings area in NB 3.x rather than in the main user dir, so NB 4.0 would just ignore them anyway (even if the upgrade wizard did not do anything about them and you just kept the user dir). So this would not cause any problems. AFAIK. Needs to be checked.
Thanks for the info. So you are saying that modules can just delete the old executors/debugger types without worries, right? How about for DataLoaders? Can modules just delete old loaders? Or should some work in core be done before we can start deleting loaders?
add DataLoaders - some non-NetBeans modules can modify loaders to extend their functionality (Sun Java Studio added some actions to loaders defined in web modules in the past AFAIK) Services can really be OK. What about .nbattrs files?
IMHO we should kill support for .nbattrs; they will be nearly useless in 4.0. No compiler type/executor/debugger type per file. Source file encoding should be a per-project attr (dkonecny will work on this API). Code synchronization is held in MDR. The only remaining use cases: 1. Marking files with odd extensions as text files. But we should just provide an editor cookie for DefaultDataObject and kill the text module, or something. The current system is just stupid. 2. Preferred data loader, for whatever this is good for. Yarda has some experimental module to manipulate it. Even if we still need file attrs for a few cases, IMHO masterfs should store them in the user dir, not alongside the files - no one wants this stuff cluttering up their source tree. I filed #42412. I would go ahead and kill old compiler, executor, and debugger type classes (as is already done for many modules). No way we want to keep them in the source base.
> 1. Marking files with odd extensions as text files. But we should just > provide an editor cookie for DefaultDataObject and kill the text > module, or something. The current system is just stupid. fully agreed. Treat all unknown files as text. If we want to do better we can detect the binary files (any '\0' in the first 2KB) and refuse to open them. Those can be edited/viewed in a hex editor in a distant future Radek, please file a P3 task, mark it with core-promod and assign it to yourself :-) Thanks
added core-promod to keep this on my radar I think this issue will become a non-issue. It's tied to how we want to import user settings from 3.6 to 4.0. Until now the upgrade code just copy over everything with a few exceptions. For 3.6 -> 4.0 we'll copy only selected .settings files, the likely candidates are shortcuts and editor settings
closing as INVALID and remove core-promod For upgrading from an older version to 4.0 the upgrade utility will copy over only a selected subset of .settings files. Modules can go ahead and safely delete their old classes which are there only because of deserializing old settings. META-INF/netbeans/translate.names could be deleted too.
Trung maybe you should locate translate.names | xargs cvs rm -f or something.
locate? I am used to 'find . -name ..." Once we delete all those translate.names I guess we still should keep the code which does this magic, for future. Right?
Do "man locate". Also http://www.geekreview.org/slocate/ Re. keeping the code - sure I guess, though we should try harder to not serialize stuff!
I've deleted all translate.names in stable modules except form and i18n/form. Not sure if form doesn't need those things for something special CC tpavek
Yes, I think form uses them to load ancient serialized .form files or something, best not to touch that.
Form uses translate names only for the JTable model property editor class name - it was moved from core to form module not so long ago, there could be still forms using the old name. The icon editor will probably go the same way, so there is still some use for the translate names files. i18n/form should be kept - there could be many forms still refering to the old class names (in this case the i18n property editor). (Don't need to tell me that storing the property editor class names in form files was not good idea. ;)
It seems that we can delete couple of ModuleInstall classes too - applet (not in build now, I know), extbrowser, html and maybe some others too.
Radim, just do it. Thanks
I went through ModuleInstall classes and removed empty ones (beans, extbrowser, i18n, properties, web/taglibed, xml/catalog, xml/core, xml/tools)