Maven - In Real Time
A perfect dependency management tool that most of us have used in our projects.
I would like to share some real-time problem scenarios that Maven is able to address pretty well.
Mr.Yan is working as a build management engineer. He takes care of the build and deploy environment in his company on a daily basis.
After doing is routine tasks, he was frustated due to the increasing work load because of multiple OS and Java versions. His entire day was gone in editing the property files and pom files.
What a Maven Profile can do for us?
Maven Profile is used for the following:
* Package the Build in different formats
* Dynamically inject the dependencies
* choose which source files or resources to be inculded/excluded for build (optional java files includes & excludes)
* Activation based on various JDK version/OS version/Property(only System Property)
Lets see a quick snapshot of Pom,
This made his life easier... Now Yan wants to activate a profile and he types a simple command
mvn -P profileName
and he wants to call using properties
mvn -Dprop=value
After doing all these changes, now he is enjoying his life without any manual work in build managment :) :)
Published at DZone with permission of its author, Karthikeyan Kanagaraj.I would like to share some real-time problem scenarios that Maven is able to address pretty well.
Mr.Yan is working as a build management engineer. He takes care of the build and deploy environment in his company on a daily basis.
After doing is routine tasks, he was frustated due to the increasing work load because of multiple OS and Java versions. His entire day was gone in editing the property files and pom files.
Finally, he started searching for a tool that would help make his work easier and atlast founfd it to be Maven... After going through the documentation, he realized "Profiles" in maven can do it.
What a Maven Profile can do for us?
Maven Profile is used for the following:
* Package the Build in different formats
* Dynamically inject the dependencies
* choose which source files or resources to be inculded/excluded for build (optional java files includes & excludes)
* Activation based on various JDK version/OS version/Property(only System Property)
Lets see a quick snapshot of Pom,
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>MyTest</groupId>
<artifactId>MyTest</artifactId>
<version>0.0.1-SNAPSHOT</version>
<profiles>
<profile>
<id>yan1</id>
<activation>
<activeByDefault>false</activeByDefault>
<jdk>1.5</jdk> <!--this profile will be activated if the JDK is 1.5 -->
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
<includes> <!--can include/Exclude the sources based on the profile -->
<include>**/MyTest1.java</include>
<include>**/service/**</include>
</includes>
</configuration>
</plugin>
</plugins>
</build>
<dependencies><!-- we can tell the dependencies for this profile alone--></dependencies>
</profile>
<profile>
<id>yan2</id>
<activation>
<activeByDefault>false</activeByDefault>
<property><!--this profile will be activated when the system property hq.version is 2 -->
<name>hq.version</name>
<value>2</value>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
<excludes><!--can include/Exclude the sources based on the profile -->
<exclude>**/MyTest2.java</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
<dependencies><!-- we can tell the dependencies for this profile alone--></dependencies>
</profile>
</profiles>
</project>
This made his life easier... Now Yan wants to activate a profile and he types a simple command
mvn -P profileName
and he wants to call using properties
mvn -Dprop=value
After doing all these changes, now he is enjoying his life without any manual work in build managment :) :)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Jilles Van Gurp replied on Fri, 2012/06/15 - 2:43am
Profiles have one big pit fall: copy paste reuse. In my experience, most engineers regard pom files as something that you write once and then never look at again. To create a new one, you simply copy another one and tweak until it sort of does what you need. Add profiles in the mix and you are now copy pasting large amounts of slightly different xml that does more or less the same. I don't know about you but, using copy paste makes me feel stupid and slightly dirty.
Fast forward a two years or so and add a bit of team growth/mutation into the mix and you have a one hell of a cluster fuck of a build. This is not a hypotethical situation. I've been on several of these projects and inherited such pom files. My current project has a 100+ maven modules, dozens of profiles that affect most of them, a huge dependency mess. Fixing this will take months and I don't have those months. People have looked at this build and ended up running away in disgust. The worst part is that it sort of works enough that most people don't see fixing this as a priority. So instead things are getting worse all the time.
The best pom files are very short and don't do anything outside of maven's comfort zone (which is actually quite a lot when it comes to typical software projects). If you need to tweak half a dozen of plugins to do something simple, maybe you are using the wrong tool for the wrong job. If a four line bash script turns into a 1500 line pom file, you are doing something wrong.
So, yes, profiles are a good way to customize your builds but having to do that already means you are in trouble.
Maven is fine when you limit it to compile, test, package, install, deploy type stuff. It does that well.
Instead of complex maven builds to do complex things like starting test servers, wiping databases, creating and deploying rpms, use some simple scripts to automate these things. I've seen pom files try to do all of these things and it totally sucked. Keep it simple. Then use something like Jenkins to make those activities repeatable and consistent. Jenkins is a great tool to automate stuff. It's best feature is that it can execute bash scripts as part of a job.
Karthikeyan Kan... replied on Fri, 2012/06/15 - 7:11am
in response to:
Jilles Van Gurp
There is a use case when we need to combine a rich dependency with profile , then ultimately Maven profiles is the choice.
consider this scenario,
I have a source code that uses one of the third party api. The third party is changing in signatures in releases(i mean no reverse compatiability). so i need to build my code by choosing my specific files with that release specific thrid party api.(along with dependency management)
In the above case, we can use maven profiles. my suggestion is if we want to do a build specfic to some resources along with dependency management then ultimate choice should be maven profiles.
moreover i agree with your point, it cant be used for multiple dozens of profile, but in medium size projects mostly they will not use multiple dozens.