Bug 57707 - Execute failed: java.io.IOException: Cannot run program "wine"
Execute failed: java.io.IOException: Cannot run program "wine"
Status: RESOLVED FIXED
Product: Tomcat 7
Classification: Unclassified
Component: Packaging
7.0.59
PC Mac OS X 10.1
: P2 enhancement (vote)
: ---
Assigned To: Tomcat Developers Mailing List
: PatchAvailable
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2015-03-14 17:38 UTC by Graham Leggett
Modified: 2015-04-28 13:20 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Graham Leggett 2015-03-14 17:38:32 UTC
When attempting to run "ant release" on MacOSX 10.10, the build fails as follows:

BUILD FAILED
/Users/minfrin/src/tomcat/TOMCAT_7_0_59/build.xml:2082: Execute failed: java.io.IOException: Cannot run program "wine" (in directory "/Users/minfrin/src/tomcat/TOMCAT_7_0_59/output/dist"): error=2, No such file or directory
	at java.lang.ProcessBuilder.processException(ProcessBuilder.java:478)
	at java.lang.ProcessBuilder.start(ProcessBuilder.java:457)
	at java.lang.Runtime.exec(Runtime.java:593)
	at org.apache.tools.ant.taskdefs.launcher.Java13CommandLauncher.exec(Java13CommandLauncher.java:41)
[SNIP]

Googling for a workaround led me to this:

http://qnalist.com/questions/4654266/vote-release-apache-tomcat-8-0-0-rc10

In which the following is stated:

013/12/23 Andrew Carr :
You cannot build a Windows Installer on an Unix system without wine.
(The installer is built by NSIS which is a Windows executable).
You can skip the step by setting "skip.installer" property in Ant configuration.
(This option is not mentioned in BUILDING.txt though).

If wine is a prerequisite, the ant build should fail cleanly pointing out in the clear and unambiguous error message that a) wine is required and b) that the skip.installer property can be used to bypass this if needed.
Comment 1 Konstantin Kolinko 2015-03-14 18:35:43 UTC
RTFM (BUILDING.txt)
Comment 2 Graham Leggett 2015-03-14 20:28:56 UTC
Little-Net:TOMCAT_7_0_59 minfrin$ cat BUILDING.txt | grep wine
Little-Net:TOMCAT_7_0_59 minfrin$ 

No reference to wine in the manual you referenced, sorry.

A quick google shows how to fix this:

http://stackoverflow.com/questions/16556746/check-if-executable-command-exists-using-ant
Comment 3 Konstantin Kolinko 2015-03-14 20:32:52 UTC
Use vi
Lines 268-272 in BUILDING.txt
Comment 4 Graham Leggett 2015-03-15 12:47:06 UTC
Ah, WINE was capitalised, and so not searchable.

This patch fixes it:

Index: build.xml
===================================================================
--- build.xml	(revision 1666658)
+++ build.xml	(working copy)
@@ -2074,6 +2074,7 @@
       <patternset refid="text.files" />
     </fixcrlf>
 
+    <echo message="Note: The Windows installer requires '${nsis.exe}' on Windows or 'wine' on Unix. Use skip.installer to skip this step."/>
     <exec dir="${tomcat.dist}" executable="${nsis.exe}" osfamily="windows">
       <arg value="/DNSISDIR=${nsis.home}" />
       <arg value="/V2" />
Comment 5 Konstantin Kolinko 2015-03-15 16:48:52 UTC
-1.
1. The message should not be printed unless there is an error.
2. The message is wrong. NSIS is automatically downloaded and used by the build script.
3. One should not set the skip.installer without reading and understanding the documentation. Skipping the step creates an incomplete release.

Starting with your original problem:  The message "Cannot run program "wine"" means exactly that - that wine is required. Why else would it try to run it? No fix needed.
Comment 6 Graham Leggett 2015-03-16 12:26:44 UTC
Come on guys, the big exception you get screams "this is broken". Throw the end user a bone and give them a message of some kind, even if that message is "this is intentional".

The idea that you have to go off and read some obscure document before you can build something is totally unreasonable. In the automake world I just run "make dist" and I have a release. In the maven world I run "mvn release:prepare release:perform" and I have a release.

