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]



Reply via email to