[Gvsig_english] Recent change for gvSIG 1.10 in SVN

Thu Jul 8 09:57:26 CEST 2010

Hi,

I agree with Ben, we should revert the change and devote some more
thinking on the topic before applying such a change. It is problematic
enough to be delayed for the next version.

Regarding the implementation, probably you don't need to modify the
installer at all, everything could be done from gvSIG during the
start-up process.

Regards,

César

2010/7/8 Francisco José Peñarrubia <fpenarru at gmail.com>:
> Hi.
>
> This change comes from a patch to avoid conflicts between several
> installations of gvSIG, and some problems related to this conflicts in
> configuration.
> I think the solution of Cesar is better, and I will try to implement,
> but only partially. I will not touch the installation program, and we
> will create gvSIG/version directories.
> If the user wants to keep the old config and preferences, he must copy
> by himself the files.
>
> Ok with that?.
>
> Fran.
>
> César Martínez Izquierdo escribió:
>> Hi Ben,
>>
>> It seems that commit matches the following ticket:
>> http://forge.osor.eu/tracker/?func=detail&atid=732&aid=14411&group_id=89
>>
>> I think the idea was allowing different configurations for different
>> gvSIG installations.
>> However, I agree with you that it is not as good ideas as it may seem
>> at a first glance, and I suggest to better analyze all the possible
>> behaviours to select the desired one.
>>
>> Besides the multi-user problem that you point at, I see other possible problems:
>> - If I install a new gvSIG version, should I set all my configuration
>> again? This looks as a regression to me.
>> - What happens if the user has no write permissions on the gvSIG
>> installation folder?
>>
>> I think it is ALWAYS a good practice to keep program configurations on
>> the user home, and program installation on a different one, and don't
>> mix them up.
>>
>> I guess that the intention of this change was to be able to execute 2
>> different gvSIG versions which may have conflicting configuration
>> files (because changes on code, etc). If this is the case, I would
>> suggest a different approach:
>> - Keep config in home.dir folder, under a versioned folder (for
>> example, ${HOME}/gvSIG/1.1 or ${HOME}/gvSIG/1.9).
>> - Whenever you install a newer version, copy the last version
>> configuration to the new dir. For example, if you new install 1.10,
>> copy config from ${HOME}/gvSIG/1.9 to ${HOME}/gvSIG/1.10 and update
>> any conflicting files on 1.10 folder.
>> - In this way, the user would find the old configuration in the new
>> versions, but version conflicts are avoided (so he would still be able
>> to run 1.9 if desired)
>> - Drawbacks: configuration changes applied on 1.9 version wouldn't
>> apply to 1.10 version and vice versa. But this is better than having
>> version conflicts, I think. Of course it could be solved with smarter
>> approaches, but for sure they would be more complex and I don't think
>> there are resources available for this now.
>>
>> I have written all this off the top of my head, but I think this topic
>> should be carefully thinking, as it may create lots of problems
>> otherwise.
>>
>> Best regards,
>>
>> César
>>
>>
>> 2010/7/7 Benjamin Ducke <benjamin.ducke at oxfordarch.co.uk>:
>>
>>> Hi all,
>>>
>>> I have just had a look at the recent changes in SVN and found
>>> that the default location for gvSIG settings has been changed
>>> from $HOME/gvSIG:
>>>
>>> Launcher.java now has this:
>>>
>>>  andamiConfigPath = System.getProperty("user.dir") +  File.separator + "andami-config.xml";
>>>  pluginsPersistencePath = System.getProperty("user.dir") + File.separator + "plugins-persistence.xml";
>>>
>>> Are you all sure this is a good idea? According to the Java documentation,
>>> "user.dir" is the "current working directory".
>>>
>>> But:
>>>
>>> 1. If the user launches gvSIG from a shell, then "user.dir" could
>>> be literally ANY location in the filesystem. So settings are bound
>>> to get lost between sessions or (even worse) they get restored from
>>> unexpected old storage locations.
>>>
>>> 2. If the user launches gvSIG via a desktop shortcut or a Mac OS
>>> App package, then "user.dir" will always point to the gvSIG installation
>>> folder. On a system set up for multiple users, with just one gvSIG
>>> installation folder, this can mean total chaos, as users overwrite each
>>> other's settings.
>>>
>>> All of that makes me a bit worried!
>>> Could someone please explain the reasoning behind this change
>>> and how it is supposed to work?
>>>
>>> I think the ONLY reasonable place for user settings has to be
>>> the user's home folder. If it is required to keep more than one
>>> set of settings, then those sets should all be kept in the home
>>> folder, perhaps in separate directories.
>>>
>>> Cheers,
>>>
>>> Ben
>>>
>>>
>>> ------
>>> Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.
>>>
>>> _______________________________________________
>>> Gvsig_internacional mailing list
>>> Gvsig_internacional at listserv.gva.es
>>> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>>>
>>>
>>
>>
>>
>>
>
> --
> Fran Peñarrubia
> Scolab
> www.scolab.es
>
> Asociación gvSIG
> www.gvsig.com
>
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   César Martínez Izquierdo
   GIS developer
   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
   ETC-LUSI: http://etc-lusi.eionet.europa.eu/
   Universitat Autònoma de Barcelona (SPAIN)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -