Your approach definitely makes sense ... and memorializes a great acronym to boot .
Don't get the MADs mad at you :-) Craig On Wed, 12 Jan 2005 19:43:37 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > > > > Note that this particular separation (of the model APIs and DAO) has > > been done already ... core/trunk/struts-examples/mailreader. We'd > > only need to make all the incantations of mailreader use this common > > code base to reduce some of the duplication. > > Yes, I noticed that a few weeks ago. I don't intend to change that, > in fact, I plan to build on it....see below. > > > > > However, you're going to end up with different implementations no > > matter what ... they exist to illustrate different technological > > approaches to building the same app, to facilitate comparisons. > > I am applying a strategy that builds the variations of mailreader > apps by repeating a process that, for each mailreader app: > > a) copies the "common" or "standard" base file structure and files > to a target dir > b) copies **/*.* over top of that > c) generates any docs/javadocs/etc and wars the artifact > (would also run the full test suite....yes I'm volunteering ;) > > This process would repeat for each "one-off mailreader"....like so: > > -- default -- > apps/trunk/mailreader/standard > apps/trunk/mailreader/el > apps/trunk/mailreader/shale > apps/trunk/mailreader/jericho > apps/trunk/mailreader/resources (impl using commons-resources) > apps/trunk/mailreader/chain (probably don't need this any more) > apps/trunk/mailreader/tiles (this is not the tiles doc app) > > -- optional -- > apps/trunk/mailreader/j2ee (mostly xdoclet generated ejb 3.0 > against HSSQLDB) > apps/trunk/mailreader/spring > apps/trunk/mailreader/resources-hibernate (HSSQLDB with Hibernate) > apps/trunk/mailreader/spring-hibernate (it's a beautiful thing) > apps/trunk/mailreader/resources-jdbc (HSSQLDB with JDBC) > > There's a main project.xml in apps/trunk/ > Each mailreader app project.xml extends that and overrides only what it > needs to for that specific app. More or less why Maven was invented in > the first place (from what I've read). > > This way we don't have to have full blown webapp structures that > duplicate 95% of the code. Only the files that are actually different > than the "standard" will exist in these "one off"'s....what do we call > these anyway? "Mailreader app demo"? (MAD) > > So, in the end, if you were to add some new button or page to > the standard app, they would all inherit it. And if something changes > that breaks any one of the "MAD"s (LOL), the extensive test coverage > would catch that....yes I'm volunteering again ;) > > Does that make sense the way I explained it? > > > > > Craig > > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > --------------------------------------------------------------------- > 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]
