I'll see your advil and raise you a demerol. But it does get easier once you've identified a workflow you're comfortable with...and forget about everything else.
I believe that nothing in the config files make a difference to the rest of the code; hence, the live versions are able to be altered. (This may be true only for dspace.cfg, I'm not positive about the other configs.) The maven thing is cumbersome if you're only altering something like the config, yes. Myself, I've written some ant targets that go up the tree and grab some files, copy them to the appropriate target directory, and then into the appropriate live directory. Among those files are dspace.cfg, and the entire [dspace-source]/dspace/modules/xmlui directory. (I found it extremely onerous to wait for a build simply to put those few files up to see if a slight CSS alteration was just enough or just too much, and our server is now built so that I can't write files into the live directory...but ant can.) ant fresh_install should only be used if you've emptied out the database. It'll crap out otherwise (thankfully.) You could use update_code, but that would be overkill if you only changed a config file. update_configs should be fine for that sort of thing. B-- >>> On 2/9/2011 at 1:13 PM, in message <[email protected]>, Glenn Little <[email protected]> wrote: > Wow.. okay... complex but makes sense given the whole > dspace/java/tomcat context I guess. The thing that seems weird to me > now is the "mvn package" command, which takes a while to run and seems > to rebuild all the apps. Is that really necessary, just to make a > quick change in a config file? (I'm trying to stay with the program > and not just edit the runtime file by hand). Does it actually do > something different in the build based on the new config values, and > should I actually reinstall all the applications ("ant fresh_install") > not just the config files? I think I need a new supply of advil... > :-) > > -glenn > > On Wed, Feb 9, 2011 at 11:25 AM, Brian Freels-Stendel <[email protected]> wrote: >> Morning, >> >> I'll give it a try, since I had the same conceptual problems with the > process. >> >> Editing the [dspace-source]/dspace/config/dspace.cfg file has the benefit of > keeping everything in sync: you'll never make the mistake of moving the > source to a new machine and leaving behind customizations that you've made to > the other copies. >> >> Assuming you only edit [dspace-source]/dspace/config/dspace.cfg, then you > have to run 'mvn package' to get the updated dspace.cfg into the > .../target/build-dir/... tree, which is the place ant works. >> >> running 'ant update_configs' puts copies of any updated config files into > the [dspace] (live) directory; but if you want to be able to use them with a > simple Tomcat reboot, you need to tell ant to make the new copies the ones > Tomcat will use. You do that with the -Doverwrite=true option, so: 'ant > -Doverwrite=true update_configs'. (At the same time, ant will copy the old > config files with a '.[date]' extension (in the [dspace]/config directory.) > Otherwise, ant writes those new config files to the [dspace]/config directory > with (I believe) a '.new' extension and you have to manually remove that > extension (and rename the old config files -- the ones you want retired) to > something else, or delete them. >> >> 'ant -Dconfig=[dspace]/config/dspace.cfg' => You'd need to have an actual > command, such as update_configs or update_code for it to do anything. It > would be of use if you were editing other code (perhaps a .java file) in the > source, but do not use the source dspace.cfg file. In this case, you'd still > need to use maven to get the altered code into the ...target... directory so > that ant can put it where it belongs. >> >> I hope this helps, and that I haven't misrepresented anything.... >> >> B-- >> >>>>> On 2/9/2011 at 11:46 AM, in message >> <[email protected]>, Glenn Little >> <[email protected]> wrote: >>> Okay, I'm really confused now. These two replies are *both* different >>> from the (itself confusing) description at: >>> >>> https://wiki.duraspace.org/display/DSDOC/Configuration#Configuration-UpdateRe >>> >>> minder >>> >>> The above page does not mention running mvn at all. Where does that >>> come from? The above page also explicitly recommends not just editing >>> the runtime config file. >>> >>> What's confusing about that page itself is that it first says, >>> essentially, to edit [dspace-source]/dspace/config/dspace.cfg, then cd >>> to the target/dspace-<version>-build.dir and run "ant update_configs. >>> >>> But then it goes on with to suggest running either (or both?) of "ant >>> -Dconfig=[dspace]/config/dspace.cfg", and "ant init_configs". I'm >>> having trouble really understand the conditions under which you would >>> run one or the other of those, and how those tie in with the initial >>> "ant update_configs". Let alone how those all tie in with the two >>> suggestions given previously in this thread. >>> >>> Can anyone help unconfuse me? >>> >>> Thanks! >>> >>> -glenn >>> >>> >>> On Wed, Feb 9, 2011 at 8:43 AM, Thornton, Susan M. (LARC-B702)[LITES] >>> <[email protected]> wrote: >>>> Here is the process I follow and never have any problems. >>>> >>>> During the initial install/implementation of your DSpace instance, you will >>> make your changes to dspace.cfg in {dspace-source}/dspace/config. Then once >>> you do a "fresh-install", your /dspace directory is populated with all other >>> sub-directories like /bin /config /etc /lib /webapps, etc. >>>> >>>> From this point on, the place to make your changes to dspace.cfg is in your >>> dspace installation directory, NOT the source directory. If you do not make >>> your changes in /dspace/config/dspace.cfg, your changes will not be picked >>> up. Also remember that you have to stop and start your web server before >>> these changes will be picked up too. >>>> >>>> Hope this helps, >>>> Sue >>>> >>>> >>>> >>>> Sue Walker-Thornton >>>> Software Developer/Database Administrator >>>> NASA Langley Research Center|LITES Contract >>>> (757) 224-4074 >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: amutsikiwa [mailto:[email protected]] >>>> Sent: Wednesday, February 09, 2011 7:25 AM >>>> To: 'Glenn Little'; [email protected] >>>> Subject: Re: [Dspace-tech] modifying config dspace.cfg >>>> >>>> After making changes to [dspace-source]/dspace/config/dspace.cfg, change >>>> directory to [dspace-source]/dspace/ and then run >>>> mvn -e -o packages >>>> Then change directory to >>>> [dspace-source]/dspace/target/dspace-1.7.0-build.dir >>>> And run >>>> ant -Doverwrite=true update clean_backups >>>> >>>> >>>> The changes should be effected. >>>> >>>> >>>> Regards, >>>> >>>> Admire Mutsikiwa >>>> University of Zimbabwe >>>> >>>> -----Original Message----- >>>> From: Glenn Little [mailto:[email protected]] >>>> Sent: Wednesday, February 09, 2011 2:00 AM >>>> To: [email protected] >>>> Subject: [Dspace-tech] modifying config dspace.cfg >>>> >>>> I've got an install of dspace and am now trying to modify the >>>> dspace.cfg file. But I'm confused as to which file to edit. I >>>> thought I was supposed to do this: >>>> >>>> + edit [dspace-source]/dspace/config/dspace.cfg >>>> >>>> + change dir to [dspace-source]/dspace/target/dspace-1.7.0-build.dir >>>> >>>> + ant update_configs >>>> >>>> The problem is that this does not do anything with my new changes. >>>> Instead it puts an old copy of my dspace.cfg file over into >>>> [dspace]/config/dspace.cfg.new. As far as I can tell, that *old* copy >>>> comes from: >>>> >>>> [dspace-source]/dspace/target/dspace-1.7.0-build.dir/config/dspace.cfg >>>> >>>> So what is the real intent of the copy in dspace-<version>-build.dir >>>> compared to the one higher up in the source tree? How is one *really* >>>> supposed to update the configuration, post-install? >>>> >>>> Thanks... >>>> >>>> -glenn >>>> >>>> ---------------------------------------------------------------------------- >>>> -- >>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >>>> Pinpoint memory and threading errors before they happen. >>>> Find and fix more than 250 security defects in the development cycle. >>>> Locate bottlenecks in serial and parallel code that limit performance. >>>> http://p.sf.net/sfu/intel-dev2devfeb >>>> _______________________________________________ >>>> DSpace-tech mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/dspace-tech >>>> >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >>>> Pinpoint memory and threading errors before they happen. >>>> Find and fix more than 250 security defects in the development cycle. >>>> Locate bottlenecks in serial and parallel code that limit performance. >>>> http://p.sf.net/sfu/intel-dev2devfeb >>>> _______________________________________________ >>>> DSpace-tech mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/dspace-tech >>>> >>> >>> ------------------------------------------------------------------------------ >>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >>> Pinpoint memory and threading errors before they happen. >>> Find and fix more than 250 security defects in the development cycle. >>> Locate bottlenecks in serial and parallel code that limit performance. >>> http://p.sf.net/sfu/intel-dev2devfeb >>> _______________________________________________ >>> DSpace-tech mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/dspace-tech >> > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
