You either need to separate the configuration from the binaries, or have different artifacts.
Your current solution does not work if you do deploys to a repo and adhere to the very important Maven rule that a release may NEVER be altered. /Anders On Wed, Oct 27, 2010 at 18:52, Jon Paynter <[email protected]> wrote: > On Wed, Oct 27, 2010 at 5:51 AM, Jörg Schaible <[email protected] > >wrote: > > > Anders Hammar wrote: > > > > > You need Maven 3.0 to be able to activate profiles in the pom by > > > properties set in a profile in settings.xml. > > > > The point is that this functionality is superfluous. If you want a > profile > > be activated based on properties in settings.xml, you may as well simply > > add > > it there to your activeProfiles section. Works also for M2. > > im using maven 3.0. I ended up defining a property inside an already > alwaysActive profile in the settings.xml. Rather a kludge - but it works. > > > On Wed, Oct 27, 2010 at 5:44 AM, Ron Wheeler < > [email protected] > > wrote: > > > On 27/10/2010 1:51 AM, Anders Hammar wrote: > > > >> While on the topic, I'd like to mention that having a different build > >> (through profiles for example) for each environment is not good. In > Maven, > >> there can only be one flavor of a released artifact. So if you build > v1.0 > >> of > >> your war, cannot rebuild it with a different content. > >> > >> What you should do is build different artifacts for each environment. > Use > >> classifiers or, in my opinion even better, different Maven projects. > This > >> have been discussed several times on this list about a month ago or so. > >> > >> And should be in the "Best Practices" section of the documentation so > > that people know that this is settled law. > > > I need something that supports parallel releases. We have 3 QA > environments, 1 or more of which can have a release that is being tested to > go into production. So for example: QA1 would have v3.0 currently under > test with a scheduled release date in september, and then QA2 would have > v3.1 under test with a scheduled release date in November. Currently each > environment has a properties fie containing environment specific values and > the build. So based on the target environment for a given build, the > appropiate properties file is used for filtering. While this doesnt seem > to > fit well with the maven way - it works for us. > > What would you suggest as an alternative? >
