I often will create a "local" aggregator project which contains all the
related projects I am working on.
I don't check that "local" aggregator project into source control, and I
throw it away when I am done with that and ready to move onto something
else.
If you go with tis route, then the only
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, an
We build an LMS application with over 70 modules.
We make each project a separate Eclipse project with its own version,
Maven builds a number of artifacts for us.
- Libraries of common code that are used as dependencies in other projects
- War files that are run under Tomcat - WebServices and We
> 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
> expect
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 p
