I have configuration inheritance mechanism allowing to specify the
setting as environment one and use it across different applications
using variable pointing to the specified before setting, so when you
need to change database url you need to change only in one place and
during customization phase the variable will be parsed with the value
from environment setting.
Best regards,
Juri.
-----Original Message-----
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2008 4:25 PM
To: Maven Users List
Subject: RE: Building for different environments - how do _you_ do it?
Right, we're doing the same exact thing. Initially, we'd build a zip
containing the vanilla ear/war combo, then generate a zip containing all
the processed resources PER machine (as the appserver config has to be
different here per app server).
So that was very time consuming, so what I did was write a m2 plugin
that looks at a set of profiles and generated an xml properties file
(<variable>value</variable>) and that was used to parse a set of
templates.
This too takes quite a while. CC starts maven, runs some command,
copies over the resulting xml file, stops the process - all can take 5 -
7 min per machine. Factor 70 or 80 machines and you get the picture.
The final result was to pre-generate the property files. The part of
this equation that I'm struggling with (as it seems everyone is doing
some variation of the above bits) is when standalone module A and
standalone module B need to both connect to the same database. We have
maybe a dozen modules like this and it's nightmarish to think of
updating 12 different locations with the same DB connection string. How
do you share a variable like this without resorting to making the build
server's settings.xml file widely available?
-----Original Message-----
From: Artamonov, Juri [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2008 8:54 AM
To: Maven Users List
Subject: RE: Building for different environments - how do _you_ do it?
Here in the company I'm working for I created the model allowing to us
to be flexible across environments settings.
If in short then:
1. We produce every time only single general artifact and not
environment specific, let's say war file.
2. Then we need to deploy it on different environments and for this I
created environment configuration file which is descriptor of the
environment.
3. Environment descriptor contains information about general settings
which belong to this environment, about servers and their settings that
are on this environment and about applications and their settings that
are on these servers.
4. In the same time every produced artifact contains its own descriptor
and contains for example default values for settings if any.
5. Another item in this model is the tool I named installer which takes
produced artifact and environment descriptor as a input and produce
customization where as a result you have artifacts specific for the
server on certain environment. If it's required it also can be deployed
using the same application.
So, we have general artifact as build result with its own component
descriptor, self-explained environment descriptor for each environment
and application which perform actions with the artifacts on specified
environment using provided environment descriptor.
Best regards,
Juri.
-----Original Message-----
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2008 9:15 PM
To: users@maven.apache.org
Subject: Building for different environments - how do _you_ do it?
So how are other people building for both dev and other environments?
For example, how does one support multiple environments like the
following:
1 - Dev integration
2 - QA stack 1
3 - QA stack 2
4 - QA stack 3
5 - Staging
6 - Prod
7 - local developer builds
How do other people support variables that can be the same from local
builds through production but support the option to change them at the
last minute? Are people building multiple version of say an ear
deployment to support all the different environments?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
