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.
The import button on the options dialog appears to replace the whole build.properties file from the userdir with the one from the zipfile created by a previous export. Correct me if I'm wrong, but this is dangerous. It can break the current netbeans installation if the export was from another version or dev build. For example I had exported all settings from netbeans-trunk-nightly-200905250001-ml-windows.exe and, after removing that build from my pc I installed netbeans-6.7rc1-ml-windows.exe and imported all the settings from the above. After that, I downloaded some optional modules from the update center. The result was that my build.properties in the netbeans userdir was completely mixed up. The newly downloaded modules had the correct paths, but the remaining had paths like "C:\\Program Files\\NetBeans Dev 200905250001\\...", which no longer existed. Needless to say that I could no longer do a build or use help. What netbeans should do here is check the paths against the current installation of netbeans, into which it is importing. That should be easy, at the bottom of build.properties you have a line like this: nbplatform.default.netbeans.dest.dir=C:\\Program Files\\NetBeans Dev 200906020201 use the value of that property as the search string and do a global replace with the correct value of the current installation. That should fix it. You should also attempt to fix the paths of other known packages that have been installed by the netbeans installer, like glassfish for example.
Jesse, I guess you should rather revert #109af999ac77 (issue 161616). build.properties are now completely replaced during ad-hoc import. If the import is done during the first start after installation, variables are copied anyway (#95fb04448375). Maybe we should make it yet for 6.7. Then in 6.8 we can somehow individually handle import of build.properties. Probably would be better to separate install-time properties and user-defined properties and import/export only the second ones.
As far as I am aware, any old paths would be corrected automatically after restarting the IDE. At least the locations of bundled libraries (libs.*.classpath) are generated during startup from XML files included in modules, which are not copied to the userdir (thus importable) unless explicitly customized. Other properties, including variables and locations of custom NB platforms, are left untouched. Assuming that analysis is correct, P3 would be appropriate and I will correct for 6.8. Just reverting 109af999ac77 does not seem right because then an import after initial startup will not work (as far as issue #161616 is concerned). Better fix would I guess be to explicitly trigger build.properties refresh from source metadata (libraries XML etc.). If this is known to affect lots of users, and/or a restart does not refresh build.properties correctly, then P1/P2 priority would be justified and this needs to be considered as a potential 6.7 showstopper. QA advice requested.
I agree with the evaluation. If restart fixes all the paths, this can be fixed in 6.8. Reporter, can you confirm?
Sorry, but I can not confirm that paths are fixed on restart. It does not happen. I tried teh following steps: Step 1: Export all settings from Netbeans 6.7 RC1 Step 2: Import all settings from NetBeans Dev 200905250001 (Netbeans does an IDE restart on Import, right?) Step 3: Exit Netbeans. Step 4: Validate that build.properties has the wrong paths. Step 5: Start Netbeand 6.7 RC1 again. Step 6: Try to build one of my projects. Fails with the following: C:\DEA_eANV\nbproject\build-impl.xml:427: taskdef class org.netbeans.modules.java.j2seproject.copylibstask.CopyLibs cannot be found Step 7: Have a look at build.properties again. Still the wrong paths in there. Step 8: reimport settings from Step 1. Step 9: try to build again. Build is succesful. I guess you have a problem here. In my opinion it makes no sense to export/import paths to libs that come with netbeans or optional netbeans modules. That can only cause trouble. Libraries or their paths can change from version to version. The current netbeans installation can have more or less modules downloaded than the one from which the export was. So it would be a good idea to separate installation properties from user defined properties.
Created attachment 83297 [details] build.properties after Step 5
I have similar observations. Restart does refresh build.properties just once for me. But if I do Tools>Options>Import second time, then build.properties are replaced permanently and restart doesn't correct them. That's why I would rather revert 109af999ac77 for 6.7. Import of variables and nbplatform.default.netbeans.dest.dir after initial startup will work because it is handled in o.n.upgrader (95fb04448375). My steps how to break build.properties: - run dev IDE - Tools>Options>Export - select all and export to devexport.zip (you can check build.properties is included in zip) - run 6.7 RC2 IDE - create a java project to activate java - Tools>Options>Import - browse for devexport.zip - select all - confirm restart - after restart <user_home>/6.7/build.properties are correct - once again Tools>Options>Import - browse for devexport.zip - select all - confirm restart - after restart <user_home>/6.7/build.properties are WRONG (paths to dev build)
Do whatever you think is best for 6.7. I do not really understand why separate code paths are being run for import of settings during initial start vs. explicit import. I also do not know why restarting the IDE is not refreshing the libs.* properties in build.properties - ought to be handled by project.libraries module, but perhaps something is broken here, or perhaps timestamps are considered? If 109af999ac77 is reverted, then I presume issue #161616 must be reopened.
> why separate code paths are being run for import of settings during initial start vs. explicit import. .. me neither ;( ... and unfortunately this generates another path that needs to be covered by testing > If this is known to affect lots of users, and/or a restart does not refresh build.properties correctly, then P1/P2 > priority would be justified and this needs to be considered as a potential 6.7 showstopper. QA advice requested. I do not think it's going to affect a lots of users : 1. export is not available in NB 6.5(.1) so anybody won't be able to generate zip file for Import directly from the IDE 2. we do not support import from Dev/Beta/RCs into FCS I also think it's too late for such change (imports were already tested). We'll definitely address this issue in NB 6.8.
> why separate code paths are being run for import of settings during initial start vs. explicit import. Basically because of ergonomics. Initial import does import of settings for all installed modules. Explicit import takes into account only settings of enabled/loaded modules. > 2. we do not support import from Dev/Beta/RCs into FCS It is allowed to import from arbitrary userdir. Thus explicit import from dev to FCS is possible.
OK, QE doesn't recommend to revert 109af999ac77. Then Jesse, please, fix it somehow for 6.8 (see desc3 or decs2).
Not sure exactly how it can be fixed. The API does not give me the option to import just some properties. What I would want (if the API is to remain purely declarative) is something like <attr name="include" stringvalue="config/org-netbeans-api-project-libraries/Libraries/.*\.xml|build\.properties#nbplatform[.](?!default[.]netbeans[.]dest[.]dir).+[.].+=.+|var[.].*"/> where the #regexp on a *.properties file would copy only some entries (using EditableProperties).
Yes, this extension of the API makes sense. Probably useful also in other cases. Or build.properties can be divided in two files as I suggested.
Splitting build.properties into two pieces would be possible, but somewhat disruptive. (Every Ant-based project type would need to change build scripts, and there might be impact on people using CI.) Seems easier to enhance the import facility.
*** Issue 167771 has been marked as a duplicate of this issue. ***
How about allowing something conceptually like a "VetoableChangeListener" to be registered? It would provide a convenient way to map potential version incompatibilities as well. I'd like that for the options relating to my plugin.
Since it was last agreed that "this extension of the API makes sense", reassigning to the person best qualified to make such an API change.
*** Issue 168159 has been marked as a duplicate of this issue. ***
Please, review this change in export/import options. It enables to include/exclude just some properties as suggested in #desc12. Patterns may contain either a regular expression defining files relatively to userdir or a compund pattern defining files and property keys. A compound pattern consists of file regex pattern followed by hash delimiter (#) then property key regex pattern followed by another hash delimiter. Hash delimiter can be ommited at the end of compound pattern. For example, a compound pattern can have the following structure filePattern1#keyPattern1#|filePattern2|filePattern3#keyPattern3 <attr name="include" stringvalue="config/mymodule[.]properties#key[1-9].*|keyA.*#|config/mymodule[.]xml"/> <attr name="exclude" stringvalue="config/obsolete[.]properties#key5"/>
Created attachment 90125 [details] Proposed patch.
Looks OK to me, though the specification of the format is getting a bit difficult to follow, thus [JG01] Consider defining a package annotation. It would offer a more readable and structured way of writing the lists, including conveniences such as being able to use literals when you do not need regexps, and the Javadoc would be a natural place to document behavior. For example: @OptionsExport(category="Advanced", displayName="#ProjectLibraries.Options.Export.displayName", patterns={ @Pattern(pathRegexp="config/org-netbeans-api-project-libraries/Libraries/.*[.]xml"), @Pattern(path="build.properties", includedKeyRegexps={"nbplatform[.].+[.].+", "var[.].*"}, excludedKeys="nbplatform.default.netbeans.dest.dir") }) package org.netbeans.modules.project.libraries; import ...; The associated processor would perform compile-time syntax checks (e.g. all regexps are well-formed, exactly one of path or pathRegexp is specified for each @Pattern) and register import lists in the generated layer in something like the currently proposed format - or anything else which is convenient to parse to runtime without ambiguity.
Of course if you are interested in JG01 it could probably be a separate API review; would want to see existing modules use the annotation too.
> Re: [JG01] It is interesting and probably more readable and flexible than proposed format in layer. Since I expect complicated regexps for keys will be used only occasionally and 6.8 code freeze is approaching, I would keep original proposal. A simple include pattern is straightforward: "config/Preferences/org/netbeans/modules/mymodule[.]properties#keysA.*|keysB.*|key1" And more complex patterns for project.libraries with exclude pattern: <attr name="include" stringvalue="config/org-netbeans-api-project-libraries/Libraries/.*\.xml|build[.]properties#nbplatform[.].+[.].+|var[.].*"/> <attr name="exclude" stringvalue="build[.]properties#nbplatform[.]default[.]netbeans[.]dest[.]dir"/>
Agreed.
If there are no other objections, I will integrate tomorrow.
Fixed as suggested. core-main #29703185bb0c
Integrated into 'main-golden', will be available in build *200911050201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/29703185bb0c User: Jiri Skrivanek <jskrivanek@netbeans.org> Log: #166585 - Added support to import/export just selected keys from property files. A compound regex pattern (filePattern#keyPattern) can be used in layers. It enables to fix problems while importing build.properties.