[ 
https://issues.apache.org/activemq/browse/CAMEL-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Willem Jiang reassigned CAMEL-1385:
-----------------------------------

    Assignee: Willem Jiang

> 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
>            Assignee: Willem Jiang
>             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.

Reply via email to