As a long time Maven (since 0.7) user, one of the most challenging things I've faced thus far in 2.0 is profiles. It appears there are a lot of anomalies when a profile is activated. Though it should work just as if you've defined/set something in the normal sections of the pom, I find that things like inheritance stop working in some cases, or in the oddest of them all, <uniqueVersion> gets ignored for snapshots, and all the JARs get unique timestamps generated. I've logged defects and some how-to-reproduces for these profile based anomalies, but haven't seen fixes or many replies as of yet. When I get a little break from work, I might have to try and dig in to debug them myself. Hopefully, this anecdote just helps you hear that there are indeed some oddities around profiles and profile activation.
ravasthi wrote: > > I'm having an odd problem to do with overriding resources and build > profiles. I'm hoping someone can give me some insight as to why Maven is > behaving as it does. First, let me give you some background. I recently > migrated my Ant project to a Maven project, and I'm running Maven 2.0.7. > I'm relatively new to Maven, so please bear with me. > > This particular project has a large set of properties files that define > its settings, and needs to run in several environments—for example a > staging server that we push releases to, and a QA server that we push > nightly builds to, as well as the usual development and production > environments—and so I need to keep a different set of settings files for > each environment it needs to run in. In addition, in order for the > developers on our team to be able to get up and running quickly, I've got > a set of default settings that I need to have the developers be able to > override with settings for their own machines. > > [snipped] > > - If a build profile has been selected, properties files of the same > name should override those in both of the two locations above. > > [snipped] > > And then in my build profiles section, I had, for example: > > <profile> > <id>stage</id> > <activation> > <property> > <name>env</name> > <value>stage</value> > </property> > </activation> > <build> > <resources> > <resource> > > <directory>src/main/resources/settings/defaults</directory> > <filtering>true</filtering> > <includes> > <include>*.properties</include> > <include>*.xml</include> > </includes> > </resource> > <resource> > > <directory>src/main/resources/settings/stage</directory> > <filtering>true</filtering> > <includes> > <include>*.properties</include> > <include>*.xml</include> > </includes> > </resource> > </resources> > </build> > </profile> > > [snipped] > > I was able to get the overriding working again by reversing the order I > was listing directories: the directories whose contents I wanted to take > precedence had to be listed first, not last. However, I couldn't get build > profiles to work at all. > > Finally what I did to get build profiles working with filtering off was to > create a new build profile that was active by default, and moved my > resource declarations from the <build>...</build> section into there, > leaving no resource declarations in the <build>...</build> section. Once I > did that, I could select a build profile and my target/classes directory > would contain the correct versions of the properties files. > > -- View this message in context: http://www.nabble.com/Build-profiles-and-overriding-resources-tf4768154s177.html#a13648367 Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
