• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Maven deploy same war for different environments

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I have been thinking about this issue for quite some time now. I am sure its quite common and would like to know how you have solved it.

I have a single war file that needs to get deployed to different environments.... say QA and SIT and finally PROD.
I am using Maven as the build system.

I have used resource filtering based on different maven profiles for each environment like mentioned here:
http://sujitpal.blogspot.com.au/2006/10/maven2-multi-environment-filter-setup.html

It seems to work, but for each environment, I have to build(compile) again even though the only difference is the property files that should get updated.

Ideally, I would like to provide PROD the same WAR file that got tested in QA (with property files updated).

Currently, I am manually providing the WAR file with property files "patched" in to the WAR for different environments.

I am sure there is a better way to do this in maven. Currently considering one of the following:

  • Externalizing the property files altogether and providing them separately.
  • Including property files for all environments in the WAR and load the relevant ones during startup.



  • Would love to hear your comments and hopefully find a better way.
     
    Vikas Brdwaj
    Greenhorn
    Posts: 3
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks for posting the link.

    Jrebel is an interesting software. But it does not solve my problem.

    It publishes code/property changes for a single container.

    I need to deploy to a completely different environments. I understand that using this software makes creating WAR archives redundant. But that is how I am required to provide the release.
    Furthermore, I dont see Jrebel plugged into Production servers any time soon.
     
    author & internet detective
    Posts: 41860
    908
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I think your first approach (Externalizing the property files altogether and providing them separately.) is best. You can even use Maven to package all of the environment property files. As part of your deployment process, you'd need to unjar the correct one and add it to your classpath.

    This is a feature that really irks me about Maven. It is "the Maven way" to include your property files inside the jar files and recreate the war for each environment. Big companies don't like different software packages for different environments. Even when you ask in Maven training what to do, the answer is to recreate the jars. Leaving you with something nonstandard to solve the problem.
     
    Vikas Brdwaj
    Greenhorn
    Posts: 3
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks for that Jeanne,

    Its good to know that I am not the only one irked by this missing feature in Maven.
    Even though, I have googled this numerous times on previous occasions, yesterday, I was able to get some interesting links.

    So far, I have not been able to find a standard maven way around this problem.
    I would appreciate if more links/comments/opinions could be added to this post as I feel, this should be a very important feature of a build/deploy system.

    http://stackoverflow.com/questions/1149352/using-maven-for-multiple-deployment-environment-production-development
    http://stackoverflow.com/questions/5967405/handling-of-configuration-files-in-j2ee-web-applications
    http://stackoverflow.com/questions/3233535/suggest-a-good-approach-for-targeting-different-databases-and-configurations-for
    http://stackoverflow.com/questions/12362984/property-file-processing-during-build-time
    http://stackoverflow.com/questions/8066230/maven-deployment-time-filtering
    http://stackoverflow.com/questions/1634458/can-i-use-a-single-war-file-in-multiple-environments-should-i
     
    Rancher
    Posts: 2759
    32
    Eclipse IDE Spring Tomcat Server
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I'm not a big fan of the build tool acting as a deploy tool. The whole point of a build tool is to create artifacts that can be deployed anywhere. The job of a deploy tool is to deploy and configure artifacts depending on the configuration of the target system. If you make your build tool act as a deploy tool, then you risk corrupting your build tool with environment specifics.

    I can understand the need to automate deployment in continious integeration environments. IMO, the build tool should build the deploy tool, and continious integeration server should call the built deploy tool to deploy runtime artifacts into your environment. You don't need Maven to do something that a simple batch script can do.. and is better at. Heck, go nuts and even use ANT. Keep it out of Maven.
     
    Jeanne Boyarsky
    author & internet detective
    Posts: 41860
    908
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Jayesh,
    Agreed. The problem is that "the Maven way" includes property files in the jars which are in the war. Which means the generated war can't just be deployed to different environments using a deploy script. And a deploy script has no business unjarring the war to change things.
     
    Jayesh A Lalwani
    Rancher
    Posts: 2759
    32
    Eclipse IDE Spring Tomcat Server
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Maven doesn't tell you to put environment specific runtime properties in the war. What should go into the maven properties should be the Build time properties. For example, lets say in production, you have a login module that authenticates the user against LDAP. Now, for developers, you really don't want to setup LDAP, and you just want to mock the login module. So, you put the class name of the login module in a property file. You setup the property file to be filtered by maven, default the property to LDAPLoginModule, and allow the developers to override that property to MockLoginModule. When you use LDAPLoginModule, you need the ldap URL etc. these are Runtime properties that shouldn't be internalized in the war. Instead there should be an install module that contains a script that copies the external property file in the correct place within the system.

    Yes, this does force you to think about what is a runtime property vs what's a build time property. In the long run that's a good thing. Eventually, all applications reach configuration bloat: there are so many configurable properties that no one can keep track of them. By separating your build time properties from runtime, you start to control them much better. Maven even lets you constrain each build time property to the module that needs the property
     
    Saloon Keeper
    Posts: 27762
    196
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I ALWAYS build a single WAR file for development, testing, and production. I do this because it prevents me from deploying the wrong WAR for the wrong environment and because it assures me that the code I'm debugging is the same as the code that's malfunctioning on the production server.

    My configuration information is all external. Since most of my webapps run under Tomcat, I usually put the anchor information for environmentally-specific items in an external Tomcat Context definition. That information includes (as needed) database connection pools, data directory paths, locations of any properties files, etc.
     
    Space pants. Tiny ad:
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic