This sounds very simmilar to the setup we have here -- everything was
already in property files. I found the key to simplifying things is to have
and enforce a standardized naming convention. Since that was already in
place when I looked into maven, picking the correct property file was
trivial:
<build>
<filters>
<filter>${PomRoot}/${envType}Config.properties</filter>
</filters>
......
</build>
then I have a few properties:
<properties>
<envType>dev</envType> <!-- Default Environment value -->
<PomRoot>C:\MavenProject\POC</PomRoot>
....
</properties>
the only part I dont like is having to add the <PomRoot> property, but thats
required if you ever build projects not at the top level -- otherwise it
cant find the properties file. (if anyone knows a better solution - please
speak up)
when you want to build for a different environment:
mvn install -DenvType=QA
mvn install -DenvType=StressTest
I find that very simple to use.
On Fri, Jan 21, 2011 at 11:39 AM, Ron Wheeler <
[email protected]> wrote:
> On 21/01/2011 1:19 PM, Jeff wrote:
>
>> 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.htmlwhere
>> 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?
>>
>> I can't answer that but you certainly have the right guys in the forum
> who can tell you for sure.
>
> Good luck
>
> Ron
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
