Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
None
-
None
-
None
Description
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
${project.build.directory}/classes/META-INF/maven/dependencies.properties
to be
${project.build.directory}/classes/META-INF/maven/org/apache/camel/jms/dependencies.properties
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)....
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, ....
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?).
Attachments
Issue Links
- is depended upon by
-
-
- Resolved
-