> -----Original Message----- > From: Mark H. Wood [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 23 September 2008 10:54 PM > To: dspace-tech@lists.sourceforge.net > Subject: Re: [Dspace-tech] Maintenance of side-news.html > > On Tue, Sep 23, 2008 at 02:19:45PM +1000, Gary Browne wrote: > > It's great how everything in DSpace 1.5 is maintained within the > > source code directory, makes support so much easier. > > I must disagree. I think it's a nasty muddle and I hope to > find some time to disentangle it. >
Well, if you must, you must. Personally, it has been well worth my time "disentangling" it. > > Only thing > is, there are > > exceptions. I just had a complaint (well, a query) from my > repository > > manager that the sidebar news that he changed had reverted to the > > previous version. This happened after I had done a rebuild > and deploy. > > I've had similar mishaps here. That's why I now have a > separate SCM branch for production configuration data, so I > can get back what's supposed to be there should another > update mess it up. > Sounds like you have a solution already! > > So I made some changes to the sidebar news from the GUI > (JSP) and sure > > enough, the changes are written to [dspace]/config/news-side.html, > > rather than [dspace-source]/dspace/config/news-side.html. The > > news-top.html seems to suffer the same fate ie: everytime I > rebuild, > > the news html pages in the install directory are overwritten with > > those from the source directory (as they should be). > > As they should NOT be, I would say. An install script should > NEVER override existing configuration data. IMO > [dspace-source]/config should be a collection of templates > for supplying missing files only. If the target file already > exists then it should not be touched. > BOLD text comes across as AGGRESSIVE in emails. > > Would be great if this behaviour could be changed to reflect the > > general ideology of maintaining changes within the source - > unless I'm > > mistaken about this ideology? > > I hope that you are but fear that you are not. > > > I guess currently DSpace has no way of knowing > > where your source code is? > > Correct. And that's as it should be. In some cases here > there is no source anywhere on the machine that actually runs DSpace. > I humbly agree. > We'd avoid a lot of surprise and complexity if there were a > cleaner separation between build-time, install-time, and > run-time configuration. > I currently run at least 6 instances of DSpace. I would also like to avoid complexity. Which is what the 1.5 system does for me. 6 instances, 6 configurations to take care of. Also makes replicating instances easy, just copy the source over and build. Maybe I'm missing something. I don't understand how maintaining 3 different configurations for each instance is avoiding complexity. As for surprises, if you know what's in your source configuration, then you know what's in your runtime configuration (apart from the news*.html files, but you know about that now, so it's not a surprise). > -- > Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] > Typically when a software vendor says that a product is > "intuitive" he means the exact opposite. > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
