Also, we should think about how we declare our dependencies because others will depend on qpid as a library and we don't want to give them some of the dependency headaches we are presented with by our dependancies. For example in the junit-toolkit, I now declare the log4j version as: [1.2.8,), which means that it works with log4j 1.2.8 or greater, so as to not force dependants to use 1.2.8 fixed. Qpid should do the same for log4j at least.
Maven transitivie dependencies - I really have my doubts about them, but thats another story... Rupert On 29/03/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
The retrotranslator runtime stuff, had to be declared as provided to get the retrotranslator plugin to work. It is onyl actually used in retotranslated java clients. I think maybe, I need to move the retrotransaltion of client and common into seperate packages, so as not to pollute the originals with unneeded dependencies. Its possible to exclude dependencies in the the assembly descriptors, when packaging builds for distribution, and I think I made sure they were excluded there. One day, I'll find the time the redo the retrotranslator stuff more cleanly. Rupert On 29/03/07, Marnie McCormack < [EMAIL PROTECTED]> wrote: > > Hi All, > > I think there's probably something to be said for a more detailed > discussion > on the list of dependencies .... > > Afaik we're not using easymock ? Please let us know if you are using it > on > the Java side. Iirc Steve introduced it as potentially useful in the > future, > but I'm not aware that we have mock objects that use it. (That said, my > focus has been a little removed from the code base over the last few > weeks > so I could be out of date.) > > Imho we have a ton of unused stuff which gets maven'd into the > repository > when we build. A load of it could/should be removed ! I suspect that for > > each one unnecessary package we have a dependency on we get several > others > too :-( > > Bfn, > Hth, > Marnie > > > On 3/29/07, Daniel Kulp <[EMAIL PROTECTED] > wrote: > > > > > > Nuno, > > > > MOST of this tree looks to be stuff that falls into "test" > dependencies, > > not runtime dependencies. Is it possible to redo the graph with > > runtime dependencies only? > > > > For example: the big tree on the left that extends from > > easymock-classextensions. Easymock is used by the unit tests to mock > > up various objects to allow for better unit testing. That's a good > > thing. However, easymock isn't something that the shipping product > > would have any dependency on. It's just used for the unit tests. > > > > Most likely, the dbunit stuff also falls ino that. > > > > > > That all said, there are some issues with the dep mgmt. For example, > if > > I run "mvn dependency:analyze" in common, I see: > > [INFO] Used declared dependencies: > > [INFO] junit:junit:jar: 3.8.1:test > > [INFO] org.apache.mina:mina-core:jar:1.0.0:compile > > [INFO] log4j:log4j:jar:1.2.12:compile > > [INFO] Used undeclared dependencies: > > [INFO] None > > [INFO] Unused declared dependencies: > > [INFO] org.apache.mina:mina-java5:jar:1.0.0:compile > > [INFO] > > net.sf.retrotranslator:retrotranslator-runtime:jar:1.2.1:provided > > [INFO] org.apache.mina:mina-filter-ssl:jar:1.0.0:compile > > [INFO] org.slf4j:slf4j-simple:jar:1.0:compile > > [WARNING] Potential problems discovered. > > > > Thus, a bunch of dependencies are declared, but not used. Those > probably > > should be cleaned up. > > > > > > > > > > Dan > > > > > > On Wednesday 28 March 2007 15:21, Nuno Santos wrote: > > > I've been working on packaging the Java code and was somewhat > > > surprised with the amount of dependencies that our code (client + > > > broker) currently has. "Dependencies" in this context should be > viewed > > > as "requires" and "build requires" for rpm deployment and building, > > > i.e., all the packages that need to be installed before qpid can be > > > itself installed or built. > > > > > > This points to a graph of a *partial* dependency tree: > > > http://people.redhat.com/nsantos/graph.png > > > > > > The original tree is much larger, but I've excluded maven2 and all > its > > > dependencies, as well as packages that are already in Fedora 7 > (which > > > takes care of things like ant, saxon, among many others). Still, > this > > > leaves a long list of 40 packages. > > > > > > It's been pointed out to me that some of these dependencies may be > > > lingering artifacts from stuff that was once used but is no more... > if > > > any of you can identify specific instances of such packages, or > > > suggest other ways to prune the tree, I'd truly appreciate it. > > > > > > Thanks, > > > Nuno > > > > -- > > J. Daniel Kulp > > Principal Engineer > > IONA > > P: 781-902-8727 C: 508-380-7194 > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog > > >
