fixed workspace and configuration defaults (install dir on windows is…

[fgdrf]

… read-only, using LOCALAPPDATA

Tested RC 2.0.0.RC1 Installer on Win x86_64 but uDig never started. The Install-Dir was read-only and therefore Eclipse Defaults doesn't make sense.

This fix sets workspace and configuration area to sub-directory in %LOCALAPPDATA% on Windows-platform only.

Signed-off-by: Frank Gasdorf fgdrf@users.sourceforge.net

[fgdrf]

@egouge Could you test this behavior on Windows?

[fgdrf]

@nprigour If your products running on Windows, could you test and verify this fix? Would be great if you can have a look at it and review changes...
Many Thanks

[nprigour]

Hi @fgdrf ,
The property value for the configuration area should be osgi.configuration.area and not osgi.configuration.area.default in order to have a local configuration area created (under %LOCALAPPDATA% sub-directory). This is a needed for a share configuration otherwise the default configuration directory located at the root installation folder is used and modified which may cause problems in case or read only installations.
see also http://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fmulti_user_installs.html
Other than that I think the changes are OK

[fgdrf]

Thanks for your feedback! Here the explanation why I used osgi.configuration.area.default over osgi.configuration.area.

From : Eclipse Runtime Options:
osgi.configuration.area.default
the default configuration location for this run of the platform. The configuration determines what plug-ins will run as well as various other system settings. This value (i.e., the default setting) is only used if no value for the osgi.configuration.area is set. See the section on locations for more details

I decided to use this option and give users the opportunity to overwrite "default" on Windows with -configuration / -Dosgi.configuration.area= for their needs.

[egouge]

A little late, but I did eventually test this and it worked fine for me.

[fgdrf]

@egouge Thank you very much for confirming the fix works on another box than mine too :)

[fgdrf]

Good finding. I guess the problem comes from "the installer configuration" where is should set dependent from the platform the installer is made for

• 32bit : $PROGRAMFILES
• 64bit : $PROGRAMFILES64

Details : http://nsis.sourceforge.net/Reference/$PROGRAMFILES

[fgdrf]

@egouge Created a bug for installer 64bit issue : https://bugs.locationtech.org/show_bug.cgi?id=142