Documentation for creating build.xml files in RL-Library?

[W Bradley Knox]

Hi Brian,

I hope all goes well. It's too bad we couldn't meet last year at
Barbados. Maybe IJCAI or AAMAS this coming year?

I'm porting all of my TAMER code over to Java, and I'm having some
trouble with runtime errors; the JVM isn't able to find classes in my
weka.jar file that were found just fine during compilation. I believe
it has something to do with the classpath set in the build.xml file,
though I'm relatively inexperienced with ant. Do you have any
documentation on how to create a build.xml file that uses the xml
files in system/common/ant/? Or more specifically, how do I add
something to the classpath? Looking at the build.xml file for
MountainCar-Java-xxx (which I adapted for my own agent), it seems that
it's not as straightforward as in a standalone build.xml file, instead
requiring use of project.extra.classpath.

Thanks, and I appreciate any help you can give.

Cheers,
Brad
www.cs.utexas.edu/~bradknox

[Brian Tanner]

Hey Brad.  Yes, I admit getting things to work with RL-Viz dynamic loading and external class paths is a wee bit tricky.

I have not solved this problem personally in some time, but there are examples of how to do it.  When plucking your agent from a jar and looking up its dependencies, Java will load load classes automatically.  IE: there is no way to fix this by just calling RL-Viz with the right parameters or classpath settings.

Instead, if I recall, you need to ensure that the manifest for your agent's jar states its dependencies and their relative locations.  OR, maybe the trick is to totally unpack the jars and put all of their classes into your main JAR.  I forget exactly how the build script I wrote does this.  Let's find out.  To the examples!

Here is a build script for my bt-agentlib which I believe depends on something:

http://code.google.com/p/bt-agentlib/source/browse/trunk/build.xml

Alright in this case it looks like we get JAMA (a Java Matrix package) into place by actually unpacking it into our classes directory.  The build target "public-agents" then rebuilds my project JAR with all of the classes.  This isn't needed in general I don't think, I just do it because I have public and private builds of my project that either show all my experimental/research agents or just the public facing ones.  Lets cross reference with another example...

Octopus from the competition needed a Base64 encoding of the internally drawn GUI bitmap which was then sent to the visualizer to draw.  So we need an external jar there...

http://code.google.com/p/rl-competition/source/browse/trunk/2009/private/environments-3.0/octopus/build.xml

This is a simpler example, similar fix: (1) Add the jar into the project.extra.classpath and (2) unzip the jar into the classes directory while building.  Feels odd that it needs both. Hmph.  I think perhaps (1) is for building and (2) is for runtime lookup.  That makes sense.

Oooh... confirmation.  Glad to see I had some common sense one day and documented things a bit. Basically it confirms what I said.

http://code.google.com/p/rl-library/source/browse/trunk/system/common/ant/sample-build.xml

Let me know how it goes.  This is a very engaging distraction to what I am and don't want to be doing at the moment.

--
You received this message because you are subscribed to the Google Groups "rl-library" group.
To post to this group, send email to rl-li...@googlegroups.com.
To unsubscribe from this group, send email to rl-library+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rl-library?hl=en.

--

Brian Tanner

PhD Student, University of Alberta

br...@tannerpages.com

[W Bradley Knox]

Thanks for distracting yourself with my needs. :)

As of now, ant can find weka.jar during the build process, presumably
because it's in my CLASSPATH environment variable. When I try to do
what my interpretation of your sample-build.xml suggests, I get a new
runtime error that seems to come from not being able to find
RLVizLib.jar. The build.xml that seems incorrect but gets an earlier
error than the seemingly incorrect one contains:

<property name="jar.main.class"
value="edu.utexas.cs.tamer.agents.TamerAgent" />
<property name="jar.extra.classpath"
value="../system/common/libs/rl-viz/RLVizLib.jar" />
<path id="project.extra.classpath">
<fileset dir=".." >
<include name="weka.jar"/>
</fileset>
</path>

And the modified one that gets the earlier error contains the
following, changed only by adding another jar file after RLVizLib.jar:

<property name="jar.main.class"
value="edu.utexas.cs.tamer.agents.TamerAgent" />
<property name="jar.extra.classpath"
value="../system/common/libs/rl-viz/RLVizLib.jar:../tamerCommon/weka.jar"
/>
<path id="project.extra.classpath">
<fileset dir=".." >
<include name="weka.jar"/>
</fileset>
</path>

The actual runtime error begins with:

Exception in thread "main" java.lang.NoClassDefFoundError:
org/rlcommunity/rlglue/codec/AgentInterface

Does something jump out at you here?

Thanks again.

- Brad

[Brian Tanner]

I couldn't completely parse your explanation of the errors.

However, I think the first example is closer to what you want. I'm
unfortunately not a JAR or Ant expert (especially not anymore), but I
have been peeking at where these values are used:
http://code.google.com/p/rl-library/source/browse/trunk/system/common/ant/build-targets.xml

Looks like jar.extra.classpath is (intuitively), the classpath for the
jar in the manifest. Two things. First, it is not totally obvious
what the format of a classpath with multiple entries should be. Doing
some reading it looks like maybe there is no classpath separator...
just a space? Some info here:
http://download.oracle.com/javase/tutorial/deployment/jar/downman.html

You can probably take RLVizLib OUT of there for now if you want to,
and just use your WEKA jar to see if that works. The reason (if I
recall) that RLVizLib is there is simply for command-line loading, so
you can do java -jar myJar.jar to start your agent. Invoking this way
means that your agent's jar must have RLVizLib in the classpath so it
knows about AgentLoader at runtime. If you load your agent out of the
JAR from RLViz, then this isn't required (probably).

