Packaging A Robot To A Jar from the Command Line?

Hiya,

Is it possible to package my robot from the command line? I see the RoboRumble participants page specifies that the bot needs to be in a jar with a botname.properties file, and the usual way to do this is via the package menu in the client. Is it possible to do this from the command line?

Is it as simple as running the standard "jar" command, passing in the source files (and the botname.properties file)?

Thanks!

It's definitely possible, but I haven't done it, besides manually unzipping / editing / rezipping sometimes. I think Beaming does it with normal development tho so maybe he can comment on his setup.

It is just a normal JAR with your class files + the .properties file. So whatever means you have of creating a JAR should work.

then ask beaming then

Why did you post this? It's impolite and not helpful.

i told Wolfman to ask Beaming

You can use Ant to package your jar, here is an example script (that I wrote) to do it. Since I mainly develop in eclipse I didn't want to switch over to Robocode to package my robot.

See the page Ant (tool).

I use standard make file which you are free to modify, see the EvBot source link to github.

Essentially, it does the following First compiles all relevant .java files to .class and move them to special folder 'out' for ease of the followin jaring.

javac -d $(OUTDIR) -classpath $(ROBOCODEJAR) YOU_JAVA_file.java

Next you need to modify YOUR_BOT.properties file. Change version variable accordingly and you need to generate new UUID and put in the file. I am not sure that robocode actually uses it, but this is fairly easy. I do it with a simple sed script. Put this new file into $(OUTDIR)/$(SUPERPACKADE)/YOUR_BOT.properties file. Here $(SUPERPACKADE) is your rumble author designation. For my case, $(SUPERPACKADE) is 'eem' and YOUR_BOT is EvBot

Next you need to jar all compiled files and the .properties file. Since we moved it all into $(OUTDIR) at previous steps, all you need is to run

cd $(OUTDIR); jar cvfM  ../NAME_OF_JARED_BOT.jar  `find $(SUPERPACKADE) -type f`

This is it. You are ready to upload the bot for rumble or to test it locally.

I would suggest to use my Makefile which comes with EvBot, it automates all of above, and does separate packaging of test and releases according to the git tags.

Let me know if you still have questions.

Awesome, two different things to try. Cheers Chase, Beaming. I'll probably try Beaming's method first because it doesn't rely on installing Ant.

FYI, i'm not sure I'll have time to do it (i'm expecting my first child in the next week! :o), but i'm planning on making a web interface for my Raspberry PI where I can upload my source files, and it auto-compiles the jar and runs RoboRunner, pasting results back to the website. A bit like RoboRumble but for personal use - so I can keep track of results of improvements of different versions for TCRM etc. And do genetic algorithm tuning of the bot, running it on my PI so I can leave it going for a week. :)

If you use Eclipse it comes with Ant. Ant is similar to Make in many ways, except it can interact with Java stuff on a deeper level (then Make can).

Happy expectations! Do not forget to report motion and targeting algorithms, and code size of your baby :)

You will also have no sleep in the next 3 months. Nevertheless, parenthood is fun and recommended activity to keep us all in sync with reality :)

I personally, attempted Ant a few times, but I do not understand its logic, and config is to wordy to be human generated. So old but proven to be good 'make' is my favorite. I never mastered these fancy IDEs as well. The best I saw was Borland C with v2.something, and than I never looked back at them.

I think Raspberry is quite low on CPU power, from other hand you will not be able to check it to often, so it might work.

Ant proposes to do the same thing Make does, but with XML syntax instead, which is more portable and more friendly to manual editing. XML is a lot more forgiving on indentation and blank spaces.

Ant has become the industry standard build tool for Java applications. With Maven and Gradle closely behind.

Despite my (slight) efforts, I still do not understand Maven. I really should read up on it some time.

Maven has a declarative approach to build scripts, in contrast to Ant which has an imperative approach.

Since most build scripts all end up doing the same thing, like deleting files from a previous build (clean), compiling source (compile) a packaging compiled files (package), Maven standardized these steps in a hard-coded life-cycle. Also, Maven has a programming-by-exception approach, with defaults for all configurations. What you basically do in Maven is reconfigure what you want different from the basic life-cycle, and Maven does the rest.

If you execute an "empty" Maven script with "mvn clean package" command line, it will:

- Delete "/target" directory (clean goal)

- Look for source files in "/src/main/java" directory, compile them and put compiled files in "/target/classes" directory (compile goal, which always runs before package goal, like depend in Ant)

