Whatever strategy you opt for should be one that the team is comfortable with and is willing to support. I'm a fan of the flat approach. I try to keep modules as simple as possible this way builds fail fast with immediate feedback to the team.
I use Maven in our environment to build out server, android (SDK and NDK) and iOS related builds. A quick browse of our svn/git repo's shows 50+ flat modules all sharing the same parent. If it works for a developer in eclipse/xcode but doesn't build from Maven the build is considered broken. The downside to a flat approach is developers do have to import quite a few modules as eclipse projects to get a working development environment but they only need to bring in what they need for the areas they are working on. However, for me the biggest gain is build reporting I can select the modules that actually make up our products and focus on those and not have to worry about all the non shipping related aspects that would be present in a multi-module project. -- Robert On 4/20/12 12:36 PM, "Tim Dugan" <[email protected]> wrote: >I'm new to maven and very much used to the "application per eclipse >project, and common library per eclipse project". > >I know "multi module vs. flat" has been discussed multiple times on this >list, but I've not seen general "pros/cons, rules of thumb, etc." of >when an application should be part of a multi-module vs. split out to >another eclipse project. > >I'm going under the assumption in the "maven way" it's OK to have >multiple applications living as part of a multi-module, for example >foo_webapp and cmd_line_client both dependant on lib_a > >MyMultiModuleProject >->lib_a >->foo_webapp >->cmd_line_client > >But what decides that foo_webapp and cmd_line belong here, just their >dependency on lib_a and the desire to share pom config & version them >together? For example, should a few new applications, also dependent on >lib_a should live here? When does it end? Or perhaps if "lib_a" is >expected to be widely reusable it should live outside the >multi-module...or???? > >Any links to references greatly appreciated... > >Thanks for your input! >Tim > > > > >--------------------------------------------------------------------- >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]
