We're slated to talk about it tomorrow, and we're planning from then. I had originally discounted Maven 1 because the multiproject system looked so messy (and I really like transitive dependencies) but maven 2 beta looks like it's sufficent for our needs.
I'm still wary about the lack of documentation, but if we do go with Maven I will write up what we've done as a case study. On 9/26/05, Jay H. Hartley <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