- Package files in "/target/classes" and "/src/main/resources" directories and put them all in a .jar file, which is stored in "/target" directory. (package goal)

You can reconfigure all directories by increasing the build script. But an "empty" script with only the project name and a few other tags also work.

If you need to import other JARs, like robocode.jar, then you need to declare them as dependencies, one-by-one in the pom.xml file. These JARs are searched in a "<home>/.m2/repository" directory, which is called a local repository. If they are not there, they are downloaded from a remote repository. By default, Maven downloads from the public Apache repository on internet, but it can be reconfigured as well. If you declare a dependency, but this dependency also needs another dependency, Maven discovers them for you by analyzing all pom.xml files from all JARs and download them all (recursive dependency resolution).

If you execute the same "empty" script with "mvn clean install" it will perform all the steps above and:

- After packaging, it will copy the .JAR file into the local repository, which can be used as dependency in other builds. (install goal)

If you need another JAR as dependency, which was never built in Maven, it can also be put in a repository with the lengthy command: "mvn install:install-file -Dfile=<jar name> -Dversion=<some version> -DartifactId=<dependency name> -DgroupId=<dependency group name>"

If you omit the "clean" goal, then the build tries to reuse existing files from a previous build to shorten build time (like Ant does).

There are other goals, but those are the essential ones.

You should put this up on Stack Overflow. That said, not sure I will change my setup until such time that I need to configure a build that neither eclipse (by itself) or my already built ant files are sufficient to configure it.

I have to say, not too much of a fan of Ant personally. Comparing Makefiles and Ant XML I'd agree the XML is more portable, but I'd consider the Makefile to similar in terms of friendliness for manual editing. On one hand Make is annoyingly picky about certain whitespace, but on the other hand I find some of the boilerplate string repetition in XML to make things less human-readable, especially when not using a syntax highlighting text editor.

(Then again, part of my not being a fan of Ant may be on account of having seen Ant badly abused as a general-ish purpose scripting language. In other words... being forced to write certain kinds of scripting flow control in Ant XML can probably make someone start to dislike Ant...)

I only use it to package my robot. How do you do even do 'general flow control' in ant? The only ways I can think of are massively involved.

Maven tries to fight scripting logic abuse in Ant by hard-coding everything in a strict life-cycle, which is hard to customize. It still doesn't solve the problem though. There is a lot of room for plug-in abuse in Maven as well. But well behaved Maven scripts tend to be smaller than well behaved Ant scripts in general.

You do general flow control in Ant by using ant-contrib add-on. Ant becomes a Turing complete language with it.

For those who don't abuse the scripting language, don't abuse plug-ins and don't like XML, there is Gradle. Which is Turing complete like Ant + ant-contrib, have full support for Maven plug-ins and repositories, and uses Groovy/Java syntax instead of XML.

Ah, okay. Gradle sounds interesting. I always thought Ant would be better if I could just write a code to do everything it does, instead of using XML. As it would be easier to write and read (for me anyway).

Sounds cool, I'd be curious to see what you come up with! But yes, Raspberry Pi is very slow if you're planning on actually running battles there. BerryBots single-threaded runs 20x-30x faster on my 2009 MacBook Pro than on stock Raspberry Pi. Also, last I checked, Java is a huge headache on the Raspberry Pi, but maybe that's improved by now.

Good luck next week! :-)

I looked at getting it running on my PI a few months ago but the latest Raspbian distro has java pre-installed. I've not tried it yet but I imagine it will be fine. And yes I know the PI is really low powered, it will make up for it in the amount of time I can just leave it slowly churning away while I am out of the house. I don't like leaving my 500w desktop running while I'm not around. The PI uses about 5 watts of power, but I don't think its 100 times less powerful ...

Anyway, if you get one running, you can buy another 10 for less than a single desktop and have your own PI rumble server farm! ;)

But for the cost of 20, I got a quad-core Core i7 with 16 gigs of RAM. :-) So I can run 5-6 threads, each 20x faster than the Pi.

If you're curious, there was some talk on Raspberry Pi about some of the issues people hit, though who knows how much has changed in a year+.

But where would the fun be in having a single desktop when you can legitimately tell people you have a server farm in your front room? He he he! ;)

I've just had a spare hour to get it working. The latest Raspian distro includes java by default now! Hopefully see some results soon! :)