With the arrival of the new project structure in 1.6 I'm looking for recommendations/experiences on organizing complex applications containing several major functional areas.
For purposes of this discussion, I'm envisioning -Application A --Functional Area A1 --Functional Area A2 --Functional Area A3 Assuming each functional area shares > 50% common entities, business logic and gui components, it isn't clear to me what approaches to organizing the codebase will scale with the eventual size of the application. Here are some of the options as I understand them: 1) Monolith Option. One project with one module, possibly supporting multple entry points. 2) One project, multiple modules. Maintain one project, but create multiple modules to organize common classes and functional areas. (How do you accomplish this in 1.6? It's not clear to me) 3) Multiple projects, one module per project. Create one project for each module, resulting in a commons project and a project for each functional area. Any thoughts/comments on this would be welcome... Advantages/Disadvantages? Options I'm missing? Good/Bad experiences with these approaches? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
