camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan (JIRA)" <j...@apache.org>
Subject [jira] Created: (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 Thu, 26 Feb 2009 08:30:00 GMT
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.


Mime
View raw message