You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Tauren Mills <ta...@tauren.com> on 2009/08/16 05:33:24 UTC
Improving maven/wicket deployment process
I currently don't have an automated deployment process in place for a
wicket/spring/hibernate/maven project and am looking for suggestions
on how to best implement one. I'm open to any suggestions as well as
references to helpful URLs and other resources.
When it is time to deploy my project, I manually go through the following steps:
1. Edit application.properties and comment out my local development
database configuration and uncomment the production database
configuration. The settings in this file (jdbc.driver, jdbc.url,
jdbc.username, jdbc.password, hibernate.dialect,
hibernate.hbm2ddl.auto) are used in my spring configuration files to
create a datasource and sessionfactory.
2. Edit web.xml and change the configuration context-param from
development to deployment.
3. Run mvn install
4. scp the newly built war file from my local maven repo to the
jetty/webapps folder on my deployment server.
5. Remove the existing ROOT.war file from the deployment server.
6. Rename the new war file to ROOT.war
7. Restart the deployment jetty server
Of course, this assumes there are no complex database changes required
by the new version that can't be handled by hbm2ddl.auto=update. If
there are, then I also need to apply an sql update script to the
database.
I'm sure that this process can be streamlined. I plan to look into
mvn deploy and see what I can accomplish. I believe there are also
ways to use maven to have development and deployment versions of
different files such as application.properties.
If you have already solved these types of problems, I'd love to hear
how you did it.
Thanks!
Tauren
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Improving maven/wicket deployment process
Posted by Jeremy Thomerson <je...@wickettraining.com>.
I have a shell script that does most of this stuff. Here's my steps:
1 - mvn clean package
2 - scp package to server(s)
3 - on server, run deploy script
3a - script makes temp working directory
3b - script copies web.xml, application.properties, etc from prod into temp dir
3c - script unzips war into proper location
3d - script copies the production web.xml, etc, back into place
3e - script restarts tomcat / apache (not necessary depending on your
config, it's just how I like to do it)
Most of the applications that I currently maintain can be deployed to
production within about five minutes, including build, upload time,
etc. (of course the automated tests take longer on some applications -
this is excluding test time)
--
Jeremy Thomerson
http://www.wickettraining.com
On Sat, Aug 15, 2009 at 10:33 PM, Tauren Mills<ta...@tauren.com> wrote:
> I currently don't have an automated deployment process in place for a
> wicket/spring/hibernate/maven project and am looking for suggestions
> on how to best implement one. I'm open to any suggestions as well as
> references to helpful URLs and other resources.
>
> When it is time to deploy my project, I manually go through the following steps:
>
> 1. Edit application.properties and comment out my local development
> database configuration and uncomment the production database
> configuration. The settings in this file (jdbc.driver, jdbc.url,
> jdbc.username, jdbc.password, hibernate.dialect,
> hibernate.hbm2ddl.auto) are used in my spring configuration files to
> create a datasource and sessionfactory.
>
> 2. Edit web.xml and change the configuration context-param from
> development to deployment.
>
> 3. Run mvn install
>
> 4. scp the newly built war file from my local maven repo to the
> jetty/webapps folder on my deployment server.
>
> 5. Remove the existing ROOT.war file from the deployment server.
>
> 6. Rename the new war file to ROOT.war
>
> 7. Restart the deployment jetty server
>
> Of course, this assumes there are no complex database changes required
> by the new version that can't be handled by hbm2ddl.auto=update. If
> there are, then I also need to apply an sql update script to the
> database.
>
> I'm sure that this process can be streamlined. I plan to look into
> mvn deploy and see what I can accomplish. I believe there are also
> ways to use maven to have development and deployment versions of
> different files such as application.properties.
>
> If you have already solved these types of problems, I'd love to hear
> how you did it.
>
> Thanks!
> Tauren
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Improving maven/wicket deployment process
Posted by Tauren Mills <ta...@tauren.com>.
Igor,
Thanks for the suggestion. Definitely looks like a good way to go.
Tauren
On Sun, Aug 23, 2009 at 5:02 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> we used to do something like this before we switched to jndi
>
> <value>classpath*:/application.properties</value> <-- prod values
> <value>conf/application.${user.name}.properties</value>
>
> that way each dev can create a conf/application.<their user
> name>.properties and override production settings with their own.
>
> for different envs you simply override the value of user.name with by
> defining it with -Duser.name
>
> -igor
>
> On Fri, Aug 21, 2009 at 4:27 PM, Tauren Mills<ta...@groovee.com> wrote:
> > I just wanted to follow up on this. As an interim solution until I
> > have time to really do this right (using Hudson, etc.), I've done what
> > is suggested here:
> > http://www.developer.com/java/ent/article.php/3811931
> >
> > In my spring config PropertyPlaceholderConfigurer, I use this:
> > <value>classpath*:/application.${env}.properties</value>
> >
> > This means that steps 1 and 2 have been resolved without the effort
> > required to switch to using JNDI, maven profiles, or other build
> > tools. All I do is specify -Denv=prod on my production server and
> > -Denv=dev -Dwicket.configuration=development on my development system.
> > I can add additional staging, QA, and other servers with this
> > scenario, and it doesn't require a separate WAR for each one.
> >
> > Tauren
> >
> >
> > On Mon, Aug 17, 2009 at 11:07 AM, Tauren Mills<ta...@groovee.com>
> wrote:
> >> Janos and Jeremy,
> >>
> >> Thank you both for your feedback!
> >>
> >> After considering your answers, I think that using Maven profiles is
> >> most in line with my needs. And the suggestion to use the command
> >> line -Dwicket.configuration=deployment parameter will certainly help.
> >> I've never used Hudson before, but I'm looking into it now. It sounds
> >> like it could help simplify things significantly.
> >>
> >> Thanks again,
> >> Tauren
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Improving maven/wicket deployment process
Posted by Igor Vaynberg <ig...@gmail.com>.
we used to do something like this before we switched to jndi
<value>classpath*:/application.properties</value> <-- prod values
<value>conf/application.${user.name}.properties</value>
that way each dev can create a conf/application.<their user
name>.properties and override production settings with their own.
for different envs you simply override the value of user.name with by
defining it with -Duser.name
-igor
On Fri, Aug 21, 2009 at 4:27 PM, Tauren Mills<ta...@groovee.com> wrote:
> I just wanted to follow up on this. As an interim solution until I
> have time to really do this right (using Hudson, etc.), I've done what
> is suggested here:
> http://www.developer.com/java/ent/article.php/3811931
>
> In my spring config PropertyPlaceholderConfigurer, I use this:
> <value>classpath*:/application.${env}.properties</value>
>
> This means that steps 1 and 2 have been resolved without the effort
> required to switch to using JNDI, maven profiles, or other build
> tools. All I do is specify -Denv=prod on my production server and
> -Denv=dev -Dwicket.configuration=development on my development system.
> I can add additional staging, QA, and other servers with this
> scenario, and it doesn't require a separate WAR for each one.
>
> Tauren
>
>
> On Mon, Aug 17, 2009 at 11:07 AM, Tauren Mills<ta...@groovee.com> wrote:
>> Janos and Jeremy,
>>
>> Thank you both for your feedback!
>>
>> After considering your answers, I think that using Maven profiles is
>> most in line with my needs. And the suggestion to use the command
>> line -Dwicket.configuration=deployment parameter will certainly help.
>> I've never used Hudson before, but I'm looking into it now. It sounds
>> like it could help simplify things significantly.
>>
>> Thanks again,
>> Tauren
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Improving maven/wicket deployment process
Posted by Tauren Mills <ta...@groovee.com>.
Janos and Jeremy,
Thank you both for your feedback!
After considering your answers, I think that using Maven profiles is
most in line with my needs. And the suggestion to use the command
line -Dwicket.configuration=deployment parameter will certainly help.
I've never used Hudson before, but I'm looking into it now. It sounds
like it could help simplify things significantly.
Thanks again,
Tauren
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Improving maven/wicket deployment process
Posted by Cserep Janos <cs...@szeretgom.hu>.
> 1. Edit application.properties and comment out my local development
> database configuration and uncomment the production database
> configuration. The settings in this file (jdbc.driver, jdbc.url,
> jdbc.username, jdbc.password, hibernate.dialect,
> hibernate.hbm2ddl.auto) are used in my spring configuration files to
> create a datasource and sessionfactory.
I prefer JNDI bound datasources configured in the app server (running
mainly on glassfish), but you could use maven profiles and properties
defined in profiles with property substitution in
application.properties.
On profiles: http://maven.apache.org/guides/introduction/introduction-to-profiles.html
On property substitution with a Hudson example:
http://weblogs.java.net/blog/johnsmart/archive/2008/03/using_hudson_en.html
> 2. Edit web.xml and change the configuration context-param from
> development to deployment.
I use the jvm startup parameter: -Dwicket.configuration=deployment on
all production server instances as it overrides web.xml.
>
> 3. Run mvn install
I use Hudson with standard maven build definitions to build everything
that ever gets deployed to stage and production servers.
> 4. scp the newly built war file from my local maven repo to the
> jetty/webapps folder on my deployment server.
> 5. Remove the existing ROOT.war file from the deployment server.
>
> 6. Rename the new war file to ROOT.war
>
> 7. Restart the deployment jetty server
I use a custom Hudson task to deploy the last successful build in
glassfish - a couple of shell commands do the trick. I even have
custom tasks to copy the production db to staging - it's very
convenient to automate such tasks with it.
Janos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org