Obviously the release is incomplete if you've added a "skip" option, that's not a justification for wasting the end user's time.
Comment 7 Christopher Schultz 2015-03-17 15:53:07 UTC
(In reply to Graham Leggett from comment #6)
> Come on guys, the big exception you get screams "this is broken". Throw the
> end user a bone and give them a message of some kind, even if that message
> is "this is intentional".

+0

> The idea that you have to go off and read some obscure document before you
> can build something is totally unreasonable. In the automake world I just
> run "make dist" and I have a release. In the maven world I run "mvn
> release:prepare release:perform" and I have a release.

I think you misunderstand what "release" means, here. When you do an "ant release" for Tomcat, you are building a complete release for voting and ultimately, publication. If you aren't a Tomcat committer, there's really no reason to be running "ant release" unless a) you intend to actually build a set of release-quality artifacts for Tomcat and b) you know what you are doing.

Using "ant -projecthelp" has this to say about the "release" target:
 release                          Create a Tomcat packaged distribution

The default target is "deploy", which says this:
 deploy                           Default. Builds a working Tomcat instance


I'm pretty sure that's what you are looking for.

> Obviously the release is incomplete if you've added a "skip" option, that's
> not a justification for wasting the end user's time.

Why is an "end user" trying to do a release build, anyway?
Comment 8 Konstantin Kolinko 2015-03-17 20:50:15 UTC
(In reply to Graham Leggett from comment #6)
> Come on guys, the big exception you get screams "this is broken".

No it is not. Learn how to read the message. It is in plain English.

It says exactly what is broken and what was tried, referencing the exact place (build.xml line 2082).
Comment 9 Graham Leggett 2015-03-21 14:35:55 UTC
(In reply to Konstantin Kolinko from comment #8)

> No it is not. Learn how to read the message. It is in plain English.

This is not the kind of response I'd expect to see from the ASF.

In response to:

> Why is an "end user" trying to do a release build, anyway?

I need a patched release to serve as input into an RPM spec file. This means running the release target. Obviously the Windows artefacts are of no use to the spec file, and so the lack of these is not an error in my case.
Comment 10 Christopher Schultz 2015-03-21 21:58:29 UTC
One could argue that, if doing something as technical as preparing an RPM spec file, you probably should have at least skimmed the BUILDING.txt file to see what the requirements were for building a release build.

Anyhow, in an effort to avoid Konstantin's -1 to your patch, I was going to try to do this:

<exec executable="wine" osfamily="unix" resultproperty="need-wine">
...
</exec>

<fail if="need-wine">
Blah
</fail>

But for some reason, I can't get the <exec> to NOT fail-on-error. I even tried setting failonerror="false" (which is the default) but it still fails early:

installer:
     [echo] Builds a Windows installer based on Nullsoft Installer
     [copy] Copying 1 file to /.../tomcat-7.0.x/output/dist

BUILD FAILED
/.../tomcat-7.0.x/build.xml:2126: Execute failed: java.io.IOException: Cannot run program "wine" (in directory "/.../tomcat-7.0.x/output/dist"): error=2, No such file or directory

Note that, in the above error output, the "installer" target already has an "echo" that tells you what it's doing: "Builds a Windows installer based on Nullsoft Installer". The only thing you really added in your proposed patch was the note about the "skip.installer" property.

I agree with Konstantin that anyone who doesn't understand the error, here, should read the BUILDING.txt file for guidance. The searchability of BUILDING.txt for "Wine" (or "wine" or "WINE", or "WiNe") is tough to fix for all possible combinations of case. Case-insensitive search, perhaps?

If you want to spend some time on a patch for build.xml that directs the user to BUILDING.txt if executing "wine" fails, I'd be happy to review and commit it, but I'm not going to bang my /own/ head against ant to get this solved.
Comment 11 Mark Thomas 2015-04-28 13:20:41 UTC
Yes, the error message could be better but I also don't think it is unreasonable to expect folks to look at BUILDING.txt if they run into a problem building Tomcat. It is in the root of the src distro and the svn repo which are the first places I'd expect people to look for docs if they were having issues.

Testing for the presence of a binary on the path (for a given OS) and then failing the build if it is not found is a on-trivial addition to what is already a large, complex build file. There is a balance to strike between between catching all failure modes and a simpler build file.

My instinct was to close this as WONTFIX but I wanted a better idea of how much code was required. Having written the patch and found it was ~20 lines I was on the fence whether to apply it or not. It isn't small, but neither is it huge and it is fairly simple so I decided, on balance, to apply it. If I have known at the start it was ~20 lines I probably would have followed by instincts and closed this as WONTFIX.

The patch has been applied to trunk and I'll back-port it to 8.0.x but I don't intend to back-port it to 7.0.x. If will probably get back-ported when/if code signing is back-ported to 7.0.x.