I use option 1 and it works well. Your C package embodies all aspects of the model and packages A and B contain controllers and views (in the MVC sense). This also ensures that all aspects of the model are available to A and B whether or not originally needed in both - projects which share common code tend to expand and share more code over time. There is a slight overhead in maintenance but it is well worth it (I reduce the overhead by using maven).
...Chad On Tue, Jun 2, 2009 at 1:13 AM, E <[email protected]> wrote: > Hi. > > I have a common library of code "C" that is shared between two separate java > applications, "A" and "B". > > C includes a set of iBATIS XML files and related java classes that are used > by both programs. > > However, each of A and B have some additional classes and XML files that are > to be used as well as the common ones from C. (All code is talking to the > same database.) > > So far I have three possible solutions, none of which are ideal. > > 1) Refactor all iBATIS related classes and XML from A and B into C, so it's > all in the one "module". > > 2) Have each of my main SQL Map XML configuration files also do <sqlMap > resource="..."> for the XML resource files that are in C - which is a > maintenance headache. > > 3) Create two SqlMapClient objects, one for C, and one for the application I > happen to be in (either A or B). > > Any feedback on a better way to do this would be appreciated. > > E. > >
