Category Archives: Ant

Moving log4js-ext development from Windows to Linux -while keeping Windows dev supported

I have been moving my development environment from Windows to Linux, step by step, and the time for moving log4js-ext has arrived.

Log4js-ext is a pure javascript + Java project, and therefore source code portability is not a big issue: the only portability issues that arose were due to the build tools I use to create the deliverables, and the ant build file.


Here is my main issues list:

  • Differences in OS conventions, including directory separator, etc., make tools fail.
  • Can’t use good old CMD to run command line tools.
  • Some tools are not available in the Linux world.
  • Other nuisances.

Differences in OS conventions, including directory separator character, etc.

There are differences in the way Linux and Windows names things, case sensitivity or the directory separator.

Being aware of that, and knowing that Windows supports both ‘\’ and ‘/’ as directory separators, I’ve been using ‘/’ for ages, so that did not pose a problem.

Besides, some file paths changed (i.e., the Tomcat config directory location), but that was an easy thing to spot and fix, and I moved those paths to ant properties to make them easier to deal with.

Thankfully, no other issues appeared in this area.

Can’t use good old CMD to run command line tools

While the project was hosted in Windows, I added calls to external tools to generate Javascript API documentation, optimize image size, etc,. invoking cmd.exe with the ant exec task.

For example, this is the relevant part of the ant code I used to generate the API documentation:

<exec executable="cmd" dir="${lib.basedir}/src" >
  <arg line="/c jsduck .../>

I had to modify the exec to make it work both in Windows and Linux, as follows:

<!-- Ok, executables are called differently in Windows and Linux... -->
<condition property="jsduck.cmd" value="cmd.exe">
  <os family="windows"/>
<property name="jsduck.cmd" value="jsduck"/>

<condition property="jsduck.cmd.extraparams" value="/c jsduck">
  <os family="windows"/>
<property name="jsduck.cmd.extraparams" value=""/>

<exec executable="${jsduck.cmd}" dir="${lib.basedir}/src" >
  <arg line="${jsduck.cmd.extraparams} .../>

As you can see, I had to provide slightly different commands to exec. It was easy, but I have to admit that ant makes this verbose and to look like a big thing -which it is not.

Another annoyance was running java to minify the consolidated javascript file that includes all of log4js-ext. In Windows, I used an exec task to call Java, passing the YUI minifier jar, as follows

<exec executable="cmd">
  <arg line="/c java -jar ${yui.jar}
   -o ${pack.tmpdir}/${lib.project}-all.js"/>

Now, I decided to use the ant java task instead, as it looked easier to use it in a portable way:

<java classpath="${log4j.jar}" jar="${yui.jar}"
  spawn="true" fork="true">
  <arg line="${pack.tmpdir}/${lib.project}-all-dev.js -o

However, I discovered that I had to fork the java task in order to invoke a jar, and that meant that other operations were executed *in parallel*…and therefore were called before the java task output they required was available, failing.

The workaround was to add the following lines immediately after the java task, so that it waited until the generated file was available, or 30 seconds, whatever came first:

<waitfor maxwait="30" maxwaitunit="second">
  <available file="${pack.tmpdir}/${lib.project}-all.js"/>

Thank God, the problem with parallel execution was easily repeatable and I was able to find the problem in no time. Had it manifested itself only from time to time, it would had been a real pain.

Some tools are not available in the Linux world

Too bad, but it is true: some tools that are readily available in the Windows world are not there in the Linux world.

That was the case with the tools I use to optimize PNG, GIF and JPG images, pngslim and pngout.

Well, since log4js-ext is very mature when it comes to the front-end, there is no real need to optimize new images, which will probably never come into being. The smart thing to do was to ignore the problem, and not to look for alternatives 🙂

So, that’s what I placed at the beginning of the corresponding ant task:

<fail message="NOT PORTED TO LINUX TOOLS: if the need arises to add new images, then it will make a lot of sense to look for alternatives that work in Linux"/>

Call me pragmatic!

Other issues

Whenever you move or install a complex development environment, it is always hard to reproduce it exactly, unless you go to great lengths.

Log4js-ext being a personal project, that was asking too much, and I just installed the latest versions of the different tools in Linux.

That meant I found the typical problems due to my Windows environment using version x.y.1 of JSDuck and Linux apt-get installing x.y.2: in fact, I had not one, but two problems related to using a newer version of JSDuck.

I know, this is not related to Windows vs Linux per se, but it is worth taking into account because it will happen. For big projects this can be a real problem, and I tend to be very, very strict with the exact version of tools and libraries I use.

A non-trivial ant build file that works in Linux *and* Windows

Just for the sake of it, I run the new ant file in Windows and performed several tests to check the results: everything worked, so I called it a day.

All in all, making my build and test scripts work in Windows and Linux was not as much of a chore as I had anticipated, and I was pleased with the time it took to migrate and the result.