On Dec 9, 2009, at 10:53 PM, Jarek Gawor wrote:
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.
To me it depends on "how shared". Something like xmlbeans is used
independently in a lot of builders. On the other hand there are a lot
of console-related dependencies that are used only in console plugins,
and for these I am inclined to think they should be specified in the
base console plugins pom and that imported for the other console
plugins.
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.
I haven't seen this myself. IIUC it seems like a really serious maven
bug. Is it reported?
Because of that I've been trying to avoid <scope>import</scope>
imports and wanted to make sure we don't over abuse them.
I forgot to mention that my overriding goal is to make it easier to
build and release the plugins independently, and then assemble servers
even more independently. In this model the idea of a root pom sort of
disappears.
thanks
david jencks
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
