Re: Improving maven/wicket deployment process
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 igor.vaynb...@gmail.comwrote:
we used to do something like this before we switched to jndi
valueclasspath*:/application.properties/value -- prod values
valueconf/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 Millstau...@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:
valueclasspath*:/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 Millstau...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Improving maven/wicket deployment process
we used to do something like this before we switched to jndi
valueclasspath*:/application.properties/value -- prod values
valueconf/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 Millstau...@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:
valueclasspath*:/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 Millstau...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Improving maven/wicket deployment process
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:
valueclasspath*:/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 Millstau...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Improving maven/wicket deployment process
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Improving maven/wicket deployment process
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 Millstau...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Improving maven/wicket deployment process
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
