On Sun, 2005-04-17 at 20:37 -0700, Michal Maczka wrote: > Are you just describing generic situation or just simple dev/qa/prod > situation where environments are almost identical?
I'm talking about the movement of an application through internal staging areas. I'm not talking about production deployments to end users. A different problem: more a matter of end-user configuration and production deployment. > I have a real life use case when we deploy the same application to > approximately 30 banks. > There is only one application and approximately 50-60 environments. > Differences between those environments are huge: > - different operating system, different databases, different jvm, > different application servers (ours or j2ee) . > We don't actually use clustering but I imagine that people who deploy > the same application to multiple cluster nodes in the same location can > easily have couple dozen of environments more, which they need to > support. This really requires a scalable solution. > If you will put all that to one archive not only it would be couple of > megabytes larger but you risk to ship to clients the knowledge which > should be protected (e.g. digital certificates, harcoded passwords (yes > it happens :( )). For the production archive I would not put every clients configuration into the archive. That's obviously ridiculous. My particular case is an application developed for use within the organization. For a production deployment to clients you would most certainly have a configuration mechanism. > In a case when you are using j2ee and build-in security mechanism > (declarative security in deployment descriptors) > you really need to replace fragments of web.xml, ejb-jar.xml > application.xml files. If you deploy j2ee applications > (war, ear) to different application server you will also need to add > application server specific descriptor. > > I don't really see how you could activate some settings, which are > stored in the some archive in such case. I actually take the archive, unpack it filter copy templates of those files against the deployment properties and package it back up. I have EAR files and WAR files that are in my single archive and this works. Now I have typically veered away from J2EE development so I'm not sure if there are better ways to do this but I open up the EAR files and swizzle them. So you could easily do this as part of a client install process. > I find it more scalable to have app-node1, app-node2, app-node-N > artifacts in repository and to have some qa practices in place > which are assuring that right archive (more often archive of archives) > is shipped to the right customer. Sure, you may want to have a profile for a client and that is essentially what I have. Using the repository might be a good idea for that. Then you can create a profile for a client and they can take your prototype deployment and run it against their profile. Right now I only have 4 environments to deal with so I package it inside the archive. If I made that work with a repository then I could easily point to somewhere in the archive or a remote repository. At any rate a single prototype of your deployment can work even if you have to mutate the contents of EAR files and WAR files. I do exactly what you describe above where I use form-based security in the dev environment and cert- based security in the other environments. Bottom line is a profile for an environment for an internal staging environment or a client is the same thing and it can be done. > I haven't really had problem which you described nad never an archive > was sent to the wrong place (and as you can see number of that places is > quite big). Archive names which are clearly describing the environment > name where this archive should be used are really helpful. So the > conventions like myapp-clientX-nodeY-1.0.war are really priceless. Believe me, it can happen even with clearly named archives. > And don't get me wrong: you approach looks really interesting in certain > circumstances. I just want to point that there are sometimes far more > complex but not so unusual situations which would be nice to have > covered in m2. I can't see in any place where a single archive + deployment profile can't work. If a repository is used to house the profile then I think you're all set. I'll probably take a shot at this. > michal > > > > ---------------------------------------------------------------------- > Wszystko o MOTORYZACJI >>> http://link.interia.pl/f186a > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
