camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] Resolved: (CAMEL-1385) allow the (transitive) maven dependencies on a module to be displayed in the runtime when we fail to load a component/language/converter
Date Fri, 31 Dec 2010 14:09:46 GMT


Claus Ibsen resolved CAMEL-1385.

       Resolution: Won't Fix
    Fix Version/s:     (was: Future)

Apache Karaf and OSGi is using features to install all what you need.

> 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:
>             Project: Camel
>          Issue Type: Improvement
>            Reporter: james strachan
>            Assignee: Willem Jiang
>             Fix For: 2.6.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 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).
> which generates a dependencies file
> 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
> So we could reuse the same plugin - but just overload the output file to change from
> {code}
> ${}/classes/META-INF/maven/
> {code}
> to be
> {code}
> ${}/classes/META-INF/maven/org/apache/camel/jms/
> {code}
> e.g. put a file 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/ 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.

View raw message