Well spotted, I spoke to Peter Kriens over the phone about this in 2010
(very smart guy btw), ClassDep doesn't detect Class.forName dependencies.
A string might not be defined until runtime, so it's not something that
can be easily determined. This could become even more difficult if
dynamic languages like Groovy are used in the proxy.
Another alternative might be to prefer everything resolvable by the
proxy codebase string annotation at runtime. It would be up to the
developer to ensure that proxy classses are packaged correctly,
annotations could go some way to automating this for the developer. The
developer could include any library jars required in their codebase string.
Perhaps a classloader called ProxyPreferredClassLoader might be created
for such a purpose.
@ServiceAPI - dependency tree excluded from proxy codebase.
@SmartProxy - root class for dependency search, to determine classes to
be included in proxy jar file.
Consideration has to be given to felixibility for developers using
Maven, OSGi and dynamic languages.
Peter.
Could work for anything other than cases where someone makes liberal use of
dynamic class loading via Class.forName and similar. So let's say I have a
smart proxy that has some dynamically assembled bits, the references will
be in String form making bytecode analysis difficult.
I wouldn't say this is likely a common case, more something that would have
to be noted as a limitation of the tool so developers are not caught out.
