Currently whenever I install a new version of NB,
the things I have to do are:
- modifiy the java editor abbreviations ('ab' and
'im' are very common german words; comments
sound a bit confused with every 'im' being
replaced by 'implements')
- modify keyboard shortcuts which don't work on
- adjust settings for Java Sources (e.g. Prescan
- adjust settings for Import Management tool
- adjust ToDo Settings (Task Tags)
- shuffle toolbar actions around
- ... some more
I'd really like to see a way to move these (and
more) settings from one installation to another,
but in some user-controlled way rather than by
letting the IDE try to import everything (which I
know didn't always work anyway but sometimes
resulted in the advice 'use a new user dir' or
'try a fresh install').
I would like to be able to share exported ide settings with other
developers. Our project code is formatted w/ tabs = 4 spaces,
expand tabs to spaces = false, etc. so that everyone sees the code
in the same format. We also add a few non-standard file extensions
to some of the indentation engines to get some syntax highlighting
as we have a scripting language that is loosly based on 'C'.
You *can* move such stuff around from install to install, just not
using the GUI... need to copy relevant files from the $userdir/system/
folder. Unfortunately there is no centralized documentation on which
file is which, so you have to experiment a bit.
Some documentation on the structure of the settings files would indeed
be helpful - be it in the online help, on nbusers list or on the website.
On the other hand, I'd fear it to be out of date as soon as 4.0 beta 1
is released, anyway?
NB: The fact that you *can* theoretically move these things if you
ever found out how and where they are doesn't really help
Joe-just-above-average-User. (Hopefully) 90% of NB users just want an
IDE that does help them do their job. Fiddling with internal files is
not an option for them.
Therefore it would be nice to have an option in the import wizard at
install time which gives you the choice to import specific categories
of settings, e.g. Editor Settings or Execution Types or whatever (an
option to automatically install modules corresponding to the ones
installed on the old version would be another idea).
I agree w/ Lars on the sub-category import and a wizard instead of
mucking around in system files. However, I don't necessarily agree
it should be on install. I would also submit that an "export" be
allowed. As I previously mentioned, I would like to share a
specific subset of settings w/ other developers so that code I
develop can be viewed correctly by other developers. We would like
to be able to create settings that all can use so all code developed
under a specific project will maintain the same formatting and
structure (Jalopy/code reformatting settings included). I would
like to be able to configure tab stops, expand tabs to spaces, and
Jalopy per project coding standards, then export them for others to
I, too, change a myriad of settings every time I install NetBeans: tab
sizes, compiler configurations, toolbars, indentation settings, form
editor preferences, code completion database settings...and there are
probably a few more that I cannot remember.
As a NetBeans user since the 3.3 days, I am extremely impressed with
the progression of the IDE through 3.6. The lack of an import/export
facility for configuration info is -- IMHO -- one of the only glaring
omissions at this point in time.
p.s. Eclipse has had a settings import/export capability for some time
now. So from a competitive perspective, there is also motivation for
this feature. If there is any help I can provide, relative to
development, please let me know...I would love to help.
Even if Eclipse has managed to provide this (from my point of view) very
important feature in team environments, they're still figuring out how to deal
with various levels of preferences, and think they shouldn't be presented
grouped only as components, but something closer to the user view of the things:
"The UI should present preferences in such a way that users can readily discover
them. Some preference settings have scopes (e.g., workspace-wide vs. per
project). The UI should help the user to visualize these scopes."
*** Issue 60535 has been marked as a duplicate of this issue. ***
I just installed NB 5.5 and this actually works very well at least to some
extent now. My macros and abbreviations and also my font sizes and custom
toolbar icons were imported and the IDE even started up with the same projects
as my previous version. I cannot see if everything is migrated correctly but my
experience with NB 5.5 met my expectations wonderfully. Thank you for fixing this.
I've been using NB 6.0, both the official beta releases and the overnight builds. It's horrible having to copy (parts
of) the folder structure manually, to migrate settings across versions.
Worse, the folder structure mixes-up things which IMO should be managed separately, most notably editor preferences and
libraries. It may well be that as a team, we want to share a common set of editor prefs (to reflect a house standard),
but perhaps have different local library settings.
NB appears to cache a lot of stuff below .netbeans\6.0beta1\var\, so copying the entire folder structure is both
uneconomical (it's around 80MB on my system) and probably wrong because the cache is presumably a completely local thing.
Copying folder structures around is just awful. This can't be a hard thing to fix, can it?
I'll vote for this issue to be addressed.
Reassigning to new module owner jskrivanek.
Some significant aspects of this issue mentioned above are now solved in NetBeans 6.5:
- ability to share libraries with other users (added in NB 6.1)
- ability to attach code formatting settings to the project and share them with other users this way (added in NB 6.5 M2)
(which allows to delete the NB settings directory without losing formatting settings)
So, what are some other aspects of the setting migration that people would like to have solved?
i.e. Macros, Code Templates, Keymaps, ToDo Task keywords, GUI Builder settings. The initial comment contains some more
In my opinion there are two use cases:
1) Sharing settings with others e.g. to force a corporate coding style. Obviously this does not make much sense for all
2) Exporting/Importing all possible settings in a version independent format e.g. to allow backing up of settings before
installing new modules or updating the IDE or to transfer settings to another computer.
> So, what are some other aspects of the setting migration that people would like to have solved?
- Toolbar customization, E.g. additional buttons, E.g: issue 42335, importing from old settings is the only way to get
buttons, which are not reachable by the new options dialogue.
- Platform settings
> So, what are some other aspects of the setting migration that people would like to have solved?
The biggest thing for me is when moving from 5.x to 6.x betas, for example, I have to reconfigure all my settings.
That's bad enough, but worse, when moving from 6.x beta 1 to beta 2, I have to reconfigure the settings again, and
when moving to 6.x final, I have to reconfigure the settings AGAIN! Maybe some of that has been changed now, but it
sure seems like that is the way things used to be, back in 2004 when this issue was first created. For those of us
willing to test the betas, we need to be able to at least import settings between from beta installations and from
betas to the final release. Importing from a previous final release would be even better, though I understand why that
might not always be possible.
*** Issue 64028 has been marked as a duplicate of this issue. ***
*** Issue 135747 has been marked as a duplicate of this issue. ***
*** Issue 152016 has been marked as a duplicate of this issue. ***
*** Issue 154125 has been marked as a duplicate of this issue. ***
This issue had *26 votes* before move to platform component
Please, review implementation of export/import options feature. The patch contains implementation in options.api module,
changes in nbbuild/build.xml for generation of list of imports after installation and changes in layers of modules which
had something to import in previous releases. Details are described in document mentioned in the url field.
Created attachment 77156 [details]
I'm sorry, but I don't think a fasttrack review is appropriate for a change of this caliber. This is going to affect
pretty much every module that reads stuff from the system filesystem. I have serious doubts that such a generic approach
can work effectively. For example some settings have to be exported/imported en block (eg. shortcut or coloring
profiles) while other settings should be exp/imp per items (eg. code templates or macros). It is also unsure how exactly
the export works - does it export stuff from a userdir (ie. user made changes to settings) or from the system filesystem
(ie. full sets of settings; both IDE supplied and user changes). Each way has its pros and cons and I'm not sure which
one is correct. Anyway, I don't want to block improvements in such an important and user sensitive area, but I think
that this particular solution grossly underestimates the problem and in the end will not solve it. It will only lead to
more defects reported by users who will feel like that they have been cheated.
I personally would prefer going the way shown in http://ui.netbeans.org/docs/ui/keymap_option_panel/index.html#profiles,
which btw was implemented in 7.0M1 as part of issue #123467.
Thank you for comments. I pre discussed intended changes at nb-tech-council, so I didn't want to go through full review.
Suggested implementation is based just on files in userdir. It imports or exports files to or from userdir. Keymaps or
Font&Colors profiles are now ex/imported at once. But it would be possible to do it one by one. I think there is no
reason to handle every single code template or macro individually. Could your please enumerate use cases and problems
which are not solved by this approach?
"I pre discussed intended changes at nb-tech-council, so I didn't want to go through full review." - That's ok. I just
think that this change affects too much and so the fasttrack review is not suitable. Obviously, this is just my opinion
and so if others are fine with fasttrack then so be it.
"Suggested implementation is based just on files in userdir" - Which is not suitable for exporting coloring or shortcut
profiles for example.
"I think there is no reason to handle every single code template or macro individually" - Well, user requests we have
had suggest otherwise. I know the IDE does not support it now, but for example DTD for codetemplates allows using unique
IDs for each codetemplate so that when exp/importing the IDE could recognize new codetemplates from those that have
already been imported.
"Could your please enumerate use cases and problems which are not solved by this approach?" - Well, this issue
originally complained about problems with importing user settings from previous versions. Your patch does __not__ solve
these problems. It can't, because these problems are in modules and there is no way how to solve them centrally in the
platform. Moreover your patch allows users to export/import settings at any time. So, it effectively exposes one of the
IDE's weaknesses by providing GUI controls for something that is not properly implemented. IMHO if we integrate this
change we are likely to receive a lot of complaints and defects.
Technically this API is not suitable for modules either. Modules would ideally need a way how to register their own code
for exporting/importing their settings instead of just having their settings files shoveled by the platform from one
userdir to another.
> "Suggested implementation is based just on files in userdir" - Which is not suitable for exporting coloring or
> shortcut profiles for example.
As I heard the problem is in default profiles. If user changes something, only diff against default profile is saved in
userdir. So, it will work when profiles are compatible. Maybe default profiles should not be editable and user should be
forced to clone such a profile and modify own copy.
> ...so that when exp/importing the IDE could recognize new codetemplates from those that have
> already been imported.
It is true my implementation doesn't solve conflicts of import. It is up to user whether to import everything or not. He
can export his options as a backup before importing.
> ...problems with importing user settings from previous versions.
For import are always allowed only files which are recognized by some of currently loaded modules. But if for example
file format changes between versions, it is up to module to not accept obsolete settings
> Modules would ideally need a way how to register their own code for exporting/importing...
Yes, that was my original idea to have something like OptionsExportProvider and modules can implement it (see
http://wiki.netbeans.org/ExportImportOptions?version=4). But if I want to do initial import of setting from previous
release at the first start after installation, modules are not yet loaded and I need some declarative way of import. I
was also considering import of options when IDE is fully initialized but with ergonomics IDE it is not possible.
I will integrate proposed patch tomorrow.
Just for the record. We discussed the change in person (jskrivanek, olangr and I) and we still seem to have different
opinions about how this should work. None of my concerns were satisfyingly addressed or proven to be void. Although I am
not strongly against the change I think it is not going to work well for editor settings. We may fix it in the future,
but it is likely to require substantial amount of work on both sides (ie in the editor and also in this api). If this
change results in too many complaints (bugs) about export/import of editor settings we will consider removing editor
settings from the list of settings that can be exp/imported through this functionality.
I must say that I don't understand why the standard API review was not held yet - Vita brought up some very valid and
constructive input. Refusing to even hear other people's comments is a very immature attitude.
To me, the most glaring flaw of the proposed solution is that for the keymap profiles, it will add another parallel
implementation next to what we already have, so there will be two different and inconsistent approaches to do one thing.
Another major flaw would be if the solution indeed does not address the user requirements we are hoping to solve - this
is another thing that can be easily discussed at the standard review meeting.
Fixed. Arbitrary export/import of user options can be done from the Options dialog. Layers of modules which provide
something for export were updated, so we don't need centralized list anymore because initial import after installation
is driven by list of patterns generated from these layers.
to pjiricka: I am sorry but I have read your comment too late. I have just pushed changes to the repository. I discussed
objections with vstejskal but I am still convinced that my implementation is better than nothing. It goes along with
previous approach that all user options stored in userdir were copied after installation of new IDE version. So, I think
keymap profiles should be importable from userdir. In such a case user even don't need to explicitely export/import his
profile if switching to newer IDE version but profiles are imported within other options.
The main user requirement was to be able to share/backup/import/export settings. This requirement is fulfilled.
I finished this review without official meeting because we discussed it and there were no strong opinions against it.
Please, let me know if you want me to call a meeting now.
Integrated into 'main-golden', will be available in build *200903060201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jiri Skrivanek <email@example.com>
Log: #42157 - Enable arbitrary export/import of user options. Added UI to options.api module and updated layers of modules which provide something for export. Also initial import after installation is driven by list of patterns generated from layers.
*** Issue 159596 has been marked as a duplicate of this issue. ***
Just tried this in the nightly... there is no way to create a new zip file when exporting using the file browser in OS X, it's expecting me to select an existing zip
Also, might be a local setting of mine, but all hidden files are being shown... that's not pretty.
I've not been able to try this, but will NetBeans remember the buttons that I've clicked to export? I don't want to have to do that every time!
Thank you for feedback. I fixed Mac issues with issue 159909. NetBeans doesn't remember selected items because we
expected it is not an action someone will use everyday. If you are missing some feature like this, please, file a
separate issue for it.
Short of remembering the settings, it would be highly useful to have "select/deselect all" button!
Integrated into 'main-golden', will be available in build *200903170201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jiri Skrivanek <firstname.lastname@example.org>
Log: #42157 - Use new API with check boxes next to node. Set visible root node which allows to select/deselect all at once.
verified according to http://wiki.netbeans.org/ExportImportOptions
Product Version: NetBeans IDE Dev (Build 090317)
Java: 1.6.0_13; Java HotSpot(TM) 64-Bit Server VM 11.3-b02
System: Linux version 2.6.27-11-generic running on amd64; UTF-8; en_US (nb)
I don't like the fact that not all registered categories are visible in export/import dialog, but just those that really
exists in userdir. If I was a user and I would open export/import dialog and wouldn't find Editor (category/node) I
would expect that Editor setting can't be exported and I wouldn't open the dialog again.
IMHO every category (folder in layer) in OD should be represented by one node in export/import dialog - no matter what
was changed, it makes navigation in such tree easier.
I think it is OK that if nothing is changed, nothing is available for export. Users will not try to export something if
they don't change anything. From developers point of view it might be confusing that if you add some patterns to layer,
there is no item in the export dialog. I will add a comment to the document but I don't plan to change it.
Ondro, what is your opinion? Could you review once more whether UI and work flow is all right? Thank you.
For me, it's a bit weird that one day I don't have some category in the Export dialog but the other day it's there; or that I don't have some
category in my Export dialog but a colleague sitting next to me has it (IMHO I can hardly guess that it's because I changed something).
I'm not UI expert but personally I would prefer the dialog to be the same all the time with some items disabled (maybe tooltip can tell the
Agreed that this can be confusing. Better solution really seems to be to display the items which cannot be disabled and
indicate this fact. Or at least state that "Only settings modified from the defaults can be exported" .. or something
Integrated into 'main-golden', will be available in build *200905041401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jiri Skrivanek <email@example.com>
Log: #42157 - Show all options registered for export but disable not available ones. While importing show only available.
*** Issue 164350 has been marked as a duplicate of this issue. ***
*** Bug 118848 has been marked as a duplicate of this bug. ***