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.
[ JDK VERSION : J2SE 1.4.2_xx ] If a user instal led nb4 once, didn't keep it and kept using 3.6, it's not possible to import settings from the 3.6 release without manually deleting the 4.0 dir. The "first use" process should display a dialog that allowed the user to choose which IDE version to import settings from in this case, def aulting to 4.0
Definitely won't be implemented in 4.1. Need to decide whether this should be implemented in future releases. Going forward we may want to support migration from the last release only.
I have submitted this during 41cat, but it's relevant for this release as well.
Was submitted during 41cat, but it's relevant for current release as well.
The case is that I have a current release. I install a beta, import settings from current and then make further changes (e.g., to take advantage of new features). Now I install the new final release and I have only the option to again import settings from the previously current release and then redo all the settings I changed in the beta. I completely miss the logic of this process. In fact, it seems to actively discourage use of new beta settings.
I've seen, that settings api is in a state of being changed, so hopefully it will become easier to migrate settings in the future. However, it should be possible to migrate from 5.0, at least. IMO, one problem with migration is, that You want to migrate everything at once, while I'd prefer every module having its own migration layer (which should *not* be integrated in the standard layer file, as bugs may compromise the whole IDE). Every module should tell, how to migrate its settings from one implementation version to the next, possibly using its own migration implementation. To make it clear: - Projects should not be thought of as private module settings, so there should be a separate panel. - Modules should be possible to be used, probably updated, in a newer IDE version (if available)
Just some more comments, what IMHO settings migration should look like: - each module should have its own migration layer, which should have entries about which versions it can migrate, e.g. from 3.4 to 4.0, from 4.x to 5.0, from 5.x to 6.0 etc. In this example it would declare for every migration step, how to migrate from one version to some other. This incremental procedure has the advantage, that also rather old settings can be migrated, if the user didn't upgrade some time because of special needs (e.g. needing some module, currently not supported, but probably later re-implemented) - migration steps could be declarative (e.g. just copying some folders and setting default values for new opts) and/or procedural (e.g. an option might be split for user convenience, so this could probably only be done using a utility method). - if a module changes the code base name for some reason or is even split, this should also be mentioned in the migration layer and later be added to the update center's information, so the migration can transparently select the correct module(s) to upgrade. This makes also sense for external writers, who are contributing their modules later. - this all could, probably, look like this: <migrationLayer> <!-- The new codebase is known ny manifest --> <codebase old="org.contrib.anything"/> <!-- probably an api-module which has been seeparated into its own module --> <add file="a-dependeny.nbm"/> <migrate from="3.4" to="$"> <!-- migration from 3.4 to current version --> <move from="config/mymod" to="config/mymod/myvalues"> <folder name="config/mymod/extensions"> <attr name="newvalue" stringvalue="smile"/> </folder> <call name="org.netbeans.modules.mymodule.MigrationUtil.migrate"/> </migrate> </migrationLayer> - While projects are known to the IDE, there should of course also a possibility for migration over several versions. However, as every project type needs to handle this by its own, I'll not provide some proposal here. - With upgrading modules: see the above And, please, remember: this is only a proposal, as nothing has happened to this issue for a very long time - feel free to find a better solution ;-)
Ooops - the "<add file ..." is redundant, as the dependency is already declared in the manifest ... :-)
Reassigning to new module owner jskrivanek.
Any chance for see this soon?
This issue had *5 votes* before move to platform component
Now it is possible to import settings from arbitrary userdir. Open Tools>Options, click Import, browse for your userdir and finish the import.