Update: I cleaned up the example based on Rogerio’s comments.

Recently I stumbled onto JMockit and have been pretty impressed with the flexibility of the approach it takes.

Many mocking frameworks seem to take an elitist attitude toward testable code, not attempting to solve certain problems in favor of guiding one toward a more testable design. It appears JMockit is a response to this.

There’s no getting around the fact that some frameworks, especially legacy or proprietary third party modules, are not coded in such a way that it’s easy to write testable code against them. Common pain points include:

• Pervasive use of statics
• Lack of dependency injection mechanisms
• Creating dependencies inline with the “new” keyword

All of these issues will pose problems when trying to double-out dependent code for testing purposes. One approach to solve these problems is to use a dynamic language and metaprogramming constructs to do this kind of doubling. Testing Java code with JRuby or Groovy has become more and more popular for this very reason.

But a lot of these will introduce a level of language abstraction between your test code and the code under test, and you’ll have to have developers maintaining a test suite sign on to learn the language being used.

In comes JMockit, which uses the instrumentation features provided with Java5 to perform a lot of the same magic tricks for you.

This also allows you to test things that weren’t otherwise possible (or are very difficult) and overall I think the programming model is much more in-tune with standard Java programming idioms. It doesn’t discriminate against you if you don’t use dependency injection, but will work with you if you do. Here’s a quick example that colleagues Andy Pemberton and Patrick Cox worked through with me trying out JMockit.

You can get the whole project from my GitHub account.

More Related Content

• February 17, 2009 -- Don’t Unit Test Anymore… No, Really! (6)
• June 3, 2009 -- What is Hamcrest? (0)
• January 31, 2009 -- In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel (3)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• July 8, 2010 -- Transactions, Part 1 (0)
• January 7, 2010 -- Eliminate Branching (IF Statements) to Produce Better Code (0)
• July 29, 2009 -- What I’d Tell Myself About Design If I Were Just Beginning (5)
• July 24, 2009 -- The Elements of Reusable Code (0)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• November 19, 2008 -- Java 6 and Maven 2.0.9 on Leopard (7)

As of JUnit 4.4, if you happen to peek into the distributed JAR you’ll notice something a little off: in addition to the org.junit.* packages there is this a funny-looking org.hamcrest.* package sticking out like a sore thumb. You may have seen other projects pick up a dependency on Hamcrest lately as well, and I bet you’re wondering what it is. Let’s get to the bottom of it.

Introduction

The “I’m Feeling Lucky” Google search for the term hamcrest currently takes you to the project’s Google Code page that states Hamcrest:

Provides a library of matcher objects (also known as constraints or predicates) allowing ‘match’ rules to be defined declaratively, to be used in other frameworks.

That’s a pretty good description if you already know what a Matcher is… but it doesn’t explain much for a beginner. So what does Hamcrest really do for you? 

It's just like... It's just like... A mini... REGEX!

A good way to think of it is that Hamcrest is to objects what regular expressions are to text.
Hamcrest provides you with a set of methods that effectively define a DSL to do pattern-matching on objects.

What can you use it for? Well, like regular expressions, the possibilities are endless. Some really novel uses have come about recently, but the most prominent use has been in the area of testing – hence the JUnit dependency.

A Brief History

Hamcrest evolved out of the library JMock, being used to write specialized constraints on what you expected to happen to a Mock object when standing in for a real implementation. A more fluent assertion syntax arose from these constraints which allowed you to chain together main constraint calls under a single assertThat method. Later JMock’s author, Joe Walnes, refactored the constraint API out into its own library called Hamcrest as people became interested in using it outside of a testing framework for all kinds of different things. He also started calling the constraints “matchers” though they can go by both names or, in some circles, “predicates.” Other testing frameworks and even JUnit, notorious for not requiring any dependencies and staying conceptually small, have picked it up.

All those old friendly org.junit.Assert.* static methods are still around in JUnit 4.4+. They’re useful for certain things, but by and large they’ve fallen out of style. The new kid on the block, JUnit’s assertThat method allows you to pass a Matcher in to create an assertion that you would otherwise use a specialized-assert method. Why is assertThat so useful? A few different reasons. Not only does it provide a more generic way to specify assertions, it also alows the framework to know specifically what you’re trying to assert. That allows the framework to generate failure messages for you.

