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 >
