aspose file tools*
The moose likes Ant, Maven and Other Build Tools and the fly likes Maven resources/filtering/profiles - build ALL profiles? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Ant, Maven and Other Build Tools
Bookmark "Maven resources/filtering/profiles - build ALL profiles?" Watch "Maven resources/filtering/profiles - build ALL profiles?" New topic
Author

Maven resources/filtering/profiles - build ALL profiles?

Dudley Dawson
Ranch Hand

Joined: Dec 14, 2004
Posts: 57
Hi-
I'm new to maven. Trying to ports some existing ant builds to maven, as well as establish some new standards for our build process.

It is our policy to only build 1 deployable war. all environment-specific configurations are kept separate, and we build them all together at once. so under our current Ant process, we have a properties file for each environment, loop over them, and create a set of config files with a replacefilterfile.
So, in our source, we have dev.properties, test.properties, and prod.properties. In the resulting build, we have:

and so on...

it seems like maven can almost do this with its resources plugin, but by default, everything in the resources dir gets copied to the WAR classpath (i'm guessing this is configurable)
but more importantly: it seems you can only build 1 profile at a time, which is specified at the time maven is executed. This is going to cause problems for our deployment process.

Is there a way to do what i've described with maven?
Martijn Verburg
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

You need to think about using Maven Profiles . I highly recommend the free Maven Definitive Guide Book/PDF by Sonatype which walks you through this process!


Cheers, Martijn - Blog,
Twitter, PCGen, Ikasan, My The Well-Grounded Java Developer book!,
My start-up.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16068
    
  21

Actually, your definition of "one war" and mine don't seem to be the same. I, too, build only one war, but it's the same war for development, test, and production. Bit-for-bit, byte-for-byte. Build one WAR file and deploy it to whichever server. There's no per-server properties files inside the WAR. And no danger of accidentally deploying a test WAR on the production server, since the test WAR is the production WAR. The attributes that make a WAR a "test" war are all injected from external sources.

I think you actually already know about Maven profiles, but you're mistaken about one thing. You most definitely can specify more than one profile on a build, and that can be useful when you have to do things like say, build a WebSphere WAR for iSeries when you also provide a WebLogic WAR for Linux. Mix and match OS's and server environments using combinations of profiles.

Incidentally, I find this annoying, but profiles do not override mainstream resources. If you want a custom web.xml, for example, you can't provide a default web.xml in the src/main/webapp or it will take precedence over a profile-specific src/tomcat/webapp version of the same file.


Customer surveys are for companies who didn't pay proper attention to begin with.
Dudley Dawson
Ranch Hand

Joined: Dec 14, 2004
Posts: 57
Tim Holloway wrote:Actually, your definition of "one war" and mine don't seem to be the same. I, too, build only one war, but it's the same war for development, test, and production. Bit-for-bit, byte-for-byte. Build one WAR file and deploy it to whichever server. There's no per-server properties files inside the WAR. And no danger of accidentally deploying a test WAR on the production server, since the test WAR is the production WAR. The attributes that make a WAR a "test" war are all injected from external sources.

I think you actually already know about Maven profiles, but you're mistaken about one thing. You most definitely can specify more than one profile on a build, and that can be useful when you have to do things like say, build a WebSphere WAR for iSeries when you also provide a WebLogic WAR for Linux. Mix and match OS's and server environments using combinations of profiles.

Incidentally, I find this annoying, but profiles do not override mainstream resources. If you want a custom web.xml, for example, you can't provide a default web.xml in the src/main/webapp or it will take precedence over a profile-specific src/tomcat/webapp version of the same file.


Hi Tim
Thanks for your reply.
Sorry if my original post wasn't clear. We actually do have the same deployment scenario - we only compile 1 single binary war, and all environment-specific configuration is kept outside, and referenced or injected at runtime.

I will research the use of multiple profiles more, but it seems contradictory at first. I could see how you can override/cascade properties from multiple profiles into one set of valid properties, but how would the build know to create a different asset for each, rather than just one that has a combination of the overridden properties?

I have also begun to explore using "executions" to bind the resource:resource goal multiple times to the process-resources phase.


This is almost working except for 2 things:
1. the build still executes the default "default-resources" execution, which copies all of the resources to target/classes. (minor, i'm sure there is a way to turn this off)
2. None of the properties in dev.properties are being resolved in the resulting resource after it's copied. Seems like this may be a bug in maven: http://jira.codehaus.org/browse/MRESOURCES-77
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16068
    
  21

I imagine that you could get into trouble if you had conflicting profiles, but in my case, the websphere-specific stuff is in one profile definition, the iSeries-OS stuff is in another profile definition, and there's no overlap of resources for potential conflict. I expect that in cases of conflict, the documentation probably has something to say, but since I've avoided such situations, I don't know.

Maven isn't designed to do something like produce a WAR+config files. It only produces a single primary artifact per build. So if you have auxiliary files, things get a little complicated.

In my case these days I'm mostly deploying on Red Hat Linux servers, so I have an advantage in that Maven can also produce RPMs (OS-installable packages). That means that a single maven command compiles the classes, builds the WAR, then wraps it all up with the necessary install scripts and data files so that a single OS command can setup both the server environment and deploy the app at the same time.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Maven resources/filtering/profiles - build ALL profiles?