Well, because the life is not always easy...
The good news is that most issues listed in this document are already solved in jMoby, and they are here just to remember them, and to advise how to go around them.
<java classname="MosesGenerators" taskname="Service(s)"
classpathref="moses.build.classpath" fork="true" failonerror="true">
<arg value="-e"/>
<arg value="${default.endpoint}"/>
<arg value="-uri"/>
<arg value="${default.namespace}"/>
</java>
When the property ${default.endpoint} is not defined, Ant
will use a default value, which is an empty string, defined in the
same Ant as:
This works fine under Linux: the invoked program gets four arguments (I have labeled them by numbers, and put them in single quotes - but neither numbers nor quotes are parts of the arguments):<property name="default.endpoint" value=""/>
Unfortunately, under Windows the arguments (2) and (4) disappear, and the invoked program gets this:(1) '-e' (2) '' (3) -uri (4) ''
I asked Ant forum why it is like that - and the answer was simply "this is how Windows command processor does it". Which is fine with me - if Ant - which claims to hide platform dependencies - solves it. But it does not.(1) '-e' (2) -uri
Therefore, in jMoby, I have introduced a new convention (which I had to teach my programs): when an argument contains only two double quotes it is considered empty. So, now, in Ant, an empty default value is defined like this:
On Windows, it produces correctly empty arguments:<property name="default.endpoint" value=""""/> <property name="default.namespace" value=""""/>
On Linux, my programs need to understand arguments like this:(1) '-e' (2) '' (3) -uri (4) ''
It was easy to fix, because all jMoby command-line programs uses a simple command-line reader (a utility class) org.tulsoft.tools.BaseCmdLine which I updated to replace two double quotes by an empty string. But keep this in mind if your programs uses a different command-line reader (such as Apache CLI).(1) '-e' (2) '""' (3) -uri (4) '""'
I found that Windows actually understand a similar construct as UNIX does: %* which is substituted with all arguments from the command line:End of Update@echo off java Program %*Therefore, this section would not be needed. But, as stated below, to have a way how to use often used subset of command-line arguments from a file is useful on its own, so I keep this section here.
I still know only how to pass maximum nine parameters to a Windows batch script (does anybody knows how to pass more?):
And it is not enough for some jMoby scripts (e.g. run-service.bat). That's why I added also another feature to the (already mentioned above) command-line reader org.tulsoft.tools.BaseCmdLine: it can accept a special command line parameter:@echo off java Program %1 %2 %3 %4 %5 %6 %7 %8 %9
This can include as many as needed arguments - each one on a separate line. The details are taken from src/Clients/help/argsfile.example file:-argsfile <filename>
Actually, this proved to be handy as a feature on its own: you can store some repeatedly used arguments to a file, and add some in the runtime directly on the command-line.# All clients that use 'org.tulsoft.tools.BaseCmdLine' class for # accessing command-line arguments can also read all or some arguments # from a file. The file name is given as -argsfile parameter. There # may be more than one of them. The arguments read from these files # are included in the place where the the -argsfile were found. # # The file format of such file is: # * Blank lines and lines started by # are ignored. # * Each argument and its (possible) value are on a separate line. # * Each line will be first trimmed of whitespaces. # * Then each line will be trimmed of quotes, if it starts and # ends with the same kind of quotes. # # Here is an example: -name Martin -optionA -next one will be empty "" -next one also ''
Otherwise Windows splits in into two arguments. The only solution for that is to pay attention to it when you have such arguments (an example where such arguments are used is again the script run-service.bat - see details in the Moses project about the BaseCmdLineClient.build/run/run-service "language=english,czech"
If a directory with jMoby has whitespaces in its name (which is quite common - because the user home directories are by default in C:\Documents And Settings) then some jMoby scripts failed to work. Without going to boring details: a workaround was to add to scripts (to their Windows version) to change first to the project home (this could be achieved even with whitespaces by double quoting name), and then to use relative paths (which, in jMoby, have never any whitespaces).
This is not an ideal solution because (again, only in Windows) such change of directory is kept even after the script finishes. but that's all I could find...