I'm +1 for moving some shared dependencies into root pom. If some dependency is not shared then it can live in some plugin's root pom.
I do have problems with <scope>import</scope> imports or at least with how maven handles them. During a build, Maven might initially download/use a snapshot of that imported pom with one set of dependencies but later build the same pom with another set of dependencies. So I never know which dependencies are really used at build time with scope imports. Because of that I've been trying to avoid <scope>import</scope> imports and wanted to make sure we don't over abuse them. Jarek On Thu, Dec 10, 2009 at 1:03 AM, Ivan <[email protected]> wrote: > Thanks for the clarification for the two solutions, David. > But I do not think that it is better to move all the dependencies out from > the root pom.xml file. It makes sense that define them in the plugin's pom > file for Tomcat or Jetty. But for those tool packages, like xmlbeans, > xmlresovle, etc, I still think it is better to put them in the root pom > file. For example, it will make it strange to import pluginA just for using > a xmlbean package, although it would not a problem from technical side. > Any comments ? > > 2009/12/10 David Jencks <[email protected]> >> >> On Dec 9, 2009, at 6:51 PM, Ivan wrote: >> >>> Hi, >>> I found some third-party bundle defintions are in the >>> framework/pom.xml, Is there any reason to keep them there ? If not, I would >>> suggest to move them to the root pom.xml file, so that all the plugins could >>> refer to them. >> >> To me this is a difficult question. There are two plausible alternatives: >> >> 1. move all dependency management for the entire project to the root pom. >> >> 2. move all dependency management to either framework root pom or the >> plugins root pom that introduces them, and use the <scope>import</scope> in >> dependency management for other plugins that need the dependency to import >> the pom that sets up the dependencyManagement.. >> >> 2 depends on the very recent import scope feature, we could not have done >> it for any 2.1 or earlier releases. >> >> Arguments can definitely be made on both sides of this discussion. At the >> moment my thinking is that (1) promotes a monolithic project that is >> difficult to split into independent modules that are assembled, and that (2) >> promotes more modularity at the possible cost of making dependency tracking >> slightly harder. So, over the last few months I've been moving towards (2), >> putting dependency management for e.g. the imported jetty jars in the jetty8 >> root pom. >> >> So, I'm in favor of gradually moving all the dependency management out of >> the root pom. >> >> thanks >> david jencks >> >>> Thanks ! >>> -- >>> Ivan >> > > > > -- > Ivan >
