An area we've been successful with in using profiles is to distinguish between local builds and CI build to toggle Fat v Skinny WARs
________________________________ Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time, 600 times a day > -----Original Message----- > From: KARR, DAVID (ATTSI) [mailto:dk0...@att.com] > Sent: Friday, December 10, 2010 12:20 PM > To: Maven Users List > Subject: Reasonable use of profiles? > > I've heard talk about the debatable value of profiles, and I > wanted to describe one use I might have for profiles, > although I'm still in the initial stages of converting a > large Ant environment to Maven, so things may change. I'd > appreciate any comments. > > I think one basic reason that profiles become useful is that > we can't control every aspect of our environment. > > This "environment" as I describe it, consists of a large > enterprise web application, although there are actually 2-3 > different EARS that are built for different but related > purposes. The applications are composed of a bunch of > modules that are divided on functional and team boundaries > (front-end Java, back-end Java, web modules, middleware, et cetera). > > When developers build the present system, they have to check > out all of the modules that contribute to the EAR, and they > have to check them out with their default name, because the > build has hard-coded references to the directory names. > > The work for each release, about every month, is done on a > branch named for that release. If the work for a release > includes changes in a particular module, then that module is > branched so that developers can do the work required for it. > Developers often have to do some work on more than one > branch, in the same module. > > So, in order to do a complete Ant build, you have to have all > the required module names checked out with their default > names. Some modules can do unit and even "integration" unit > testing without building the EAR (back-end and middleware > modules), so that doesn't require checking out the module > with the default name. > > A typical strategy is to create separate Eclipse workspaces, > each of which has all the required modules checked out, but > for different branches. Personally, I find it a pain to > switch workspaces in Eclipse, because I have a lot of > modules, and startup takes quite a while. As a result, I > often end up checking out many modules with a name like > "<default>-<branchname>", especially if I don't have to build > the EAR with that module, but just be able to inspect the > code, or get unit/integration tests working. > > So, in converting this to Maven, I envision an almost 1-1 > correspondence between the Ant projects and Maven projects, > except the "build" project will just run the build > (previously, we had sort of a "chain" system, where module > builds chained to the next required module), and "ear" > projects will specify just the needed dependencies and the > assembly phase, not to mention a parent POM or two. > > I want to allow for the possibility of not requiring modules > to be checked out with their "default" names, so I want to > have module references that reference property values, > instead of hardcoded names. > It seems to me that if I define a profile in my settings.xml > that corresponds to a branch, I can define the property > values for each module name, and then I can either specify > the profile on the command line, or if I'm working for a few > hours on one branch, I can just change the default profile. > I think this can work. > > Another desire I have is to allow for developers not even > building most of the modules, and just letting the "ear" > project pull snapshot artifacts from the Nexus repo (built by > the release team or continuous integration). I could do this > with multiple "build" projects, including different sets of > "module" elements. That seems messy, however. I wish I had > different options for setting that up, perhaps in a profile, > but I don't see how that could work. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
