That seems much closer to our situation, but I'm still confused - if project-A and project-B live in two different branches (and are clearly different projects), where do you store this configuration? We're leaning toward a separate configuration only project. So when project-A branches for some change request, we'd branch the configuration project as well.
This particular solution gets hung up when developers need a large percentage of the same "base" configuration as used in the deployment environments. For deployment, we're using ant - ant likes property files (or xml properties), maven requires profiles. We looked into filters, but you can't override the filters with values in settings.xml (not sure if this has changed between 2.0.5 and 2.0.9 or 2.1). If you could override property values in the filter files (property files) via settings.xml, we could easily share configuration. One of my co-workers wrote a plugin that allows the user to decide what properties to use and allows the overriding of filter file values. I've been hesitant to embrace this as it looks more like an exploit rather than a fix. Has there been any discussion about performing this kind of override or changing maven such that settings.xml takes precedence over all other profile values? -----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" <users@maven.apache.org> > 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: 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] > > > --------------------------------------------------------------------- > 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]
