One other issue with rebuilding the artifacts is that you're going to have problem if you want to do it the Maven way by deploying to a repo. As there can only be one flavor of a specific version of an artifact, you can't rebuild without bumping version. (Yes, you should never ever replace/remove/alter a released artifact.)
/Anders On Tue, Dec 14, 2010 at 10:11, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On 14 December 2010 08:50, fhomasp <thomas.peet...@realdolmen.com> 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 <thomas.peet...@realdolmen.com> > 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: users-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: users-h...@maven.apache.org > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > >> > > > > -- > > 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: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
