Re: Help referencing profile properties/attributes...
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:
${PomRoot}/${envType}Config.properties
..
then I have a few properties:
dev
C:\MavenProject\POC
the only part I dont like is having to add the 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 <
rwhee...@artifact-software.com> 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 *${profile.id
>> }* instead of *staging *or
>> *dev.*
>>
>> 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: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: Help referencing profile properties/attributes...
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.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 *${profile.id
}* instead of *staging *or *dev.*
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Help referencing profile properties/attributes...
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 *${profile.id
}* instead of *staging *or *dev.*
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 wrote:
> designed
--
Jeff Vincent
predato...@gmail.com
See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent
Re: Help referencing profile properties/attributes...
Still not sure why you need deployment or test configurations in your applications You are not the first person to build an N-tiered web application with many servers. Why can you not put debugging levels and BaseURLs in JNDI? Those seem pretty simple things to deal with. You are not the first person to try to use/misuse profiles for this. I am not trying to be mean or disrespectful of your intentions, I am just trying point out some reasons why there is no answer to what you want to do. It is not a good way to do things and Maven is not designed to solve this problem. You are looking at Maven for the right reasons but Maven is not Ant. Maven is designed to make it easy to do the right thing and it make make it hard or impossible to do other things. I didn't write Maven but I had to deal with the same thing. We didn't get started out right either and had to change. I have also read dozens of long conversations here with people more determined than you to try to find a way to make Maven do what you want. You also have had advice from others here who are the best Maven experts in the world (committers to the project ) and you might have observed that they have not given you a solution. It is not because they are trying to annoy you or tease you. Ron On 20/01/2011 5:18 PM, Jeff wrote: I don't want to debate our architecture or processes since I have little to do with defining them, but its an N-tiered web application comprising from one to dozens of servers. Many of the tests are Selenium Integration tests on Windows clients hitting remote servers that are mostly Linux. We have dev and test instances that we hit during development. One of the key properties that changes is the baseURL used by selenium, as well as debugging levels. The integration test code is not currently part of the source for the application. The tests never run on the app servers directly (I've never seen anyone do that anyway...our build servers don't run the web app.), particularly the integration tests as they are client-based. We are running the tests from dev workstations for now but will eventually expand to running a subset of integration tests via Hudson. We are leveraging as much of Maven through the entire process as possible in order to maximize reuse, portability and integration moving forward. Anything else I can clarify? On Jan 20, 2011 2:24 PM, "Ron Wheeler" wrote: - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Help referencing profile properties/attributes...
I don't want to debate our architecture or processes since I have little to do with defining them, but its an N-tiered web application comprising from one to dozens of servers. Many of the tests are Selenium Integration tests on Windows clients hitting remote servers that are mostly Linux. We have dev and test instances that we hit during development. One of the key properties that changes is the baseURL used by selenium, as well as debugging levels. The integration test code is not currently part of the source for the application. The tests never run on the app servers directly (I've never seen anyone do that anyway...our build servers don't run the web app.), particularly the integration tests as they are client-based. We are running the tests from dev workstations for now but will eventually expand to running a subset of integration tests via Hudson. We are leveraging as much of Maven through the entire process as possible in order to maximize reuse, portability and integration moving forward. Anything else I can clarify? On Jan 20, 2011 2:24 PM, "Ron Wheeler" wrote:
Re: Help referencing profile properties/attributes...
Is there any reason why deployment and server specific configurations are mixed in with your code? This is not a good thing and usually not needed. When you configure a server, you should be able to include this information in the server configuration not in the application code. 1) The application should run on whatever server it finds itself loaded on. If it needs to know something about the server, it should ask the server. This includes stuff like webservice endpoints if they change between test and production - and the had better or someday you may find a test calling production services and really making a big mess. If you leave this kind of stuff in the hands of a developer, you are bound to have something bad happen eventually. 2) When you build a release of something you should not be rebuilding it after you have tested it unless you are going to test it again. There is no way to do this with the structure that you are proposing. 3) You are making your builds too complicated and error prone. See JNDI. http://download.oracle.com/javase/jndi/tutorial/TOC.html From my blog http://blog.artifact-software.com/tech/?p=58 BTW. You are not the only one who has to run software on development machines, test machines and often hundreds or thousands of production machines. You do not need to go down this route and the usual destination is not a good one. Fix it as soon as you can and your whole development to production cycle will get much easier. Ron On 20/01/2011 1:09 PM, Jeff wrote: Thanks all for the comments. If there is a better way to do what I need, then I welcome help to understand how to do it right. We have configurations we need to load for the various development and testing environments (unit and integration). I've been working to put the specific configuation information for each environment (URL's, IP's, debug levels, etc.) into property files. Each property file will have a name like "test.properties" or "staging.properties". There is a 1 to 1 mapping between a maven profile and each properties file. (e.g., profile.id = "staging" loads "staging.properties") As I understand it, the *profile mechanism is the way to affect behavior at run-time*. So I'm setting a system property in the profile that will trigger a specific file to be loaded. If there is a better way for my code to know what profile was selected, I've not been able to find it. Since each profile is identical except for the id and the value of the system property being set and maven encourages universal reuse, I was hoping to just reference the profile id when setting the system property. Then when I copy the profile to add new ones all I would need to change is the profile id. Thoughts? On Thu, Jan 20, 2011 at 8:39 AM, Wayne Fay wrote: I'm new to Maven and am building a POM with profiles. I want to be able to Then you are most likely doing things "wrong." Is there no other way to build/test your app without using profiles? Currently the value of the "config" system property is equivalent to the value of the profile id. Is there a syntax in the POM for referencing the id of the profile that is in the parent chain of the property being set? Not that I'm aware of. The simplest fix is to just put the word "staging" in that plugin configuration, since your plugin is inside the profile anyway. The next simplest "fix" is to have another property, say profile-name, that you copy your profile id to and then reference that property where you need to use the name. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Help referencing profile properties/attributes...
Thanks all for the comments. If there is a better way to do what I need, then I welcome help to understand how to do it right. We have configurations we need to load for the various development and testing environments (unit and integration). I've been working to put the specific configuation information for each environment (URL's, IP's, debug levels, etc.) into property files. Each property file will have a name like "test.properties" or "staging.properties". There is a 1 to 1 mapping between a maven profile and each properties file. (e.g., profile.id = "staging" loads "staging.properties") As I understand it, the *profile mechanism is the way to affect behavior at run-time*. So I'm setting a system property in the profile that will trigger a specific file to be loaded. If there is a better way for my code to know what profile was selected, I've not been able to find it. Since each profile is identical except for the id and the value of the system property being set and maven encourages universal reuse, I was hoping to just reference the profile id when setting the system property. Then when I copy the profile to add new ones all I would need to change is the profile id. Thoughts? On Thu, Jan 20, 2011 at 8:39 AM, Wayne Fay wrote: > > I'm new to Maven and am building a POM with profiles. I want to be able > to > > Then you are most likely doing things "wrong." Is there no other way > to build/test your app without using profiles? > > > Currently the value of the "config" system property is equivalent to the > > value of the profile id. Is there a syntax in the POM for referencing > the > > id of the profile that is in the parent chain of the property being set? > > Not that I'm aware of. The simplest fix is to just put the word > "staging" in that plugin configuration, since your plugin is inside > the profile anyway. The next simplest "fix" is to have another > property, say profile-name, that you copy your profile id to and then > reference that property where you need to use the name. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Jeff Vincent predato...@gmail.com See my LinkedIn profile at: http://www.linkedin.com/in/rjeffreyvincent
Re: Help referencing profile properties/attributes...
> I'm new to Maven and am building a POM with profiles. I want to be able to Then you are most likely doing things "wrong." Is there no other way to build/test your app without using profiles? > Currently the value of the "config" system property is equivalent to the > value of the profile id. Is there a syntax in the POM for referencing the > id of the profile that is in the parent chain of the property being set? Not that I'm aware of. The simplest fix is to just put the word "staging" in that plugin configuration, since your plugin is inside the profile anyway. The next simplest "fix" is to have another property, say profile-name, that you copy your profile id to and then reference that property where you need to use the name. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Help referencing profile properties/attributes...
We have had long discussions about why profiles are not the right way to
deal with environment/deployment issues.
Ron
On 20/01/2011 3:05 AM, Anders Hammar wrote:
Not that I know of, no.
In your example, why don't you just specify the value ('staging') in the
confgiuration of the surefire plugin?
/Anders
On Thu, Jan 20, 2011 at 07:52, Jeff wrote:
I'm new to Maven and am building a POM with profiles. I want to be able to
set a system property that contains the value of the current profile(s).
Currently I have multiple profiles that each relate to different web app
servers (dev, test, staging, etc.) in our dev/test environment. I want the
profile (via the surefire plugin) to set a system property called "config"
that can be read during the "test" goal to change which web app server to
use (via property file).
Currently the value of the "config" system property is equivalent to the
value of the profile id. Is there a syntax in the POM for referencing the
id of the profile that is in the parent chain of the property being set?
For example, in the profile below, can I reference the profile id in order
to retrieve the value "staging"? I've tried ${profile.id}, ${id}, but
they
don't work.
*staging
*...
org.apache.maven.plugins
maven-surefire-plugin
2.7.1
false
*${profile.id}
*...
Thanks!!
--
Jeff Vincent
predato...@gmail.com
See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Help referencing profile properties/attributes...
Not that I know of, no.
In your example, why don't you just specify the value ('staging') in the
confgiuration of the surefire plugin?
/Anders
On Thu, Jan 20, 2011 at 07:52, Jeff wrote:
> I'm new to Maven and am building a POM with profiles. I want to be able to
> set a system property that contains the value of the current profile(s).
>
> Currently I have multiple profiles that each relate to different web app
> servers (dev, test, staging, etc.) in our dev/test environment. I want the
> profile (via the surefire plugin) to set a system property called "config"
> that can be read during the "test" goal to change which web app server to
> use (via property file).
>
> Currently the value of the "config" system property is equivalent to the
> value of the profile id. Is there a syntax in the POM for referencing the
> id of the profile that is in the parent chain of the property being set?
>
> For example, in the profile below, can I reference the profile id in order
> to retrieve the value "staging"? I've tried ${profile.id}, ${id}, but
> they
> don't work.
>
>
>
> *staging
> *...
>
>
>
>org.apache.maven.plugins
>maven-surefire-plugin
>2.7.1
>
> false
>
>*${profile.id}
> *...
>
>
>
>
> Thanks!!
>
> --
> Jeff Vincent
> predato...@gmail.com
> See my LinkedIn profile at:
> http://www.linkedin.com/in/rjeffreyvincent
>
Help referencing profile properties/attributes...
I'm new to Maven and am building a POM with profiles. I want to be able to
set a system property that contains the value of the current profile(s).
Currently I have multiple profiles that each relate to different web app
servers (dev, test, staging, etc.) in our dev/test environment. I want the
profile (via the surefire plugin) to set a system property called "config"
that can be read during the "test" goal to change which web app server to
use (via property file).
Currently the value of the "config" system property is equivalent to the
value of the profile id. Is there a syntax in the POM for referencing the
id of the profile that is in the parent chain of the property being set?
For example, in the profile below, can I reference the profile id in order
to retrieve the value "staging"? I've tried ${profile.id}, ${id}, but they
don't work.
*staging
*...
org.apache.maven.plugins
maven-surefire-plugin
2.7.1
false
*${profile.id}
*...
Thanks!!
--
Jeff Vincent
predato...@gmail.com
See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent
