Hi there!
Thanks very much for your always helpful responses!
Just one question to clarify:
I'm assuming that once we would copy the /webapps directory over to the
Production machine, we will have to run ant, but not mvn? Is that correct?
Of course we have to have our dspace.cfg file configured for Production,
but are there any other files that will need to be edited once they're copied
over to Production?
Thanks again for your prompt reply!
Best regards,
Sue
------------------------------------------------------------------------
Sue Thornton
Office: (757) 224-4130
Mobile: (757) 506-9903
[email protected]
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of helix84
Sent: Monday, July 22, 2013 11:28 AM
To: Thornton, Susan M. (LARC-B702)[LITES]
Cc: dspace-tech ([email protected])
Subject: Re: [Dspace-tech] Question about deploying the DSpace application
On Mon, Jul 22, 2013 at 5:08 PM, Thornton, Susan M. (LARC-B702)[LITES]
<[email protected]> wrote:
> Here are my questions:
>
> 1. Why don’t we deploy the .war file like we used to? Why the
> change, what’s the difference in doing it this way, and are there any
> benefits?
Hi Sue,
I'm not an expert in this, so I'll leave someone else answer it:
http://stackoverflow.com/questions/3906881/advantages-disadvantages-to-exploded-wars
My personal point of view:
With WARs, Tomcat would detect when you deleted/updated the WAR and
undeploy/redeploy it.
With the new recommended approach, where you configure <Context>s in individual
context fragments (.xml files), you can simply delete/touch the context
fragment.
> 2. We are modifying the structure of our new DSpace sites, to
> include a separate PostgreSQL server and not having the DSpace source
> code on the Production server. The SAs have asked me to find out:
>
> a. If we can deploy DSpace 3.1 with a .war file that can just be
> copied over from the Dev machine once we’re ready to go to Production?
The webapps (whether WARs or exploded) will be the same.
Note the difference in configuration: You only need to change dspace.hostname
and possibly dspace.baseUrl and dspace.url.
Then there are also other directories in [dspace], but after the upgrade, if
you're only redeploying changed code, you most likely don't need to change
anything there. For the upgrade itself, all the changes to these directories
will be covered in the upgrading docs.
> b. Are there any other ways of doing this so the DSpace source code
> is NOT on the Production server?
Sure, you could actually use the binary distribution and never touch the actual
source code. You still need to do mvn package, though, to create the webapps.
Once you've upgraded and you only want to redeploy changed webapps from dev to
production, you could skip the ant step and just copy over the webapps manually.
I hope this answers your questions, let me know if it doesn't. In some parts I
felt like I could go into more detail but I didn't want to flood you with too
much information.
Regards,
~~helix84
Compulsory reading: DSpace Mailing List Etiquette
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
