It sounds to me like two types of documentation are needed. One is the/an ideal "Maven Way" of setting up a consultant's multi-client project, assuming you are starting fresh and know you will be using Maven. I personally think that Maven is ideal for exactly that kind of environment, but then I'm already among the converted. :-)
The second task is providing migration examples, such as those sought in the original query on this thread. This is substantially harder, because the starting points can vary rather dramatically. The question comes up often on this list, so perhaps the best thing to do is provide a centralized FAQ-type page in the documentation with examples and solutions drawn directly from the list. The simplest first approach might be just a list of links to the appropriate threads in the list archives. Add it to the "Migrating from Ant" section of the existing documentation, perhaps. Fleshing those out and cleaning them up would of course be great, but people are busy. Adding a link in the documentation each time a new variant of the migration question comes up would be relatively quick and might be sufficient. I notice "Strategy for migrating from Ant builds" is one of the items listed as needed documentation for M2. I did a quick search on "migrate ant" in the archives and turned up a reasonable starting set, most of which are for M1. I haven't moved to M2 yet myself, but if there are no strong objections, I'll take a shot at assembling and organizing the links for the gurus to look over and decide whether they are helpful as-is or in need of cleaning. The best thing would be for the people who asked for the help originally to write up and submit what it was they finally did that worked for them... assuming they did go with Maven in the end. This is probably too much to expect, but if we had a centralized set of links for the migration problem it would make it easier to send follow-up emails to the originator later and perhaps find out what happened. Exit interviews are quite useful when trying to improve marketing. Jay -----Original Message----- From: Andy Glick [mailto:[EMAIL PROTECTED] Sent: Sunday, September 25, 2005 4:16 PM To: [email protected] Subject: Re: [m1 or 2] Odd project structure... how much pain will this be? Brett Porter wrote: > Is it worthwhile publishing a few documents that show how various > project types would be set up for m2, like this? > > - Brett > > On 9/24/05, Kenney Westerhof <[EMAIL PROTECTED]> wrote: > >>On Fri, 23 Sep 2005, Eric Biesterfeld wrote: >> >>You're pretty much set up for maven use, except for the 'overlay' system. >> >>I'll demonstrate using maven2. >> >>I see: >> >>/base/pom.xml - base project >>/base/client/pom.xml - grouping project for all clients, has parent >>../pom.xml /base/client/X/pom.xml - project for client X, has parent >>../pom.xml >> >>As you compile the client/a/java/* to the base/target/ I expect those >>classes don't 'overlay' existing ones, because your build will break - >>the base classes are always newer than the client/a sourcefiles. >> >>So now you get 1 + count(clients) jars. For each client, that's 2 >>jars. If you can live with that, then so far it's easy. If not, you >>can add an 'assembly' goal to each client/a/pom.xml (ofcourse >>configuration specified in client/pom.xml) to merge the two jars. >> >>Btw, each client/a/pom.xml has a dependency on base/pom.xml. >> >>For the property/html overlay: the property part (which is probably >>going to end up in a jar /META-INF/ somewhere?) the assembly plugin >>and/or the resources plugin could take care of that. >> >>You need to use the unpack goal to unpack the base dependency into >>client/a/target/classes/ (${project.build.outputDirectory} (or another >>location if they shouldn't end up in the jar). >>This goal is bound to the 'generate-resources' lifecycle phase. >> >>Then maven2 will copy your client a's resources to the same location, >>overwriting the other ones. >> >>Or you could just specify a <resources> section in the client a pom >>that has '../../html' in it. Be sure to specify that section before >>the <resources> section that defines the client a resources. >>That order will have the effect of client a's resources overwriting >>the existing ones. >> >>But it would ofcourse be best to have disjunct sets of resources for >>base and the client projects, so that the client projects just 'add' >>to the base project, not change it's behavior. >> >>Maybe you can factor out the common features in the client projects, >>and make projects for each of those features. >>Then each client project just depends on the features that are >>appropriate for that client. But it's probable that this won't work in >>your particular case. >> >> >>So, here are some ideas. Hope it helps! I've worked at a number of shops that followed development practices similar to these, where they had "base" project contents and by customer customizations. So, yes, I think that publishing documents, or even full or partial project mockups that demonstrated various strategies for the configuration of M2 projects would be really helpful to people. And a a feature of Maven Evangelism I believe that this would be particularly useful for teams that are interested in computing the "price" of migrating projects/project families from existing build systems to Maven. And if the Maven use-case files were updated and kept in sync with the examples, that would be even better. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