Fail message… win?

It’s always been a good idea to use the overridden version of assertX method that also takes a String for a failure message, for example:

If we passed in an object representing a childhood version of Blackbeard, say, (before he took to the high-seas) then we’d expect to see our failure message:

It’s always been a good idea to provide these messages. But there’s no getting around the fact that they’re repetitive, tedious, and redundant.

Using Hamcrest matchers alongside assertThat makes JUnit smart enough to generate meaningful failure messages for you: writing your assertion with Hamcrest matchers provides the framework with enough contextual information to generate meaningful failure messages on your behalf. No need to maintain an extra arbitrary String to make sense of your failed assertions:

This may not look like much of an improvement, but it also doesn’t read any worse. We can ditch the extra String parameter as well. When this fails we’ll get a pretty cool failure message for free:

Note: I’m using JUnit 4.6 – in order to get this syntax to work you need to do some static imports:

It looks like there’s still work being done to make this DSL read more fluently in JUnit; something like:

Other Cool Stuff

Getting Reused

TestNG, JMock and many other testing frameworks will certainly benefit from what Hamcrest offers, but we’re starting to see this being used in many other places as well. I’ll be interested to see how well matchers work together or are maintained seeing that they’re relatively easy to create. Hopefully frameworks will contribute useful matchers back to the project.

Chaining

Because the matchers are implemented as a DSL using the method chaining idiom, they’re extremely easy to combine and extend.

Matchers For Regular Expressions

To bring the blog post full circle, I found this earlier tonight: the Hamcrest Text Patterns project. Its goal is to have you write Hamcrest-style regular expressions using matchers which will produce much more readable regular expression code. For example, have a look at this test that I found in the project:

By providing a friendly name for each capture (user, host, scheme, email) you can provide meaningful messages programmatically about what doesn’t match up when something doesn’t match.

Conclusion

I hope you choose to take a closer look at Hamcrest because it brings a big bang-for-the-buck and has the potential to guide us to more human-friendly, readable code.

Further Reading

• Have a look at Joe Walnes’ blog for a great introduction to using assertThat as well as other creative uses of Hamcrest matchers.
• Also take a look at Nat Pryce’s blog for more info on Hamcrest and Testing in general.

More Related Content

• June 9, 2009 -- Mocking with JMockit (5)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• November 19, 2008 -- Java 6 and Maven 2.0.9 on Leopard (7)
• July 8, 2010 -- Transactions, Part 1 (0)
• January 7, 2010 -- Eliminate Branching (IF Statements) to Produce Better Code (0)
• July 29, 2009 -- What I’d Tell Myself About Design If I Were Just Beginning (5)
• July 24, 2009 -- The Elements of Reusable Code (0)
• February 17, 2009 -- Don’t Unit Test Anymore… No, Really! (6)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• September 10, 2008 -- Axis2 client using ADB – runtime dependencies (6)

Update: A great article on OSGi popped up on Javalobby today. Check it out.

I haven’t yet written any thoughts about OSGi but it’s something that’s increasingly found its way on to my radar over the past year and a half or so. I’ve been doing a little bit of reading and research on it lately, (a quick introduction can be found via Adrian Colyer’s talks on InfoQ about it). Needless to say it’s got me excited. Really excited – to the point where I’m catching myself geeking out uncontrollably like Quagmire from Family Guy. What’s got me all giggity? Let’s take a step back first.

With Java there has always been a focus on modularity, but it’s come up in different intermediate forms. Any typical Java developer can go on for hours about the importance for layering and properly isolating, decoupling and packaging components and subsystems. Java has the idea of a package, and the idea of JARs came about fairly early on in the process. But what became difficult was that often each layer had to have its own supporting infrastructure in place to be built independently, and someone needed to know how all of those JAR dependencies mapped out at build time and runtime. This was a necessary evil so that we could have individually deployable modules or subsystems. Once you got there, it was all worth it.

