On 14 December 2010 08:50, fhomasp <[email protected]> wrote: > > > > I didn't mean huge changes for the different platform. The usual changes > for the specific environments switched with profiles are usually those > property files you're talking about. > So the codebase remains the same, but assuming I build my ear using property > files for the validation platform, then the property files for the jar > dependencies in that ear would be automatically customized for the > validation platform as well. This means that some language properties > change, also the validation software needs to connect to another server, > also on the validation platform, so that url and its properties need to be > specific as well. And then also the property files for JUnit and for the > different databases. This way there is almost no human error possible, the > artifact is the same for all platforms, but with different config settings, > etc. > > Or am I missing something?
OK, I used to do consulting for the pharma sector. The FDA would hang you for a short-cut if they heard you were rebuilding the artifact and not doing a full regression test on the modified artifact ;-) [OK, so there are ways and means you could make it work and not be hung by the FDA, but that's a lot of process you'd be putting in place and a lot of extra validation and a lot of extra consultant hours to spend... (why did I leave the pharma sector... oh yeah I hate the paperwork!)] You are REBUILDING your artifact for each use case... that is not the "Maven Way"... Just to be clear, if you want to rebuild the artifact for each environment, then profiles is the solution I would choose... but I would NEVER want to rebuild the artifact for each environment... The "Maven Way" is to find a way of building, packaging and deploying your application such that you _never_ need to rebuild your artifact to run it in a different environment... that way you can build the artifact, test it in your test environment, qualify it for release in your qualification environment, and deploy it in your customer environment, and the whole time the SHA1 and MD5 of your artifact is the exact same, each step of the process. If you rebuild at any point, then a strict quality process would mandate one of two things: 1. Restart testing back at the start or 2. Do a diff of the two artifacts, identify all changes, make a risk assessment of the impact of each change, and then on the basis of the assessed risk do strategic testing in the environment you are deploying to... and also put in place a process of review for the risk assessments to ensure that they are being performed correctly and that the additional testing is not missing issues that would have been caught by just Restarting testing back at the start Now if quality is not your "thing" I can see why you might think that "REBUILDING for each environment" might be "ok"... but I happen to have been 'tainted' by working in heavily regulated industries and trained in GMP, GLP, cGCP... in short I have had quality drilled into me, at what some suspect is a cellular level, and every fiber of my being screams... never ever rebuild an artifact just so you can deploy it in a different environment... rebuild to fix bugs... rebuild to add features.... rebuild because the artifact will/should be better [/rant] -Stephen > > > > stephenconnolly wrote: >> >> On 14 December 2010 08:06, fhomasp <[email protected]> wrote: >>> >>> After reading a bit of the debate I wonder a few things. I read "stay >>> away >>> from profiles" a lot but I do find them to be very useful. >>> >>> So what's the alternative on profiles? Assuming there is a modular >>> project >>> with several jars, several wars and several ears. Each of those >>> artifacts >>> can be built for a different environment (development, test (1,2,3), >>> staging, validation,...) >> >> >> Here is your issue. >> >> The Maven Way is to build one artifact that works in any environment. >> You don't go building environment specific artifacts on the Maven Way. >> >> You use things like JNDI or properties files added to the classpath to >> provide the environment customisations.... >> >> In situations like branding, you produce a brand artifact for each of >> the customer specific brands and you would load that into your >> application, by e.g. loading from the classpath, or by installing into >> the deployed application. >> >> If you have an existing application that is not designed this way, >> then I can see that you might find it hard to avoid profiles.... but >> you will have a better application if it is designed for the kind of >> pluggable customizations I describe. >> >> The Maven Way is about best practices.... and one of the best >> practices there is is ensuring that you only build an artifact once >> and re-use that tested artifact... it reduces the scope of testing >> (i.e. you only have to test the JNDI names exist, or you only have to >> test that the branding is correctly applied, rather than have to >> retest the entire application because you have rebuilt it with the >> alternate profile. >> >> -Stephen >> >>> >>> Then an ear/war can be deployed using Maven to those different >>> environments, >>> be it from a local machine or Hudson or some other contineous integration >>> tool. >>> >>> How would one automate such situations without profiles and without a >>> huge >>> amount of redundant maven xml? >>> >>> >>> -- >>> View this message in context: >>> http://maven.40175.n5.nabble.com/Reasonable-use-of-profiles-tp3300650p3304188.html >>> Sent from the Maven - Users mailing list archive at Nabble.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] >> >> >> > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Reasonable-use-of-profiles-tp3300650p3304241.html > Sent from the Maven - Users mailing list archive at Nabble.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]
