Looking at the number of 3rd party jar file we
needed to distribute with the initial code contribution and the tight process
of Eclipse Legal I decided to look into refactoring the code in an attempt to
remove some of the non-necessary ones.
It turns out that:
<![endif]>the dependencies on
commons-jelly-*.jar was mainly due to some file operations that I was able to
re-implement in Java directly.
<![endif]>The dependency on Jaxen (XPath) was
only triggered in 2 calls in the whole code, where I had been “smart”
and used an XPath _expression_ to navigation a simple XML document. As it turns
out, it is just as simple to walk the document directly… which removes
There should be no impact on the behavior of Tigerstripe as
a result of this refactor expect for the Copy
Rules in plugins where is a “**/*.xxx” _expression_ was
used… a little testing would be required J. We were
using the native Ant/Fileset implementation indirectly, now it is a lightweight
Please let me know if you stumble on any problem there.
As a result we are down to a set of pre-approved 3rd
party jars + Qdox + Velocity. So we should be in good shape now.
I’ve updated a table to list these dependencies: http://wiki.eclipse.org/Tigerstripe_3rd_party_jars
Cisco Systems, Inc.
Mail Stop SEA1/5/
2901 Third Avenue
Seattle, WA 98121
This e-mail may
contain confidential and privileged material for the sole use of the intended
recipient. Any review, use, distribution or disclosure by others is strictly
prohibited. If you are not the intended recipient (or authorized to receive
for the recipient), please contact the sender by reply e-mail and delete all
copies of this message.