The problem was that while you may have been diligent and rigorous in your approach to applying how your projects were laid out and built, quite often the framework space solved this problem over and over again in many different ways. Going to upgrade a library was not an easy task, because you had to typically upgrade it across each of your layers, and what’s more, there was no consistent approach to manage transitive dependencies amongst the modules each library used. Library selection and dependency management was the work of a greybeard within your project and it took a while to change a library or upgrade. Not to mention a near certainty that you’d need to execute your entire suite of regression tests to make sure nothing broke.

After seeing many Java frameworks being cajoled into a Maven build in order to manage builds and transitive dependencies, there has been increased awareness on the part of the vendor (be it commercial or open source) space on modularity. But we’ve only focused on the problem of solving modularity from a build-centric view. In other words, “How can I package and manage these build artifacts in such a way that consumers can easily integrate them into their project in a consistent and automated way?” This was the pie-in-the-sky idea behind Maven as I see it, and they pretty much made it happen. You’d be hard pressed to find a framework today that doesn’t support it in some fashion.

But there’s a whole separate piece of modularity that takes place at runtime. In the context of my historical explanation of modularity within Java, you can look at OSGi’s ability to manage dependencies dynamically at runtime (via a header in your JAR MANIFEST file) as a “modularity win” and icing on the cake. But OSGi indeed goes farther than that. OSGi gives you the ability to install/uninstall, start and stop bundles dynamically (think Eclipse plugins) via its lifecycle, and that just plain gives me the “giggities.” To account for truly dynamic modularity OSGi also gives you requires and provides semantics (also declared via headers) akin to the requires and provides semantics you see in dynamic languages like Ruby and some Javascript packaging/dependency management frameworks. While this may seem like its strength is only in making a clear separation between APIs you use and export, its real strength is that this allows you to truly isolate your modules at runtime from trickery that can (and has) happened on a classloader level. “That couldn’t possibly work on an App server,” you say? I was skeptical, too, but not so fast…

If you’re the type that keeps up with the JCP space, you probably know there is a JSR “trinity” (equally as mysterious as its holy counterpart to the outside viewer) to provide a more robust modularization mechanism in varying degrees. That “quagmire” withstanding, OSGi has been mounting a considerable lead as the modularization system of choice in the JavaSE and EE/App server space. (It was already a formidable player in the embedded/mobile space, where it evolved from.) Nearly all major App server vendors have integrated the OSGi model into their core, which means they’ve probably cleaned up any classloader nastiness they’ve resorted to in the past. And now you’re seeing some of the leading frameworks like Spring and Web Beans/Seam 3 (and subsequently have signed up to publish themselves as OSGi bundles.) Not to mention the success that Eclipse has seen since refactoring itself to work off its OSGi implementation, Equinox.

If OSGi can continue to make inroads in the framework space, I think its prospects to the “in the trenches” Java developer are very exciting indeed. Expect me to babble on more about this in the future…

More Related Content

• July 24, 2009 -- The Elements of Reusable Code (0)
• June 3, 2009 -- What is Hamcrest? (0)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• November 19, 2008 -- Java 6 and Maven 2.0.9 on Leopard (7)
• March 19, 2008 -- New Wave Logging (0)
• July 8, 2010 -- Transactions, Part 1 (0)
• January 7, 2010 -- Eliminate Branching (IF Statements) to Produce Better Code (0)
• July 29, 2009 -- What I’d Tell Myself About Design If I Were Just Beginning (5)
• June 9, 2009 -- Mocking with JMockit (5)
• January 31, 2009 -- In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel (3)

I just read Your Unit Tests Lie to You by Janusz Gorycki and I was going to leave a comment there, but thought it was more appropriate to expand my comments off into their own thing.  For those that haven’t read the article, its basic premise is to grab hold of the nearest “test infected” reader and shake the warm and fuzzy out of them.  It paints the short sightedness of many recent “unit testing” converts as living in a dream world where unit tests should replace formal testing. It follows with many sentiments I’ve read (and written about here) for a while now.  It’s not that I disagree with what is being said in the article, or its tone for that matter; most of what is being said is spot on.  Unit testing is definitely not a silver bullet.  If you read my blog often, you no doubt get that. The article ends:

So please, don’t fire your QA department just yet. Their job is still important, even if you unit test.

So to Janusz, the fundamental problem here is a general ignorance of the purposes behind a unit test suite.  I agree 100% that’s the primary factor behind his problem.  What don’t we agree on?  Semantics.  But semantics are important!  How far do we have to go for a true zen-understanding of this issue?  Not far.  Indulge me —

