CODEWITHSUNDEEP
javamavendeploymentmaven-2build-process
NVD
NVD

Reputation: 15

Maven build process/deployment & properties at runtime

I have a vaadin project with maven and some properties. The properties includes filepaths, filenames etc.

I've also created maven profiles for development and production. For development my application runs with jetty, in production it should run with tomcat 8. (my target is a .WAR file)

Everything works fine so far, but now I need to prepare for the production build and "go live". So I need to create different properties, one for development and one for production.

But the application needs to load the right properties based on the environment, am I right? So if local machine use property a, else use property B.

What's the best practice in this case? What am I suppose to do with my properties and pom files? How should the build process looks like?

I hope I could explain it clearly, otherwise I will share more information.

Any ideas would be helpful. Thanks a lot.

PS. Sorry, but that's my first production build!!!

Upvotes: 1

Views: 98

Answers (2)

Phylock
Phylock

Reputation: 171

With Maven Resource Plugin you can include/exclude resources based on the active profile.

Or you could do it as part of the package process with the Maven Assembly Plugin

Upvotes: 0

skuro
skuro

Reputation: 13514

The best approach is to externalise your configuration outside of your WAR file in a .properties file or similar format, then let your application fetch such file at bootstrap. Common approaches for discovering the configuration file are:

  • a predefined location within the application CLASSPATH
  • a predefined location on the file system
  • a location (either CLASSPATH or FS) specified by a startup parameter (eg.: -Dmyapp.config=...
  • a JNDI environment property which points to the right location
  • all of the above together, in a chain of responsibility fashion

Depending on your deployment model, keeping the properties within the pom.xml might not be convenient, as you don't usually want e.g. the production database password in there, or anywhere in your source code anyway.

Properties for the local environment can indeed be put within the pom.xml, then you can also use filtering to populate a properties file with them and load such file from your application. The same approach can be used together with profiles to target more than one environment.

Then, if you need to provision the correct properties to all the environments you use (eg. if you're rolling out a full DTAP street) I'd recommend you to have a look at some provisioners / configuration managers such as Ansible, Salt, Chef, Puppet and the likes.

Upvotes: 1

Related Questions