I think my comment is misinterpreted, think about this if you had an ear file then an admin interface as a separate deployable unit - both would need to connect to the database, both live as separate projects (as you don't necessarily have to build both per release).
Where is that configuration stored? In its own separate project? We have 17 individual deployment stacks (where a "stack" is comprised of web/app/utils/tools/db and many more servers) where there can be as many as 6 of any given type (requiring some different config in some cases). Which one of those is a "backend" project? Or are we talking in parallel where you're saying "backend" project, I'm saying "configuration ONLY" project? At any given time, we may have a branch for only the "app" layer (and no corresponding branch for any of the other modules as they are unchanged). It'd be rough to branch say, the db layer, just to change the configuration string the app layer is using to connect with. Or are you suggesting making the change to the "mainline" db project? Once things go to main, that branch is recycled for patch/support work (unless it is deemed risky enough to need a branch). -----Original Message----- From: Mark Struberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2008 12:25 PM To: Maven Users List Subject: RE: Building for different environments - how do _you_ do it? > Also, much of this is viewed as, "I have an appserver > that I need many configurations for", Nope, it's more like: we have _many_ app servers (local development boxes, internal dev testing boxes, staging boxes, demo boxes, production boxes) and each of them needs special settings (like e.g. different database settings, network settings, load balancing data, and also different business configuration like affiliates, contracts, suppliers, etc) The trick is to keep the "baseline" configuration in the backend project and use the maven-assembly-plugin to provide it as attached artifact. This baseline config will be tagged, branched etc as it always fits to the backend services of this version. In the frontend projects, this baseline config will be overlayed with n installation configuration settings. And they will also be treated as attached artifacts. So you end up with 1 WAR + n configuration zips (1 for each type of box) If some frontend project uses another backend version (even different maintainance branch) it will get the right config automatically. 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, 17:45 > 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] __________________________________________________________ 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]
