Community
Participate
Eclipse IDE
I can't seem to find examples of people using XDoclet using the built in facilities in eclipse. Namely specifing the XDoclet tasks in the preferences dialog instead of writing task defs. Whenever I do this I get the following error with XDoclet 1.2. I have put in all the jars in the lib directory from XDoclet. Buildfile: C:\Program Files\Eclipse\workspace\JBossProject\build.xml BUILD FAILED: file:C:/Program Files/Eclipse/workspace/JBossProject/build.xml:23: Can't create a ejbdoclet element under {2}. Make sure the jar file containing the corresponding subtask class is on the classpath specified in the <taskdef> that defined {2}. I am not using 1.1 because my project path has a space in it and I get. [ejbdoclet] Javadoc execution [ejbdoclet] javadoc: Illegal package name: "C:\Program" [ejbdoclet] 2 errors [ejbdoclet] javadoc: File not found: "Files\Eclipse\workspace\JBossProject\src\net\trajano\umi\beans\NamedElem entBean.java" [ejbdoclet] BUILD FAILED: file:C:/Program Files/Eclipse/workspace/JBossProject/build.xml:21: Javadoc returned 1
Created attachment 4757 [details] Build.xml with the taskdefs
The ejbdoclet task creates a whole bunch of subtasks. To correctly load these subtasks, the ejbdoclet task needs to have the correct classpath. I don't fully understand why the Ant runtime classpath does not allow the correct loading of the subtasks but this is pretty low priority.
I have a very similar issue that I have resolved, so I'm noting it in this bug. I was trying to use XDoclet support and I had defined a path entry for the XDoclet JARs in my build.xml <i>as well as</i> in my Ant runtime classpath via the preferences dialog. On the suggestion of Darin I removed the JARs from my Ant runtime classpath preferences and the build worked. I tried the converse, commenting out the classpath in my build file and adding the JARs in my Ant runtime prefs, but that did not work. To summarize: to get XDoclet working I have to use a classpath element in my build file to include the XDoclet JARs, not the Ant runtime classpath preferences.
Thanks. I have some very preliminary results here, but I see two major differences in behavior: 1. With the XDoclet JARs in the Ant runtime classpath the class loader for xdoclet.modules.hibernate.HibernateDocletTask is org.eclipse.ant.internal.core.AntClassLoader The classpath then gets set to the return value of System.getProperty("java.class.path") (xdoclet.loader.ModuleFinder, line 98). This classpath (in my case) is simply "C:\\Program Files\\eclipse\startup.jar" Which does not hold the xml module documents that XDoclet needs to define the hibernate subtask, which is what the build error says in not so much detail. 2. Without the XDoclet JARs in the Ant runtime classpath the class loader for xdoclet.modules.hibernate.HibernateDocletTask is org.apache.tools.ant.AntClassLoader The classpath then gets set to the classpath for that loader (which is correct, and contains the xml mapping docs). The immediate problem is that the eclipse AntClassLoader is not actually a subclass of the real Ant ClassLoader, so the xdoclet code throws a ClassCastException. As far as I can tell, they both extend java.lang.ClassLoader somewhere down the line, but I'm not sure what the specific requirements are for XDoclet specifically asking for an org.apache.tools.AntClassLoader.
Thanks for the info Derek. The XDoclet code does a hard cast to org.apache.tools.AntClassLoader? Or is it that the ClassCastException is not from the classloaders but from some xdoc classes being cast to each other that are loaded by the different classloaders? Just guessing...
Definitely doing a hard cast. Here is the offending code from xdoclet.loader.ModuleFinder, lines 93-100: if (System.getProperty("xdoclet.class.path") == null) { try { classpath = ((AntClassLoader) clazz.getClassLoader()).getClasspath(); } catch (ClassCastException e) { classpath = System.getProperty("java.class.path"); } } I think the reason they do it is that the base java.lang.ClassLoader doesn't have an accessor for the classpath.
So it looks to me like the good path for the Eclipse integration is to recommend that the user set the magic "xdoclet.class.path" property and not rely on using AntClassloader. The java.class.path for the Eclipse Ant classloader when in the same VM as Eclipse will always be the root directory of the Eclipse install. Ant in a separate VM which is support in 3.0 M3 and on, you can set the working directory to be whatever you desire and defaults to the parent folder of the Ant build file. I am going to reopen so that we can address this in readme / known issues.
Either that, or just use the classpath attributes inside your buildfile. Originally I tried using the Ant runtime classpath as a way to avoid writing the <path> elements in my build file, but on second thought I think it makes more sense from the Ant perspective to require explicit classpaths inside the build.
I agree...you should not have to guess what is occurring while you are reading the buildfile. And it is much less error prone :-)
Added to the Ant readme.
Please verify DarinW.
Verified
Hi, I have this problem also. Could you please provide a sample build.xml entry to fix this? Kind regards, Daniel
