Before Maven, we used Ant. The build output was a tar.gz that was staged to the install host. A deploy consisted of an unpacking of the .tar.gz and Ant was run given a properties file and an installation directory.
With Maven, our current process is to filter for the target environment at build time, producing an application inside .tar.gz that can be unpacked and started, but that requires one build per environment. ________________________________ From: Anders Hammar <[email protected]> To: Maven Users List <[email protected]> Sent: Mon, November 23, 2009 4:06:11 PM Subject: Re: Thoughts on build vs deploy time property filtering Well, I would argue that you should keep all environment specific configuration outside of your "artifact". How can you do filtering on deploy? Do you explode your jar/war/ear, filter, and then repack? /Anders On Mon, Nov 23, 2009 at 16:59, John Prystash <[email protected]> wrote: > Hi, I was hoping for some thoughts from the community about the reasons > behind why one might want to filter at build time versus at deploy time. > > Traditionally, our organization built one artifact from version control > that still contained property placeholders. We would filter those artifacts > at deploy time, so that the artifact was completed as it deployed to the > target environment. This was seen as beneficial as we only had to build our > artifact once, and then we can deploy that same artifact multiple times. > > It appears as though maven prefers to filter at build time, and create a > different artifact per environment. What are the benefits of this > methodology? It looks like you would have to do multiple builds (to produce > an environment-specific artifact), where before, we could only build a > filterable artifact once. > > Thanks > > > >