When is A Unit Test is not a Unit Test?

Here’s my thesis: you may use a unit testing framework, but what you write are developer tests.  Even if they are technically unit tests, it is against everyone’s interest to call them this.  Picky, useless distinction, you say?  Hear me out.

There is a vast difference between the gamut of possible automated tests one could write and what is known colloquially as a unit test.  A number of different kinds of automated tests are written against frameworks that are built on top of unit testing frameworks.  That doesn’t make them unit tests.  It doesn’t make sense to call them unit tests.  A square is a rectangle, but does that make every rectangle a square?  An automated acceptance or integration test is subject to a completely different set of problems (in areas such as specification, maintenance, complexity) than a unit test.  In fact, about the only thing they share is their lifecycle and execution model, which many times has been retrofitted into the JUnit lifecycle and execution model.

“Unit Testing” and Linguistic Drift

I’ve recently seen a number of different incarnations (1, 2, 3) of the argument that we should eschew use of the term “best practice” because of the implications of its linguistic drift and general propensity of people to turn off their brains when just spoon-fed answers, not having to experience deriving the solution for themselves.  Similarly, the popularity of unit testing frameworks and the sheer frequency with which the term has been used have, in a sense, set the idea of developer testing back considerably.  Cedric Beust makes the point that in many cases we’ve confused [developer] testing terminology with JUnit terminology, and TestNG was in part a response to that.  Here we oversimplify the problems we choose to bite-off and the goals we strive toward.  They’re not realistic.  Is it no wonder so many people fall flat when trying to adopt “unit testing”?

While there may be some overlap with the goals of validation and verification, most in the know consider the true benefits of “unit testing” to be a totally different animal altogether.  We seem surprised to find the benefits of doing developer testing have little to do with what “testers” do.  This dischord causes a lot of confusion, and has sparked a lot of articles.  Some draw this conclusion, appropriately, that developer testing, while it fits a rigid definition of what testing is, shares little with what a typical “tester” is responsible for (true V&V).  Quite often developers are the only ones doing any automation work, including this automated “developer” testing.  Developers tend to do it for all kinds of different reasons, too.  We’ll use a suite of automated tests to proceed without fear of integration errors.  That adds value totally independent of validation and verification practices.  If our suite catches regressions before we hand a single version off to testers, that saves both developers and testers time.  I could go on and on, but the term “unit testing” conveys very little of these kinds of benefits to the development lifecycle, and as it turns out, causes a great deal of confusion.

The Right Usage

When we’re talking pure unit tests, that is, black-box testing components in pure isolation (which requires isolated dependencies), not in concert, as developers we can certainly find merit in this practice.  But what we’ve learned is that this idea of unit testing, while quite beneficial as a development practice, shares very few goals with “testing” as we know it from a classical definition of the word (end-to-end V&V).  Perhaps a few years ago this distinction was not that true, but we now know better.  We know the danger in trying to bend unit tests into something they’re not.

My point is essentially this: knowing how to use a unit testing framework, a very simplistic construct on the surface, to do all of these wonderful things is certainly not something that just “falls out” of developing a unit of code – it’s not something we should expect developers to just deliver each iteration as part of their deliverable like it’s “done.”  Effort invested to develop and maintain test code alongside the code under test is not free.

Only if you are persistent will you come to understand there sometimes is very little benefit in terms of “full blown”, classical validation and verification – the whole reason you set out on this crazy “unit testing” kick. You either stick with it, or write it off at this point.  If you stick with it,  well, I’ll save you the trouble of figuring this out for yourself; you learn it’s only another development practice, that needs to be balanced out with other sound practices. It’s hard work.  Really hard.

Then why go to all the trouble?  It’s my contention, and I assume most will agree, that developer testing is useful.  It drives out better designs, code, and has the potential to thwart a caste of would-be regressions.  It can stamp out integration errors.  It can help you learn about a new framework or prototype a new feature.  But that usefulness comes with a very real cost.

