[Gvsig_english] Recent change for gvSIG 1.10 in SVN

[Benjamin Ducke]

I think that Cesar's suggestion is a perfectly good solution.
However, I think that implementing it and testing it (including
finding all the unexpected side effects) will take time and is
a complex matter.

Therefore I vote for implementing this very critical change in
program behavior in gvSIG 2.0 and leaving gvSIG 1.10 with the
old, tested, behaviour. I think it is too fundamental a change
to still go in for 1.10, which is already at RC level.

Cheers,

Ben

----- Original Message -----
> 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


------
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.