Hi, Thank you Pedro. After much thinking I realized your approach it is the best I can come up with as well :) I first thought of being a cool guy and using OOP by all means. I then will have a model, DAOs and managers for common and a custom specific implementation extending the common model. Problem is that we are not using the generic DAO that much so that we would have to reimplement the DAOs as well as the managers in case the logic changes or to return a list of the new entities. Not to mention the case the relationship changes. In this case the relationship must be changed from other classses as well so that they point to the new class/entity. And the DAOs must be doublechecked to see if the queries have still something to do the old entity. So there is no room for OOP I am afraid... Thanks again! I will go the way you suggested :) Br, Oscar On Mon, Jul 7, 2008 at 5:16 PM, pedro_burglin <[EMAIL PROTECTED]> wrote:
> > Hi Oscar, > > On a recent project I faced the same problem but due to some project > limitations I was using AppFuse 1.9.4 with SpringMVC. > > To allow parallel development of both generic code (which I called CORE) > and > project-specific code (which I called CUSTOM) I modified AppFuse's build > logic and directory structure as following: > 1. I moved AppFuse's original src, web, test folders into a new folder > called core; > 2. I changed AppFuse's build logic to get files from these new directories; > 3. I created new folders src, web, test inside a folder called custom. This > name 'custom' was a configurable property in the build props file. It could > be, for example, the name of the client I wanted to add customizations to > the generic implementation; > 4. I added new steps in AppFuse's build logic to, during build, copy files > from core directories to a temporary folder, and then overwrite these with > files from the custom directory. > > The final result was that the build logic would inject custom files into > jars and wars overwriting any generic implementation, if it existed. I am > not sure if that was the best approach but it worked fine for my needs, I > am > just unsure if it would be much harder to implement with Maven for AppFuse > 2.x... > > Hope that made sense, > Pedro Burglin > > > oscar perez wrote: > > > > Hi there, > > We are working in one project based on appfuse struts 2 multimodular. We > > are > > now in a final stage of the project and would like to reuse as much code > > as > > possible which is why we intend to create 3 modules. One with the common > > core features, other for the web and other for the customized core > > (customer-specific). Does this make sense? We are using extensively in > the > > view the opensessioninview pattern which I believe make things more > > difficult to reuse. Anybody has experienced the same problem?? What is > the > > best practice? Our main concern is that if we start a new project based > on > > copy-paste it will be more difficult to synchronize later and the extra > > work > > will not be worth it. Any suggestion? Thanks! > > Oscar > > > > > > -- > View this message in context: > http://www.nabble.com/Multimodular-project-with-Struts-2-%28best-practice%29-tp18312411s2369p18317603.html > Sent from the AppFuse - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