project.extra.classpath is used for compiling. So that's probably all fine.

So that gives you a direction to pursue I think.

The other way to proceed would be to leave jar.extra.classpath at its
default, and then comment out the include for the predefined build
targets, and just paste the build targets from the Octopus and
changing the jarname to your weka, so something like:
!-- <import file="${this.project.system.directory}/common/ant/predefined-target-aliases.xml"/>-->
<target name="build">
<unzip src="weka.jar" dest="build/classes/"/>
<antcall target="rl-jar" />
</target>

<target name="clean" depends="rl-clean"/>

<target name="debug" depends="rl-set-debug,build"/>
<target name="test" depends="rl-test"/>
<target name="javadoc" depends="rl-javadoc"/>
<target name="clean-build" depends="clean, build"/>
<target name="all" depends="clean, build, test, javadoc"/>
<target name="update-public" depends="build" >
<copy file="${result.jar}"
todir="${baseLibraryDir}/../public/system/environmentJars"/>
</target>

--
Brian Tanner
Ph.D Student
University of Alberta
br...@tannerpages.com

[Brian Tanner]

Except the last target "update-public" is not necessary.

[W Bradley Knox]

Changing the ":" to a space fixed it. You're my hero. Strangely, I'd
thought about that but the following website says to use ":" or ";":
http://ant.apache.org/manual/using.html. Maybe I misread it. Either
way, thanks. I guess this was more of an ant issue than an RL-Library
and ant issue, so thanks all the more.

- Brad

[W Bradley Knox]

Oh, and the reason you couldn't parse my explanation of the error is
that my editing of the email before sending rendered it nonsensical,
claiming that both versions were the bad ones. Sorry about that.

[W Bradley Knox]

Shoot. I've got another issue that is probably better to deal with
now. I really hope it's specific to RL-Library. When I get a runtime
error, the stack trace has no line numbers for my code, like this:

AgentLoader run(class edu.utexas.cs.tamer.agents.TamerAgent) threw
Exception: java.lang.NullPointerException
java.lang.NullPointerException
at edu.utexas.cs.tamer.agents.TamerAgent.processLastTimeStep(Unknown Source)
at edu.utexas.cs.tamer.agents.TamerAgent.agent_step(Unknown Source)
at edu.utexas.cs.tamer.agents.TamerAgent.agent_start(Unknown Source)
at org.rlcommunity.rlglue.codec.network.ClientAgent.onAgentStart(ClientAgent.java:75)
at org.rlcommunity.rlglue.codec.network.ClientAgent.runAgentEventLoop(ClientAgent.java:193)
at org.rlcommunity.rlglue.codec.util.AgentLoader.run(AgentLoader.java:128)
at edu.utexas.cs.tamer.agents.TamerAgent.main(Unknown Source)

According to my interpretation of at least two websites (e.g.,
http://www.jguru.com/faq/view.jsp?EID=1122360), the solution should be
to add

debug="true" debuglevel="lines,vars,source"

to the last of the following lines in build-targets.xml:

<target name="rl-compile">
<mkdir dir="${classes.dir}"/>
<!-- make sure we get the resources -->
<copy todir="${classes.dir}">
<fileset dir="${src.dir}" excludes="**/*.java"/>
</copy>
<javac srcdir="${src.dir}" destdir="${classes.dir}"
debug="${build.debug}" target="1.5">

Doing so (or rather, only adding the debuglevel part that's missing)
does not fix the issue. There are still no line numbers for my source
in the error's stack trace.

Might I be putting this debug parameters in the wrong place? Or are
you aware of something else I should be doing differently?

- Brad

[Brian Tanner]

Ack.

Well first off I'm not quite sure. I have run into similar issues
before. I'm trying to remember if the problem is you need debug mode
enabled in the Agent, or in RL-Viz, or both.

For the agent, you could test this by putting a runtime error in a
test class in your code and then invoking that code from outside of
RL-Viz just to make sure line numbers come up. You could even toggle
the debug thing to see if you can control it. Probably that'll work
fine and we'll need to look at RL-Viz.

For some reason I always compile RL-Viz without debug mode on. This
has bit me a few times and I've recompiled a special version of it
with debug mode on, solved a problem, then disabled debug mode.
Today, this seems stupid. Why not just have it on? Perhaps there is
a good reason that I cannot recall.

Looks like RLVizApp/VizLib/AgentShell/EnvShell have a debug target
called "debug-all":
http://code.google.com/p/rl-viz/source/browse/trunk/build.xml

It gets used here, similarly to what you are doing in your snippet:
http://code.google.com/p/rl-viz/source/browse/trunk/projects/rlVizLibJava/build.xml

Except I use: <property name="build.debug" value="on"/> while you use
"true". Try "on" and see if life is good. If not, perhaps I should
just push out a version of RLVizLib with debug on and make that the
default. Please tell me if you can think of why that might be bad.
Random Internet search says "debugging mode" is up to 10x slower than
without, but I don't necessarily think that's just having the debug
symbols not stripped. Not sure.

Anyway, digest this and let me know :)

[W Bradley Knox]

I tried your suggestions and was about to throw up my hands when I
realized that there is a verbose option for ant. From the verbose
output, I figured out that build.debug wasn't set in
build-targets.xml. Changing

<target name="rl-compile">

to

<target name="rl-compile" depends="rl-set-debug">

added line numbers to the error stack trace.

Thanks again for your help.