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 wrote:
> we used to do something like this before we switched to jndi
>
> classpath*:/application.properties <-- prod values
> conf/application.${user.name}.properties
>
> that way each dev can create a conf/application. 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 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:
> > classpath*:/application.${env}.properties
> >
> > 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
> 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
classpath*:/application.properties <-- prod values
conf/application.${user.name}.properties
that way each dev can create a conf/application..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 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:
> classpath*:/application.${env}.properties
>
> 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 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:
classpath*:/application.${env}.properties
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 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 Mills 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
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
