Also, much of this is viewed as, "I have an appserver that I need many 
configurations for", my issue is not just that, but also "I have a <other> 
server that needs the same (or similar) configuration as that appserver in a 
different branch, how do I share this info".

I can't use profiles.xml as then I'd need a profiles.xml file in both the 
appserver and in the <other> server's root directory.

It's not the actual configuration files that are in common either, we could use 
the maven-dependency-plugin to pull down and unpack some common config if that 
was the case.

Which brings me back to a configuration only project.  That could be simply a 
jar (<packaging>jar</packaging>) project that just bundles up the pre-generated 
property files.  But then we get into the realm of having to version all the 
config projects as well.

/shrug

-----Original Message-----
From: Mark Struberg [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 04, 2008 11:09 AM
To: Maven Users List
Subject: RE: Building for different environments - how do _you_ do it?

My colleague Sigi Goeschl wrote a comment on how we solved a very similar 
problem back in early 2007:

http://www.nabble.com/Re:-What-is-the-Best-practice-for-generating-variations-of-an-artifacts--p9519069s177.html


LieGrü,
strub


--- EJ Ciramella <[EMAIL PROTECTED]> schrieb am Mi, 4.6.2008:

> Von: EJ Ciramella <[EMAIL PROTECTED]>
> Betreff: RE: Building for different environments - how do _you_ do it?
> An: "Maven Users List" <[email protected]>
> Datum: Mittwoch, 4. Juni 2008, 15:44
> How do you do the inheritance though, that's the part
> I'm missing.
> 
> -----Original Message-----
> From: Artamonov, Juri [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 04, 2008 9:42 AM
> To: Maven Users List
> Subject: RE: Building for different environments - how do
> _you_ do it?
> 
> 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: [email protected]
> 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]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]


      __________________________________________________________
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com

---------------------------------------------------------------------
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]

Reply via email to