allow the (transitive) maven dependencies on a module to be displayed in the
runtime when we fail to load a component/language/converter
----------------------------------------------------------------------------------------------------------------------------------------
Key: CAMEL-1385
URL: https://issues.apache.org/activemq/browse/CAMEL-1385
Project: Apache Camel
Issue Type: Improvement
Reporter: James Strachan
Fix For: 2.1.0
It can be frustrating seeing lots of stack traces with random
ClassNotFoundException. Its also pretty hard to know what jars are required for
any component. While folks using Maven don't always have this issue - folks who
slap jars into a WEB-INF/lib directory or use Ant - frequently miss jars from
the classpath.
When we try to load a class for a component, language, converter (or any other
auto-discovery mechanisms we have) we should know the 'camel module' and
therefore the dependencies it requires. e.g. if resolving the "jms" component
we should know its "camel-jms" doing the lookup. Then we can look in some
canonical place for the list of jar dependencies (groupId/artifactId/version)
which camel-jms requires and then inform the user of the dependencies it
requires. e.g. we look for org.apache.camel.jms.dependencies.properties on the
classpath and use that to list the actual compile time dependencies (generated
at build time from maven).
FWIW there's a maven plugin I hacked for servicemix which does something kinda
similar - dumping maven dependencies into a properties file (so you don't need
to depend on some maven library stuff to be able to easily grok what your
dependencies are).
http://svn.apache.org/repos/asf/servicemix/maven-plugins/depends-maven-plugin/trunk/
which generates a dependencies file
http://svn.apache.org/repos/asf/servicemix/maven-plugins/depends-maven-plugin/trunk/src/main/java/org/apache/servicemix/tooling/depends/GenerateDependsFileMojo.java
So I'm thinking we should put a dependencies file in the package that the
component/language/converters are defined in - then that single file can be
looked up by any code and shared across component/language/converter discovery.
So we could reuse the same plugin - but just overload the output file to change
from
{code}
${project.build.directory}/classes/META-INF/maven/dependencies.properties
{code}
to be
{code}
${project.build.directory}/classes/META-INF/maven/org/apache/camel/jms/dependencies.properties
{code}
e.g. put a file org.apache.camel.jms.dependencies.properties on the classpath;
then when loading a component/language/converter class in that package, we look
for the dependencies properties file (and maybe keep walking up the package
hierarchy until we find one).
Then whenever we try to load a component/language/converter (or indeed do any
String -> class conversion) we can discover the available
$package/dependencies.properties files and use that information to produce
useful warnings about missing classes etc.
It'd be awesome if we could list the actual *missing* library :).
e.g. if you try and use "activemq" component and stuff is missing on the
classpath (and we seem to see something like this alot on the forums etc)....
{code}
WARN: Camel tried to load the 'activemq' component defined in
org.apache.activemq:activemq-camel:5.3.0 but you were missing the following
jars from your classpath org.apache.geronimo.specs:jta.jar:1.234, ....
{code}
However even if we just had a way to list the dependencies we expect and the
user could do the diff themselves it'd be really helpful. (I wonder if we can
figure out if a jar is present on the classpath based on a
groupId/artifactId/version? - maybe looking internally for the pom.xml that
Maven shoves in META-INF?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
