>>> Basically a profile should only be used to either >>> a) externalise OS dependent settings, e.g. location of eclipse installation. >>> In general for all most all maven plugins you never need to do this
Why else would you use a profile? So we have three per environment we activate: 1 - base (has all the generic stuff used across all environments 2 - StackDefaults (this is all the default stuff per qa/staging/production environments - everything that's different between these and a developer's machine) 3 - color (all of our stacks are color coded - things like db strings go in here) So when we build, we activate via -Pbase,StackDefaults,<color> Depending on what the "color" profile is, via help:active-profiles, we can see sometimes <color> comes before StackDefaults - which basically nullifies itsself. >>> You are using -Ppersonal,StackDefaults,ca-lime,root which just feels wrong. Why? How else do you say, "take everything from this semi-generic profile, PLUS what is defined as a stack default AND override all that with this VERY specific stuff in this ca-lime profile (just ignore "root" for the time being as it needs to specify the directory the build is happening in) >>> Why are you having to select these values? Because for our stack defaults, we have a large set of c-name settings. Instead of having each color profile that had 9134806709328476 entries, we plopped them all in StackDefaults. This way when it comes time to add on a new stack, people don't look at it and say, "ZOMG - LOOK AT ALL THOSE ENTRIES!!! I'll never figure this out". Then get releng involved. Then get dev involved. Then get ops involved. The way it works now is you add a color profile and talk to the dbas for what the password should be for that env. >>> Why are they not the defined defaults? We have two degrees of defined defaults. This is where I think we break from the mvn norm. We have a VERY complex environemtal set up in staging and production. We have 4 web servers, 5 jboss app servers, 2 atg util servers, the list goes on and on - in total 25 with MANY various purposes. Where when we try to stick to convention over configuration, it forced us down this path. >>> There was a discussion a while ago about multiple build for different >>> configurations, e.g. Tomcat/War, JBoss/Ear, etc. I can't recall the >>> result of the discussion. >>> But if you always want to build each of these configurations then you >>> may want to consider creating a module per configuration that has all >>> the correct settings defined for that build. Heh - what we're doing is building a "main" bin type distirubtable that is mis-configured (because we're only activating the personal profile with next to no other profile). That alone is about 220 mb. If we had to generate that for each stack, that'd be 15 of those puppies. Plus, we still have to build up the atg ca app, util app, email server - the list goes on. Add to this that we currently have 7 active branches. You start to see how big a disk that would require. This is why we build ONE main binary then a configuration for each environment. The config files are tiny, maybe 10 kb. I think your suggestions are valid, but only for a very plain-jane build env and environment (which ours is not). How about mvn fixing this buggy profile override code? I can see it's targeted for 2.1 (now)... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
