overriding system properties in maven - java

I have a web application with a couple of profiles - for production and for local testing;
build is executed with maven;
logback is used for logging
so some of logs write to files - the problem is:
in production we use tomcat and CATALINA_HOME is set on server,
but locally we often use jetty, so tomcat may even not be configured
so in prod i want to write log in file this way:
${catalina.home}/logs/profiler.%d{yyyy-MM-dd}.log
how do I set maven override this ${catalina.home} property
how do i set it from maven (do i need system properties or just maven properties)
may i make it conditional? (if it is not set on the local system then use the property
defined in #1)
thanks a lot!
tatiana.

You can define a maven property, say log.dir and set it to appropriate values in each profile.
Say,
<profile>
<id>dev</id>
<properties>
<log.dir>${catalina.home}/...</log.dirv>
</properties>
</profile>

Related

Deploying two different versions of same jars through jenkings on different servers

I have two servers for my java application and I'm using jenkins to deploy my code on those servers. The application is same but because of the nature of work we are doing we need different versions of same custom jars on each server.
1: I've tried to set environment variables and tried to get artifact and group Id's of those in pom.xml but we can not access environment variables in pom.xml
2: I've tried changing their names and import both jars but that's insane one of them is ignored and both the servers use only one version.
I've been struggling with it for a long time now, The only possible solution that comes to my mind is that i create two different git repositories and make different jenkin jobs for every server.
Can anyone help me figure out how can I import different versions on different servers, that'd mean a lot. Thanks in advance.
If I get you correctly,
different versions of some custom jars
are different version of yours dependencies. This can be easily achieved using maven profiles. Your pom.xml would look similair to this (XML is simplified to minimum.
<project>
<!-- Basic info like model, artifact, group etc. -->
<dependencies>
<!-- Your usual deps as you are used to -->
</dependencies>
<profiles>
<profile>
<id>profile1</id>
<dependencies>
<!-- Extra deps for this profile -->
</dependencies>
</profile>
<profile>
<id>profile2</id>
<dependencies>
<!-- Extra deps for this profile -->
</dependencies>
</profile>
</profiles>
</project>
IDEs commonly provides way to set profile, so devs should not have problem . From jenkins, are while building from command line you would be invoking command with given profile. You can have separate jobs or you can create your job with parameters.
mvn install -P profile1
Alternatively, profile can be activated by enviroment variable. Problem may be that this variable must be availble during compilation.
Another aproach would be branching your code for different customers as Abhilas mentioned in comment.

Maven build profiles in a mutli-module project property expansion

I have a Multi-Module Maven project. My parent POM has the following modules:
<module>common</module>
<module>ingest</module>
<module>package</module>
The package modules handles all aspects of building a deployable zip file using maven-antrun-plugin. The other two modules are where the core application code is located. Within the package I have various profiles holding the configuration settings for production, staging and development environments. Each profile looks like:
<profile>
<id>prod</id>
<properties>
<oozie.url>http://oozie-server:11000/oozie</oozie.url>
<stage.user>prod-stage</stage.user>
</properties>
</profile>
This works perfectly at the parent level, running:
mvn clean install -P prod
All the .properties file have the various properties expanded to be the ones in the Maven profile.
Within the ingest module, one class may rely upon a .properties file with the ingest module. The contents of this properties file will look something like:
stageUser=${stage.user}
When running tests for the ingest module, the properties are not expanded to be the properties from the build profile e.g. the property will still be stageUser=${stage.user} rather than stageUser=prod-stage. This causes the test to fail.
The only workaround I have is to add in the required profiles and properties to get the test to pass into the ingest POM. This means I have these properties in two locations both the package and ingest modules. Is there a better solution to this?
The inheritance of properties from the parent should work. Make sure you have the parent declaration in the child modules:
<parent>
<artifactId>parent</artifactId>
<groupId>parentGroupId</groupId>
<version>version</version>
</parent>

How to optimise deployment of repository to production server Hippo CMS?

Problems:
Deployment took too long
Namespaces, configurations and contents missing in production server
What I've done:
Followed the guide to deploy my Hippo CMS project here.
What I've found:
When I extract the distribution file, I've found cms.war which includes a huge bootstrap content jar (140MB; myproject-bootstrap-content-2.01.08-SNAPSHOT).
I have a feeling that in my production server, Hippo will try to expand this jar file and write to my production MySQL server.
(That sounds a bit scary to me.)
Am I correct?
It makes the distribution file very big, right now it's 160MB we haven't even launched out site which has relatively little contents yet.
Can we configure Hippo to not include the bootstrap jar and simply connect to the MySQL database assigned?
The contents can be filled up manually.
Data entry is supposed to be a separate matter right?
you can exclude bootstrap jar by creating another profile which includes your content dependency.
Just edit cms/pom.xml and add following:
<profiles>
<profile>
<id>local</id>
<dependencies>
<dependency>
<groupId>com.YOURGROUP</groupId>
<artifactId>YOURPROJECT_ARTIFACT-bootstrap-content</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
</profile>
now you can activate this by using mvn package -Plocal
By default it will not be included in distribution package (unless you add -Plocal of course)

Generate property file as per environment by passing multiple environment

I have one situation where I need to create multiple configuration property file by passing environment.
i.e : I have environment like dev, prod, qa, int, but I want to create jar only for int and dev in one go
My First question is: "Is there any way in maven where we can pass multiple environment value" ?
If this is possible how can I setup my pom.xml to accept the multiple env value ?
It's not quite clear what you mean with "pass multiple environment value".
If you want to activate a set of properties depending on the execution environment you could use maven profiles.
Here is an example for two profiles, which you can add to a pom.xml.
<profiles>
<profile>
<id>prod</id>
<properties>
<value1>a</value1>
<value2>b</value2>
</properties>
</profile>
<profile>
<id>qa</id>
<properties>
<value1>x</value1>
<value2>y</value2>
</properties>
</profile>
</profiles>
You could then for example activate profile "prod" by calling maven with the paramter "-Pprod".
I fear you can't trigger 2 different packaging with per-profile filtered resources in one build.
If you want to activate 2 profile at once you can specify them both using -P or trigger the activation according to the same property (see Maven: Only execute plugin when a command line flag is present)
If I correctly understand your question, i'd suggest to delegate the build of the integration artifact to a continuous integration server which will trigger the appropriate resource filtering using a dedicated profile and to set the dev profile as default one for the daily developers builds.

Using maven to create a .war file, how can I use my production resources?

I use this to build my spring mvc app:
mvn clean package
I use the maven war plugin to create a war file, but the problem I am facing is that in my resources folder I have my development versions of my .properties files for log4j etc.
When I push to production, and run:
java -jar ...
It explodeds the war file, and then at that point I can modify the .properties files with my production settings, but I obviously want to do this during my maven build for production.
Is there a way I can tell maven that this is a production build, so get these files from somewhere else? And during development, keep doing what it is doing now?
User maven profiles. Maven profiles help you in specifying different properties for different profiles. So you can have two profiles - development and production.
Something like this -
<profiles>
<profile>
<id>development</id>
<!-- we'll properties here... -->
</profile>
<profile>
<id>production</id>
<!-- ...and here -->
</profile>
</profiles>
Like this example -
<profile>
<id>development</id>
<properties>
<db.driverClass>oracle.jdbc.driver.OracleDriver</db.driverClass>
<db.connectionURL>jdbc:oracle:thin:#127.0.0.1:1521:XE</db.connectionURL>
</properties>
</profile>
<profile>
<id>production</id>
<properties>
<db.driverClass>oracle.jdbc.driver.OracleDriver</db.driverClass>
<db.connectionURL>jdbc:oracle:thin:#134.0.0.1:3124:XE</db.connectionURL>
</properties>
</profile>
There are a couple of options here. The first (as others have mentioned as well) is to use maven profiles. Instead of having multiple version of your properties files, you would have something like:
mypropsfile.properties
-----------------------
prop1=${prop1.val}
prop2=${prop2.val}
Then in your profiles, you can define values for those properties (make sure you have resource filtering enabled for this to work. see an example http://www.manydesigns.com/en/portofino/portofino3/tutorials/using-maven-profiles-and-resource-filtering).
You can also have your properties file have production values in it but with the ability to override those files in development. Spring profiles are helpful for this. For example, in development mode you can look for a properties file named <user-home>/mypropertiesoverride.properties, which could be used to override any of the production value properties with development specific ones.
I prefer the second method here where you have a default properties file and then you can just override select properties.

Categories