Hi I implemented using the following:
In the parent pom: <properties> <envType>local</envType> <!-- Default Environment value --> <envProps>../autotestProperties/</envProps> </properties> <build> <resources> <resource> <directory>${envProps}/resources</directory> <filtering>true</filtering> </resource> </resources> <filters> <filter>${envProps}/env/${envType}.properties</filter> </filters> As far as maven goes, it works fine, but when I generate eclipse project, it tries to add the resource entry, but all it gets is a incorrect build path entry: "Build path entry is missing: home/emerson/workspace/trunk/autotests/autotestProperties/resources" Is there anyway to stop eclipse from trying to create this entry? The normal use of this will be for the developers and qa to create the project structure using a maven eclipse:eclipse install -DskipTests build once via maven On 6 October 2010 11:31, emerson <echofloripa.y...@gmail.com> wrote: > Hi Wayne > > For app deployment we use anthill in such a way that we use the same build > for all environments and the resources are processed during the deployment. > > that said, this is a special case, as this project and its modules are all > jbehave and selenium projects, which won't generate artifacts and will just > run the tests. > > But I agree with you in that this is somewhat of a anti-pattern when used > to deploy final artifacts. > > Regards > Emerson > > > On 5 October 2010 18:27, Wayne Fay <wayne...@gmail.com> wrote: > >> > For property values -- I setup a .properties file for each of our >> > environments with the default being 'dev'. So for a default build, the >> dev >> > properties are used. but when its time to build for QA or Production, >> you >> > add a cmd line argument accordingly: mvn install -DenvType=QA >> >> IMO this is an anti-pattern for Maven usage. You should be able to >> build one single artifact in say Dev and then promote that same >> untouched/changed artifact through your various environments. >> Otherwise the artifact that gets QA'ed is not the same artifact that >> lands in Production... which defeats the purpose of QA. >> >> You should generally deal with these variances in the environments via >> JNDI or other mechanisms available in the platform (JavaSE/JEE or >> whatever container you're deploying into). >> >> Wayne >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> >