On Mon, Aug 25, 2008 at 6:13 AM, BoD <[EMAIL PROTECTED]> wrote: > The main difference I see is that our custom tool handles "scm" > dependencies. What I mean by that is that we have our project which is split > in several "modules" and they all have their own life on subversion, and we > say for example that the project is on svn://svn/project1/trunk and it > depends on svn://svn/module1/trunk and on svn://svn/module2/branches/v2. > Then when we "bootstrap" the project, the tool will checkout these two > modules, and generate an eclipse workspace, with one project by module, and > the "team" plugin setup as needed for the project and its dependencies. > So a developer can work on the project itself, but if he finds a problem on > a dependency he can also work on it! He has the sources and can commit, etc. > > When I used to work with maven, we only had "jar" dependencies, ie, the > project depended on "built" versions of some module (external or internal), > which is a bit different. > > So my question is, is this kind of "scm" dependency possible with maven?
It's a bit of both. If you have a set of related projects that tend to have the same lifecycle, it's not uncommon to put them in a multi-module project. If you go that route, then it's very easy to check out the multi-module project, have Maven build an eclipse workspace, and use them such that a change in one module is automatically reflected in the other modules within eclipse (project dependencies instead of JAR dependencies). If, on the other hand, these are projects that aren't very tightly coupled, then you'd usually stick to JAR-style dependencies, although there may still be another way of making what you want happen. It sounds like the former case is closer to what you need, though. - Geoffrey -- Geoffrey Wiseman
