On 16/08/2011, at 5:46 PM, Andrew Lee Rubinger wrote:
On 08/16/2011 12:54 AM, Jason T. Greene wrote:
> The approach might catch a missing dependency, but it will not catch an
> unnecessary dependency. It seems that only human review can get the most
> accurate results. Alternatively, it might be more correct to actually
> write real API verification tests, that does something like look for an
> expected list of packages, and erroring when an unexpected package is
> found (or a missing one).
I think about this all the time. Unfortunately, you can't catch a leaked API unless
you test for all possible leaks. If anyone's got a fine idea how to deal with this,
I'm all ears.
If you have a list of allowed dependencies, it should be fairly trivial to write a maven
plugin that verifies that only the dependencies on the list are exported from the API (and
that every dependency on the list is present).
Stuart
WRT using the testsuite as a verification mechanism to validate the completeness of the
API, yes, it's a convenience mechanism. But in this case, convenience is likely to
equal correctness over time (implicit maintenance). Take the case of @SecurityDomain or
JavaMail, both missing from the Spec-API and API. If we didn't remember to export it,
we definitely weren't going to remember to test that it was exported. :) Only when we
added tests for EJB3 security or something that used javax.mail did we catch it (after I
moved to a restricted dependency chain).
S,
ALR
--
Andrew Lee Rubinger
Senior Software Engineer
JBoss by Red Hat
Twitter: @ALRubinger
http://about.me/alrubinger