Either I'm not explaining things well enough or you are assuming something different and I think that is the confusion ... I am not building or using the application projects or source code. I'm not dealing with application deployment, they are already deployed via other means and processes that I am not directly plugged into.
My maven project is currently a set of Selenium-based, TestNG-driven, stand-alone integration tests for 3 different applications, one that is MediaWiki-based, one built on vBulletin and one that is a custom J2EE-based web service. These tests run on client machines. Profiles are curently working great for me...I merely hoped to find a way to simplify them a bit. I believe I am using maven exactly as stated in the maven profile intro at http://maven.apache.org/guides/introduction/introduction-to-profiles.html where it states: "Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. *They modify the POM at build time*, and are meant to be used in *complementary sets* to give *equivalent-but-different parameters for a set of target environments* (providing, for example, the *path of the appserver root* in the development, testing, and production environments)." this is exactly what I'm trying to do for my project, target different appserver roots for the different dev, test and prod environments for the 3 different applications I test, independently of the application build process. The test environment information is all *stored in property files* outside of the source code. The tests are generic in that regard. The maven profiles simply help determine which properties file the test uses/loads via a call to getResourceAsStream(profileID+".properties"). I don't see how this is anti-Maven. So for what I am doing, JNDI seems like overkill to set the application root or affect run-time debugging levels. Even if I do use JNDI, how does JNDI solve the problem of determining which environment/settings are used at run-time? Seems like I'd still need profiles or something to tell my tests at run-time which environment to use, regardless of whether they are stored in property files or in some database somewhere. As mentioned, the profiles are working great for me. I just hoped I could simplify the profile a bit to eliminate the duplicate, hard-coded config value in each profile by doing something like *<config>${profile.id }</config>* instead of *<config>staging</config> *or *<config>dev</config>.* As an alternative to setting a system property via the surefire plugin, I also wondered if there is any other way to communicate to my tests which profile(s) is(are) loaded? On Thu, Jan 20, 2011 at 4:27 PM, Ron Wheeler <rwhee...@artifact-software.com > wrote: > designed -- Jeff Vincent predato...@gmail.com See my LinkedIn profile at: http://www.linkedin.com/in/rjeffreyvincent
