ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Topping" <>
Subject RE: Ant Classpath -- Help Requested
Date Wed, 22 Aug 2001 20:55:06 GMT
Hi Connor,

Thanks for the info.  I've done both of those in the past, but went back
to working with 1.3 because I figured that the 1.4 source base might not
be as well understood by people.  I'll flip back over though, seems that
any changes that need to be made will be there anyway, so it makes
better sense.  

I saw all the classes being loaded in the beginning but didn't
understand precisely what was going on.  Is that the transitive closure
of all the classes that need to be loaded for the entire session?  In
other words, is Ant loading all of the classes it needs before executing
anything in the Antfile?  

While I've got your attention, if you know of any primers that I could
use to get up to speed faster on how Ant works (outside learning the
main source tree and appropriate modules), a reference would be great.
I'm assuming that there isn't one, but I thought that I would ask.

Thanks for your consideration, 


p.s.  I'm traveling right now, so I'm a little slower than normal in
getting back to my emails... -b

-----Original Message-----
From: Conor MacNeill []
Sent: Monday, August 20, 2001 8:09 PM
Subject: RE: Ant Classpath -- Help Requested


First, please try this under 1.4 Beta. I have made some changes to Ant's
classloading with respect to <taskdef> which may have an impact. The
step is to run ant -debug. You will see Ant's classloader spewing out a
whole stack of messages about where it is loading classes. Finally, or
firstly, check whether org/enhydra/error/ChainedException is in the
classpath you have defined.


> -----Original Message-----
> From: Brian Topping []
> Sent: Tuesday, 21 August 2001 3:44 AM
> To:
> Subject: Ant Classpath -- Help Requested
> Greetings and salutations,
> I first sent this to the Ant-user list, but got no response so I
> I would try here.  It is rather technical in nature, so maybe I should
> have started here, but I was saving this list for a last resort.
> I'm trying to get Ant working with an external taskdef, but without
> configuring the CLASSPATH of the Ant itself.  So I've added the
> following to my build.xml:
> 	<property name="enhydra.root" value="C:/eas4/lutris-eas4"/>
> 	<property name="enhydra.output" value="C:/eas4/lutris-eas4"/>
> 	<property name="enhydra.liboutput"
> value="C:/eas4/lutris-eas4/lib"/>
> 	<property name="enhydra.jdkdir" value="C:/jdk1.3.1"/>
> 	<path id="xmlc.classpath">
> 		<fileset dir="${enhydra.liboutput}">
> 			<include name="build.jar"/>
> 			<include name="boot.jar"/>
> 			<include name="kernel.jar"/>
> 			<include name="xmlc.jar"/>
> 			<include name="wireless.jar"/>
> 			<include name="LutrisWireless.jar"/>
> 			<include name="dods.jar"/>
> 			<include name="ctxrmic.jar"/>
> 		</fileset>
> 		<fileset dir="${enhydra.jdkdir}/lib">
> 			<include name="tools.jar"/>
> 		</fileset>
> 	</path>
> 	<taskdef name="xmlc" classname="org.enhydra.ant.taskdefs.Xmlc"
> 		classpathref="xmlc.classpath"/>
> Did I set this up correctly?  I am trying to get the CLASSPATH that is
> set up for both Ant (when it executes taskdef
> org.enhydra.ant.taskdefs.Xmlc) and org.enhydra.ant.taskdefs.Xmlc
> (it has a bunch of libraries that it needs to be successful).  What I
> get when I run it with 1.3 is:
> java.lang.NoClassDefFoundError:
> org/enhydra/error/ChainedException
>         at
> va:439)
>         at
>         at
>         at
>         at java.lang.ClassLoader.loadClass(
>         at
>         at
>         at org.enhydra.xml.xmlc.commands.xmlc.XMLC.main(
>         at java.lang.reflect.Method.invoke(Native Method)
>         at org.enhydra.ant.taskdefs.Xmlc.execute(
>         at
>         at
>         at
>         at
>         at
>         at
> java.lang.reflect.InvocationTargetException:
> java.lang.NoClassDefFoundError: org/enhydra/xml/xmlc/XMLCException
>         at
>         at org.enhydra.xml.xmlc.commands.xmlc.XMLC.main(
>         at java.lang.reflect.Method.invoke(Native Method)
>         at org.enhydra.ant.taskdefs.Xmlc.execute(
>         at
>         at
>         at
>         at
>         at
>         at
> Everything seems to be working fine up to
> org.enhydra.ant.taskdefs.Xmlc.execute( (line 549 is
> highlighted):
>         } else {
>           String [] _args = (String[])args.toArray(new
> String[args.size()]);
>           // Execute XMLC directly.  This requires that enhydra.jar,
> an equivalent
>           // path containing the needed DOM code is on the CLASSPATH
> ANT.
>           String xmlcClassName =
> "org.enhydra.xml.xmlc.commands.xmlc.XMLC";
>           Method      m = null;
>           Class       c = null;
>           try {
>               c = Class.forName(xmlcClassName);
>               m = c.getMethod("main", new Class[] { String[].class });
>           } catch(Exception e) {
>               // Reflection errors.  Class or method does not exist!
>               e.printStackTrace();
>               throw new BuildException(e);
>           }
>           if (m != null) {
> 549->              m.invoke(null,new Object[] { _args });
>           }
>         }
>       } catch(InvocationTargetException ite) {
>         ite.printStackTrace();
>         throw new BuildException(ite);
> Basic reflection code, right?  The class is found and the method call
> works.  But the comments at the top of this block state that the
> relevant JAR files must be already on the Ant CLASSPATH.  Problem is,
> cannot do that, I am trying to run this build in NetBeans/Forte 3.x
> there is a confirmed problem with the library compatibility between
> Enhydra and NB.  I believe I need to use the classpath attribute in
> Antfile taskdef in order to get around this NB library problem.
> Moving up the call chain, the source of the real error is in
> line 49, and it is failing to instantiate a class that exists in the
> same package and jar file as the caller itself!  So somehow it seems
> that the CLASSPATH is initially getting set up correctly by the code
> the build.xml, but it is not surviving the reflection call through the
> method interface since the first instantiation of another object from
> that JAR is failing.  *THIS* is the problem I am trying to solve.  How
> can I make the CLASSPATH that is getting set up in the Build.xml
> "sticky"??!??!!?
> I hope this all makes some semblance of sense to someone that can
> tips toward a solution.  I've beat on this nonstop for a solid day and
> have come up with a little over nothing...
> Thanks very kindly for your consideration,
> Brian Topping

View raw message