If we truly acknowledge that the type of practice we’ve talked about has merit as a development process, it makes very little sense to continue referring to the practice as “unit testing.”  If testing modules of code, driving development with these tests, maintaining them alongside the code, and other automation activities are worthy practice for developers, we should consider the semantics of our vocational vocabulary.  Let’s stop confusing each other.  We’re not talking about delivering 100% code coverage, we’re not talking about replacing testers (unless you’ve got the huevos to go without them, anyway), and we’re surely not talking about writing or releasing bug-free software.  It’s a lot easier to cut through a lot of the hype and confusion if we can all learn to say developer testing and understand it as such.  Let’s put the term “unit test” to rest.

R.I.P. unit tests.  Long live “developer tests!”

More Related Content

• June 9, 2009 -- Mocking with JMockit (5)
• January 31, 2009 -- In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel (3)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• June 3, 2009 -- What is Hamcrest? (0)
• March 13, 2008 -- Continuous Integration Dissected (0)
• March 11, 2008 -- Bugs, Detectives, and Test Automation (2)

I’ve been doing a lot of reading lately and have been meaning to plug some of my favorite reads, and one of the things that I’ve been trying to read with an eye toward is for converting those that have been stuck on “behind-the-curve” projects to the new way of thinking and doing things. As such, and just in time for the weekend, I’ve compiled a list of my favorites with an eye to the “movers and shakers” that have driven innovation in the Enterprise Java world recently. Note that even though some of these links are specific to certain frameworks/technologies, there is a common thread throughout most of these that have a bigger focus on the best way to solve problems using Java 5/EE 5 constructs and concepts.

A book that should be on any Java developer’s shelf is Effective Java (2nd Edition). Make sure you get the second edition, for all of the Java 5 changes. This talk by Joshua should whet your appetite. (His talk on good API design is also very good.) You should also take a look at Bob Lee’s talk on Guice. Guice’s philosophy and focus on typesafety has spilled over into Web Beans (and newer versions of Seam) and its annotation based approach has heavily influenced newer Spring features. I especially like his points on type safety around the 11-minute mark. The walkthrough at the end of the talk from “old way” to “new way” is great for people who haven’t really gotten away from Factories, Delegates, and Service Locators yet.

The Guice video mentions that a common thread in modern Java frameworks is a focus on testability. Testing is a very important concept that nearly all new frameworks have embraced, but you still need know-how to be successful with testing. I’ve come across some great books recently in the automated (developer) testing arena. I’ve found the most thorough book on the topic out there is Lasse Koskela’s Test Driven. The ideas and topics discussed in the book are really language independent, and work equally well with other languages. To cut your teeth on TestNG, which the Seam documentation turned me onto, I recommend the TestNG developers’ book Next Generation Java Testing: TestNG and Advanced Concepts. Cedric Beust, also the author of EJBGen, and Hani Suleiman, author of the Bile Blog, produced a book that was a suprisingly good read. It’s packed with a lot of knowledge and some interesting takes on EE concepts. Newer versions of JUnit also include many of these features and concepts, so you’ll get the underpinnings of these concepts in this book. This video gives you a basis to TestNG’s approach.

As one of the growing number of developers who have an application in the Seam In Production page, there are a few Seam resources I have to share. Even if you don’t get into Seam, it should be on your radar because a lot of the core concepts around conversations have evolved into Web Beans, and are found other frameworks like Apache Orchestra and Spring WebFlow. Pete Muir did a Webcast that’s a great introduction to Seam 2.

Author of one of my favorite Seam blogs, Jacob Orshalick, has created a DZone RefCard for Seam 2.1 Core. It’s right off the presses, being published this week, but is a great quick-capsule review of what Seam can do for you, and nice to have on your desk if you’re writing Seam. If you need more in-depth descriptions of what’s on the RefCard, Jacob also coauthored the latest edition of the great Seam reference Seam Framework: Experience the Evolution of Java EE.
Dan Allen’s Seam in Action is another excellent resource. Of course, the awesome Seam Docs and Forums always come in handy. You should also RSS in.relation.to – the Hibernate/Seam developers’ group blog.

I know I’m leaving some great things out. What resources do you think someone who is used to J2EE should take a look at to get them “up to speed” with the state of the art?

More Related Content

