Build: NetBeans IDE Dev (Build 080614)
VM: Java HotSpot(TM) Client VM, 1.5.0_15-b04, Java(TM) 2 Runtime Environment, Standard Edition, 1.5.0_15-b04
OS: Linux, 2.6.25-gentoo-r4, i386
just <enter> in PHP script
I am running a new build. The problem is e.g.
<!DOCTYPE settings PUBLIC "-//NetBeans//DTD Session settings 1.0//EN"
<instance class="org.netbeans.modules.gsf.GsfOptions" method="create"/>
Now of course this class was removed in #cd7055fc20d9. The reason I think this is a core bug (specifically:
SerialDataConvertor.isModuleEnabled) is that the .settings file claims to be for org.netbeans.modules.gsf/1, yet the
current module is /2. Therefore the .settings file should be quietly suppressed by the settings infrastructure: it
claims to be written by an older and incompatible version of the module.
We might consider enhancing the settings module a bit so that if Utilities.translate gives e.g. "" as the translation
for a class name (via META-INF/netbeans/translate.names) used in <instance> in a .settings file, the file is ignored.
That would be a simple way to just cancel any old *.settings for a given set of classes. Probably a fast-track API change.
Comment 7Vitezslav Stejskal
2008-06-18 16:10:30 UTC
It's the same problem as in issue #137278. This should not happen with properly imported userdir. I'm not sure what
policy/conventions we have for things like this. I know we encourage users to keep their userdirs, but can we ask them
to always import and ignore errors that happen with userdirs that has not gone through the import procedure? And if so,
is there any way to tell the IDE to import an arbitrary userdir?
If we have to deal with any userdir (without being properly imported) I will have to resurrect the options classes and
somehow make sure that the .settings converters load null for these settings files. Btw, this is a result of GSF writing
layer registration files to a userdir when initializing a language.
Importing of an old usedir is offered only when starting with empty userdir. AFAIK, there is no UI allowing to import an
arbitrary userdir. But of course user can use --userdir anytime. Radku, what was the policy in the past about userdirs
that has not gone through the import procedure?
BTW, if you already know what to import or not to import to NB6.5, please update
Simply was not recommended, not supported in any way.
Comment 10Vitezslav Stejskal
2008-06-19 10:34:02 UTC
> But of course user can use --userdir anytime
This is exactly the problem. Doing this will NOT import the userdir, it will simply use it. And no filters,
transformations, etc defined in o.n.upgrade will be applied. So basically the IDE will run with an old userdir that may
contain some rubbish, which if imported properly would have been removed.
Maybe we could somehow detect that the folder passed in as --userdir is in fact a userdir from some older version and
offer a user to import it properly. The IDE should then probably refuse to run with a userdir that was already upgraded
by a newer version. Just an idea...
> BTW, if you already know what to import or not to import to NB6.5, please update
> http://wiki.netbeans.org/NB65SettingsMigration accordingly.
The filter for excluding Settings.settings has been in place since 5.5, I updated the wiki page.
> Maybe we could somehow detect that the folder passed in as --userdir is in fact a userdir from some older version and
> offer a user to import it properly. The IDE should then probably refuse to run with a userdir that was already upgraded
> by a newer version. Just an idea...
I don't know if we are able to easily recognize version of userdir. I afraid of complicated logic and not much benefit.
As always, I am against relying on the importer to exclude "bad" settings, or transform old settings formats. Every
module is responsible for gracefully dealing with old settings. In the case of NbPreferences, this is trivial - just
ignore old keys (and choose new key names if you change format). A simple API change to the *.settings handler would I
think make it equally trivially to ignore *.settings from defunct classes.
Comment 13Vitezslav Stejskal
2008-06-23 12:40:16 UTC
> As always, I am against relying on the importer to exclude "bad" settings, or transform old settings formats.
> A simple API change to the *.settings handler would I think make it equally trivially to ignore *.settings
> from defunct classes.
Ok, it sounds reasonable. May I leave this with the core team?
Comment 14Antonin Nebuzelsky
2008-06-29 23:44:01 UTC
I implemented Jesse's proposal. If Utilities.translate() returns "", InstanceCookie is not issued. I am asking for
review but I am not sure where to document it and if increase spec versions of openide.util or settings modules. Your
comments are welcome.
[JG01] instanceCookieChanged might also need to be updated for completeness.
[JG02] It seems you are checking for a null translation of <instance class="..."/> only. Is it supported to have a null
translation of the class name in <instanceof class="..."/> or <serialdata class="...">...</>? For the former, I would
think that this would mean that the instanceOf method would simply not report that class:
String name = Utilities.translate(attribs.getValue(ATR_INSTANCEOF_CLASS));
if (name.length() > 0) instanceOf.add(name);
For the latter, I would expect the same treatment as <instance class="..."/>: produce no InstanceCookie. It looks like
this will already work, but it is not tested.
[JG03] Have you confirmed that the proposed change can actually be used to suppress GsfOptions? E.g.
> [JG01] Done.
> [JG02] Done.
> [JG03] I can't reproduce original exception. I started build 20080613 and created PHP project. Then I saw
config/Editors/text/x-css/Settings.settings in my userdir. I started current build with this userdir but I didn't get
any exception and Settings.settings silently disappeared.
To JG03 - strange, maybe you can debug a bit?
Otherwise it is looking good. Don't forget apichanges, I guess in settings module. Since no one has a direct dependency
on this module just to load *.settings files (for historical reasons...) I guess changing spec versions is not necessary.
>> [JG03] Tor already put a patch (http://hg.netbeans.org/main/rev/01d41235697e) which removes Settings.settings files.
If I revert his changes and add org.netbeans.modules.gsf.GsfOptions= into gsf/src/META-INF/netbeans/translate.names, it
It is strange it can be reproduced in dev builds. This changeset http://hg.netbeans.org/main/rev/01d41235697e should
delete *.settings files with obsolete GsfOptions class, if assersions are enabled which should be true for dev builds.
For sure it would be better to add the following into gsf/src/META-INF/netbeans/translate.names: