You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Nuno Santos <ns...@redhat.com> on 2007/03/28 21:21:26 UTC
Qpid packaging (Java)
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
Re: Qpid packaging (Java)
Posted by Martin Ritchie <ri...@apache.org>.
Nuno,
That is a nice diagram.
Are you looing to reduce the runtime dependancies or just dependancies
in general?
Easymock is only referenced by the pom AFAIK. It was left in as there
was desire to use it for testing but we haven't gone that route yet.
Backport will be removed when we upgrade the Mina to the Java 5
version. If we want a Java 1.4 client then we will have to keep it for
that package.
Most of the dependancies seem to be a result of commons configuration.
Perhaps we could leave out the parts that we don't actually use.
--
Martin
On 28/03/07, Nuno Santos <ns...@redhat.com> 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
>
Re: Qpid packaging (Java)
Posted by Rupert Smith <ru...@googlemail.com>.
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 <ru...@googlemail.com> 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 < marnie.mccormack@googlemail.com> 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 <daniel.kulp@iona.com > 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
> > > daniel.kulp@iona.com
> > > http://www.dankulp.com/blog
> > >
> >
>
>
Re: Qpid packaging (Java)
Posted by Rupert Smith <ru...@googlemail.com>.
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 <ma...@googlemail.com> 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 <da...@iona.com> 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
> > daniel.kulp@iona.com
> > http://www.dankulp.com/blog
> >
>
Re: Qpid packaging (Java)
Posted by Marnie McCormack <ma...@googlemail.com>.
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 <da...@iona.com> 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
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>
Re: Qpid packaging (Java)
Posted by Nuno Santos <ns...@redhat.com>.
Rupert Smith wrote:
> Runtime deps for the java broker and client should look like: [...]
That list looks a lot more manageable, but I'm also interested in
tracking buildtime dependencies, because for our purposes we need to
provide everything that's required to build the binary rpm from sources.
> This is just taken from a distribution .zip file. Even this list includes
> things that are probably not needed. Like what on earth is isorelax?
In that list, two other packages -- msv and dom4j -- depend on isorelax,
so it seems to be a 2nd level dependency. FWIW, isorelax's description
is "Public interfaces useful for applications to support RELAX Core", so
it's related to the use of the NG RELAX datatype.
Nuno
Re: Qpid packaging (Java)
Posted by Rupert Smith <ru...@googlemail.com>.
Runtime deps for the java broker and client should look like:
relaxngDatatype-20020414.jar
isorelax-20020414.jar
mina-core-1.0.0.jar
log4j-1.2.12.jar
commons-collections-3.1.jar
qpid-client-1.0-incubating-M2-SNAPSHOT.jar
commons-codec-1.3.jar
backport-util-concurrent-2.2.jar
xercesImpl-2.2.1.jar
geronimo-jms_1.1_spec-1.0.jar
xalan-2.7.0.jar
mina-java5-1.0.0.jar
jaxen-1.0-FCS.jar
commons-beanutils-1.6.jar
commons-logging-api-1.0.4.jar
saxpath-1.0-FCS.jar
commons-lang-2.1.jar
commons-digester-1.6.jar
commons-cli-1.0.jar
qpid-common-1.0-incubating-M2-SNAPSHOT.jar
msv-20020414.jar
qpid-broker-1.0-incubating-M2-SNAPSHOT.jar
commons-logging-1.0.jar
mina-filter-ssl-1.0.0.jar
servlet-api-2.3.jar
commons-configuration-1.2.jar
com.ibm.icu-3.4.4.jar
slf4j-simple-1.0.jar
xml-apis-1.0.b2.jar
commons-beanutils-core-1.7.0.jar
dom4j-1.4.jar
This is just taken from a distribution .zip file. Even this list includes
things that are probably not needed. Like what on earth is isorelax?
Rupert
On 02/04/07, Nuno Santos <ns...@redhat.com> wrote:
>
> Daniel Kulp wrote:
> > 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?
>
> Thank you Dan (and others) for pointing that out... The srpm that I
> started with includes the client, the broker, and all the tests so all
> the dependencies got bundled together in that graph. I'm working on
> decoupling the tests so that we have a better representation of the
> actual runtime dependencies.
>
> In the meanwhile, just for the sake of completeness, I created a graph
> of the full dependency tree (as I mentioned in the previous email, the
> graph I posted excluded all the maven2 deps, as well as packages that
> were already part of Fedora)... if you want to take a look, it's
> available at http://people.redhat.com/nsantos/graph-full.png , with the
> maven2 deps expanded at
> http://people.redhat.com/nsantos/graph-maven2.jpg (we've simplified the
> maven2 deps quite a bit, but that's what they originally looked like)
>
> Nuno
>
Re: Qpid packaging (Java)
Posted by Nuno Santos <ns...@redhat.com>.
Daniel Kulp wrote:
> 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?
Thank you Dan (and others) for pointing that out... The srpm that I
started with includes the client, the broker, and all the tests so all
the dependencies got bundled together in that graph. I'm working on
decoupling the tests so that we have a better representation of the
actual runtime dependencies.
In the meanwhile, just for the sake of completeness, I created a graph
of the full dependency tree (as I mentioned in the previous email, the
graph I posted excluded all the maven2 deps, as well as packages that
were already part of Fedora)... if you want to take a look, it's
available at http://people.redhat.com/nsantos/graph-full.png , with the
maven2 deps expanded at
http://people.redhat.com/nsantos/graph-maven2.jpg (we've simplified the
maven2 deps quite a bit, but that's what they originally looked like)
Nuno
Re: Qpid packaging (Java)
Posted by Daniel Kulp <da...@iona.com>.
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
daniel.kulp@iona.com
http://www.dankulp.com/blog