• January 31, 2009 -- In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel (3)
• March 19, 2008 -- New Wave Logging (0)
• June 9, 2009 -- Mocking with JMockit (5)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• February 17, 2009 -- Don’t Unit Test Anymore… No, Really! (6)
• January 13, 2009 -- On Software Quality (8)
• August 21, 2008 -- Weblogic 9.2 + Seam : Victory is Mine! (1)
• August 2, 2008 -- How I Escape the “Reuse Trap” (0)
• July 21, 2008 -- Pimp My Build (0)
• March 13, 2008 -- Continuous Integration Dissected (0)

Trying to run through a screencast I’m putting together after upgrading to Leopard, I noticed Maven giving me a strange error when trying to run archetype:generate and realized that Leopard includes its own version of Maven (and Ant) out of the box.  The problem is that it’s version 2.0.6, which doesn’t have support for this feature.  I then set about trying to upgrade Maven (and in the process, Java) and here is what I uncovered.

First of all, I screwed myself over a bit by customizing my /etc/profile under Tiger; there were changes to this file that came in with Leopard but I can’t see where the updater tried to merge them in at all.  There are changes in Leopard to how paths are configured using a script called /etc/path_helper, but I don’t have any of that getting executed.  It took me a while to figure out this was the reason my .profile, .bash_profile, etc weren’t getting source’d properly.  What I did was pull out all of my updates to /etc/profile and just add in the following:

So at least now I have my .profile getting loaded properly.  I’d still be interested to see someone’s /etc/profile that works out of the box with the call to /etc/path_helper, but this is all beside the point.

Applying the Java update was painless – it worked fine through the Apple Software Update utility.  You can download it here manually if you need to.

Next, you’ll probably notice that Java 6 isn’t enabled by default.  This blog will show you how to switch over to 6 using the Java Preferences utility.  There is a flaw in the ointment, though – for some reason it appears that it doesn’t switch over all of the symlinks properly.  Maven’s startup script gets confused by this in a few steps.  You can read more about it in this message (some JIRA comments) from their mailing list.  The workaround is to just point your JAVA_HOME directly to the 1.6/Home directory.

You can install the newer version of Maven at this point.  I saw this post detailing the instructions, but it was what I expected.  Just download the latest version and extract it to where you keep these kinds of things.  Then you just have to update your .profile (or .bash_profile) to set up some environmental variables for you.  Here’s what I included in my ~/.profile:

You’ll need to do source ~/.profile or exit out of your terminal and open it up again for the changes to take effect.  Once you do you can test to make sure you’re seeing the right version of Maven:

You can also check this by doing:

I guess we can chalk this one up to kicking the tires on Leopard. Hope this makes the process a little less painless for someone else!

More Related Content

• June 3, 2009 -- What is Hamcrest? (0)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• August 1, 2008 -- New Apple Wireless Keyboard (1)
• July 21, 2008 -- Pimp My Build (0)
• July 8, 2010 -- Transactions, Part 1 (0)
• January 7, 2010 -- Eliminate Branching (IF Statements) to Produce Better Code (0)
• July 29, 2009 -- What I’d Tell Myself About Design If I Were Just Beginning (5)
• July 24, 2009 -- The Elements of Reusable Code (0)
• June 9, 2009 -- Mocking with JMockit (5)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)

I couldn’t find any definitive answer to this question, so here’s what I found, just incase anyone else needs this little nugget of information: the runtime dependencies for an Axis2 client that uses Axis Data Binding (ADB):
activation.jar
axiom-api.jar
axiom-dom.jar
axiom-impl.jar
axis2-java2wsdl.jar
axis2-jaxws.jar
axis2-jaxws-api.jar
axis2-metadata.jar
axis2-saaj.jar
axis2-saaj-api.jar
backport-util-concurrent.jar
commons-codec.jar
commons-fileupload.jar
commons-httpclient.jar
neethi.jar
wsdl4j.jar
wstx-asl.jar
xml-resolver.jar
xmlbeans.jar

It’s long, I know – but not as long as what you find in $AXIS2_HOME/lib!

More Related Content

• June 3, 2009 -- What is Hamcrest? (0)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• November 19, 2008 -- Java 6 and Maven 2.0.9 on Leopard (7)
• July 21, 2008 -- Pimp My Build (0)
• March 19, 2008 -- New Wave Logging (0)