[Gvsig_english] Recent change for gvSIG 1.10 in SVN

[Pablo Sanxiao]

Hi all,

This change was really thinking for the gvSIG portable version where it
makes a lot of sense to save the configurations in the application
folder so that you can distribute a pre-configured gvSIG version ready
to be used in courses, demos, etc.

I agree with all the problems that this change could cause and you have
commented but the old solution, although it is tested, it is not the
good in my humbled opinion since, right know, gvSIG 1.9 is the last
stable version, but many useful extensions are not adapted jet therefore
many users need to have installed both versions, 1.1.2 and 1.9 and
cannot have different configurations for them it is really a problem.

Summarizing, I agree that the change should be reverted and the last
solution proposal by Fran should be applied. To have a gvSIG version
directory within the HOME directory could be a very good intermediate
solution and could be applied in the 1.10 version since is a minor
change.

Regards,

On Xov, 2010-07-08 at 09:57 +0200, César Martínez Izquierdo wrote:
> 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
> >
> 
> 
> 

-- 
Pablo Sanxiao Roca
Grupo de Desarrollo
Cartolab - Laboratorio de Ingeniería Cartográfica
http://www.cartolab.es

ETS Ingeniería de Caminos, Canales y Puertos
Universidade da Coruña
Campus de Elviña - 15071 A Coruña (España)
(34)981167000 ext. 5493