Christian Pesch wrote:
Actually, they were in the archive. And I can reproduce the error
doclet.XDocletException: The class org.metamusic.core.impl.conversion.Role2VarcharFieldConversion hasn't been found on the classpath while checking the conversion class specified for field role in class org.metamusic.core.impl.ContributionImpl
The class is there:
[EMAIL PROTECTED] ojb-blank]$ ll src/java/org/metamusic/core/impl/conversion/Role2VarcharFieldConversion.java
-rw-r--r-- 1 cpesch staff 1144 18. M�r 12:43 src/java/org/metamusic/core/impl/conversion/Role2VarcharFieldConversion.java
And contains valid package and type names:
package org.metamusic.core.impl.conversion; import org.apache.ojb.broker.accesslayer.conversions.FieldConversion; public class Role2VarcharFieldConversion implements FieldConversion { ... }
Strange, isn't it?
Strange that I didn't see them. Anyway, its not strange that the XDoclet module produces this error. The problem here is that the module can only check used classes (e.g. conversions, row readers etc.) as classes, not as source. Therefore, they have to be available in the classpath used to run the XDoclet module. Usually you would include your build directory in the ant classpath that you use to define the ojbdoclet task. As a last resort, you can turn the checks of these class off, see the module doc at http://db.apache.org/ojb/docu/guides/xdoclet-module.html#Usage .
But you're right, this is currently not done in the ojb-blank project. I'll fix that ASAP. The fix should be a simple change of the compile-classpath at the beginning of the build.xml of the ojb-blank project to:
<path id="compile-classpath">
<fileset dir="${build.lib.dir}">
<include name="**/*.jar"/>
</fileset>
<pathelement path="${build.classes.dir}"/>
</path>Tom
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
