I use Ant for all of my commercial Java developments and have just started to use it within the development of by Bots. (It may be a bit of an overkill as the Robocode projects don't tend to be that big but it is a useful skill/tool to have on your CV)
I have an Ant "Build" file that performs the following tasks for me during the development of my Bots:
-- Hexkid
/SampleBuildFile2 (David Alves)
Packing a minimal JAR
My codesize would be a lot smaller if I could figure out how to have Ant automatically include only required files, but right now it's just including *.class. Does anyone know how to tell Ant to only include files needed by YALT.class? --David Alves
Not really, but maybe you can check how the Robocode packager does it? -- PEZ
Built-in Robocode packager includes only needed classes. --Ph
@Ph, I know, but is there a way I can get Ant to do it? I want to automate everything. :-) --David Alves
I think there is no simple way to tell Ant compile only classes needed by some class. AFAIK in each .class file there are references to other classes needed by this class, so you can scan each .class file for these references. But it is complicated, because you have to know how a class file is built, and find some way to plug-in that into Ant. I am not an expert and do not use Ant very often, so maybe someone can find better solution. --Ph
Maybe Ant has some way to reach the reflection API? -- PEZ
Years later, I answered my own question: [these people] have made an Ant task that packages only the minimal set of files. --David Alves
Escape Characters in robot.description files
I have been using Ant build-files for some time now, but still have one (simple?) problem. I want to enter a description for the robot-properties file like:
<entry key="robot.description" value="text 1\n text 2\n text 3"/>so i get three lines of text in my description. But when i select my bot in the "new battle"-popup, instead i get one line in the description field that is too long to show completely. Any ideas how to get multiple lines? Thanks --Loki
Well i didnt try, but maybe using \\n instead of \n in your ant-file could help. --Mue
If you do that, Mue, you get \n instead of a line break. Looking at existent .properties files \n should work. -- Jonathan
sorry folks, i should have described the results of the properties file as well; i get a \\n in the description field, like:
robot.description=text 1\\n text 2\\n text 3Every "\" in the description is escaped... --Loki
Ant files are XML, so try H That's the UTF-8 character code for a slash. --David Alves
I have Googled a solution: include the following <replaceregexp> Ant-task after the definition of the properties-file, like:
<propertyfile file="${ROBOTNAME}.properties"> <entry key="robot.description" value="this line is to long to show in the description field,\n so i need a newline character."/> <entry key="robot.java.source.included" value="true"/> <entry key="robocode.version" value="1.0.6"/> <entry key="robot.version" value="0.1"/> <entry key="robot.author.name" value=""/> <entry key="robot.classname" value="${package}.${ROBOTNAME}"/> </propertyfile> <replaceregexp file="${ROBOTNAME}.properties" match="\\n+" replace="\n" flags="g" byline="false"/>The <replaceregexp> task is a "directory based task for replacing the occurrence of a given regular expression with a substitution pattern in a selected file or set of files."
Loki: Did you include the semicolon? It works for me. Entities in XML need to be terminated with a semicolon, like so: H --David Alves
sorry, i misunderstood the ";" as a "." as your next sentence started with a capital letter. I added the semicolon. This results in a capital "H"... --Loki
You probably have some other encoding than David has? -- PEZ
Loki, I think your solution is beautiful. It must obviously be a bug in Ant that it writes an escaped backslash for you without you asking for it. Then you go in and correct the effects of the bug. Clean and clear. Why David's solution works I don't know. The backslash character itself or it's entity reference should be equal in XML. But a bug is a bug I guess. =) -- PEZ
thanks PEZ. Regular expressions are powerful, once you get to know he syntax. But i do prefer 'first time right'. --Loki
Reggexps are truly powerfil. Though in this case regular expressions aren't showing their power. The task could just as well had been solved with a simple, non-regexp, search-and-replace. Had there been such a task builtin of course. -- PEZ
Ah oops, you're right, should be \ not H. This is ISO 8859-1, not UTF-8. Although you could force it to be UTF-8 by using
<?xml version="1.0" encoding="utf-8" ?>--David Alves
Ok, checked both H with UTF-8 encoding and \ without the encoding specification (which default to ISO 8859-1): on my (Windows) machine only the latter works. So the result of this session is that we have two working solutions. Thanks all! --Loki
BTW. I think your regexp breaks if you have a string like "dada, dada, dada\\nnana, nana". Remove that + in the match expression and it should be safer. -- PEZ