Looks like jna could not be downloaded properly. Have you had a look whether the file specified can be opened as a .zip? If not, delete it and try again. MiniMaven should try to download it again, hopefully succeeding this time.

I tried to manually unzip .jar file using java, but it gave me error also. 
When I deleted problematic .jar file, and tried to built fiji again, the program was stuck after these two lines: 

Looking at children of pom-fiji
Looking at children of pom-fiji-plugins

Could you please clarify what you mean by "stalled"? Does it exit without further notice? Does it hang, possibly using a lot of CPU? What does "./Build.sh verbose=true" say?

I apologize for being vague there. By "stuck" I mean that the command line doesn't not quit and it doesn't print anything, and doesn't give any errors, it is stuck on a new line. Unfortunately, I do not know how to check CPU usage on the cluster.

When I tried "./Build.sh verbose=true": 

Parsing /ifs/home/oo370/.m2/repository/org/scijava/pom-scijava/1.51/pom-scijava-Looking at children of pom-fiji
Looking at children of pom-fiji-plugins
Parsing /ifs/home/oo370/.m2/repository/com/apple/AppleJavaExtensions/1.5/AppleJaSkipping artifact com.sun:tools:1.4.2 (for net.imagej:ij:1.47t): not found
Parsing /ifs/home/oo370/.m2/repository/mpicbg/mpicbg/0.6.0-SNAPSHOT/maven-metadata-snapshot.xml
Parsing /ifs/home/oo370/.m2/repository/mpicbg/mpicbg/0.6.0-SNAPSHOT/mpicbg-0.6.0Parsing /ifs/home/oo370/.m2/repository/mpicbg/pom-mpicbg/0.6.0-SNAPSHOT/maven-metadata-snapshot.xml
Parsing /ifs/home/oo370/.m2/repository/mpicbg/pom-mpicbg/0.6.0-SNAPSHOT/pom-mpicParsing /ifs/home/oo370/.m2/repository/loci/pom-scifio/4.4.8/pom-scifio-4.4.8.poParsing /ifs/home/oo370/.m2/repository/loci/jai_imageio/4.4.8/jai_imageio-4.4.8.Parsing /ifs/home/oo370/.m2/repository/loci/loci-common/4.4.8/loci-common-4.4.8.Parsing /ifs/home/oo370/.m2/repository/org/slf4j/slf4j-api/1.5.10/slf4j-api-1.5.Parsing /ifs/home/oo370/.m2/repository/org/slf4j/slf4j-parent/1.5.10/slf4j-parenParsing /ifs/home/oo370/.m2/repository/xalan/serializer/2.7.1/serializer-2.7.1.pParsing /ifs/home/oo370/.m2/repository/xml-apis/xml-apis/1.3.04/xml-apis-1.3.04.Parsing /ifs/home/oo370/.m2/repository/edu/mines/mines-jtk/20100113/mines-jtk-20Parsing /ifs/home/oo370/.m2/repository/org/jfree/jcommon/1.0.17/jcommon-1.0.17.pParsing /ifs/home/oo370/.m2/repository/org/sonatype/oss/oss-parent/7/oss-parent-Parsing /ifs/home/oo370/.m2/repository/org/jfree/jfreechart/1.0.14/jfreechart-1.Parsing /ifs/home/oo370/.m2/repository/javax/servlet/servlet-api/2.5/servlet-apiParsing /ifs/home/oo370/.m2/repository/bouncycastle/bcmail-jdk14/138/bcmail-jdk1Parsing /ifs/home/oo370/.m2/repository/bouncycastle/bcprov-jdk14/138/bcprov-jdk1Parsing /ifs/home/oo370/.m2/repository/net/imglib2/imglib2-algorithms/2.0.0-betaParsing /ifs/home/oo370/.m2/repository/net/imglib2/pom-imglib2-algorithms/2.0.0-Parsing /ifs/home/oo370/.m2/repository/net/imglib2/pom-imglib2/2.0.0-beta-9/pom-Parsing /ifs/home/oo370/.m2/repository/net/imglib2/imglib2/2.0.0-beta-9/imglib2-Parsing /ifs/home/oo370/.m2/repository/net/imglib2/imglib2-ij/2.0.0-beta-9/imgliParsing /ifs/home/oo370/.m2/repository/java3d/j3d-core-utils/1.5.2/j3d-core-utilParsing /ifs/home/oo370/.m2/repository/mpicbg/mpicbg/0.6.0-SNAPSHOT/maven-metadata-snapshot.xml
Parsing /ifs/home/oo370/.m2/repository/mpicbg/mpicbg/0.6.0-SNAPSHOT/maven-metadata-snapshot.xml
Parsing /ifs/home/oo370/.m2/repository/mpicbg/mpicbg/0.6.0-SNAPSHOT/maven-metadata-snapshot.xml
Parsing /ifs/home/oo370/.m2/repository/mpicbg/mpicbg/0.6.0-SNAPSHOT/maven-metadata-snapshot.xml
Parsing /ifs/home/oo370/.m2/repository/mpicbg/mpicbg/0.6.0-SNAPSHOT/maven-metadata-snapshot.xml
Parsing /ifs/home/oo370/.m2/repository/mpicbg/mpicbg/0.6.0-SNAPSHOT/maven-metadata-snapshot.xml
Parsing /ifs/home/oo370/.m2/repository/org/beanshell/beanshell/2.0b4/beanshell-2Parsing /ifs/home/oo370/.m2/repository/org/javassist/javassist/3.16.1-GA/javassiSkipping artifact com.sun:tools:1.6.0_24 (for org.javassist:javassist:3.16.1-GA): not found
Parsing /ifs/home/oo370/.m2/repository/org/scijava/scijava-common/1.4.0/scijava-Parsing /ifs/home/oo370/.m2/repository/net/java/sezpoz/sezpoz/1.9-imagej/sezpoz-Parsing /ifs/home/oo370/.m2/repository/net/java/sezpoz/pom/1.9-imagej/pom-1.9-imParsing /ifs/home/oo370/.m2/repository/net/imagej/ij-updater-core/2.0.0-beta-7/iParsing /ifs/home/oo370/.m2/repository/net/imagej/pom-ij-core/2.0.0-beta-7/pom-iParsing /ifs/home/oo370/.m2/repository/net/imagej/pom-ij-base/2.0.0-beta-7/pom-iParsing /ifs/home/oo370/.m2/repository/net/imagej/ij-core/2.0.0-beta-7/ij-core-2Parsing /ifs/home/oo370/.m2/repository/net/imagej/ij-ui-swing-updater/2.0.0-betaParsing /ifs/home/oo370/.m2/repository/net/imagej/pom-ij-ui-swing/2.0.0-beta-7/pParsing /ifs/home/oo370/.m2/repository/net/imagej/pom-ij-ui/2.0.0-beta-7/pom-ij-Parsing /ifs/home/oo370/.m2/repository/com/miglayout/miglayout/3.7.3.1/miglayoutCPU_Meter not up-to-date because 1 source files are not up-to-date (/ifs/home/oo370/fiji/src-plugins/CPU_Meter/src/main/java/CPU_Meter.java)
Compiling 1 files in /ifs/home/oo370/fiji/src-plugins/CPU_Meter
[-source, 1.5, -target, 1.5, -classpath, /ifs/home/oo370/fiji/src-plugins/CPU_Meter/target/classes:/ifs/home/oo370/.m2/repository/com/apple/AppleJavaExtensions/1.5/AppleJavaExtensions-1.5.jar:/ifs/home/oo370/.m2/repository/net/imagej/ij/1.47t/ij-1.47t.jar:/ifs/home/oo370/.m2/repository/net/java/dev/jna/jna/3.2.7/jna-3.2.7.jar:/ifs/home/oo370/fiji/java/linux-amd64/jdk1.6.0_24/jre/../lib/tools.jar, -d, /ifs/home/oo370/fiji/src-plugins/CPU_Meter/target/classes, /ifs/home/oo370/fiji/src-plugins/CPU_Meter/src/main/java/CPU_Meter.java]
using the class path: /ifs/home/oo370/fiji/src-plugins/CPU_Meter/target/classes:/ifs/home/oo370/.m2/repository/com/apple/AppleJavaExtensions/1.5/AppleJavaExtensions-1.5.jar:/ifs/home/oo370/.m2/repository/net/imagej/ij/1.47t/ij-1.47t.jar:/ifs/home/oo370/.m2/repository/net/java/dev/jna/jna/3.2.7/jna-3.2.7.jar:/ifs/home/oo370/fiji/java/linux-amd64/jdk1.6.0_24/jre/../lib/tools.jar
error: error reading /ifs/home/oo370/.m2/repository/net/java/dev/jna/jna/3.2.7/jna-3.2.7.jar; error in opening zip file
1 error
Exception in thread "main" imagej.build.minimaven.JavaCompiler$CompileError: Compile error: 1
        at imagej.build.minimaven.JavaCompiler.call(JavaCompiler.java:83)
        at imagej.build.minimaven.MavenProject.build(MavenProject.java:444)
        at imagej.build.minimaven.MavenProject.buildAndInstall(MavenProject.java:332)
        at imagej.build.minimaven.MavenProject.buildAndInstall(MavenProject.java:327)
        at imagej.build.minimaven.MavenProject.buildAndInstall(MavenProject.java:327)
        at imagej.build.minimaven.MavenProject.buildAndInstall(MavenProject.java:289)
        at imagej.build.MiniMaven.main(MiniMaven.java:138)

Is it possible that your cluster does not allow you to access the world wide web? The hang appears to be when MiniMaven tries to download jna... when you interrupted, it left an invalid .jar in the file system.

FTR you can check the CPU usage on a Linux cluster using "top" and on a MacOSX cluster using "top -u".

Also: why are you compiling on the cluster? Why not compile locally, use the "Make Fiji Package" command to make a .zip and unpack that on the cluster?

The cluster should allow me to access the WWW since I got .m2 folder somehow. And if I delete it, Build.sh would load it again. I also cloned fiji from github through the command line. 

I am using PC and access cluster remotely. Will a be able to compile and make fiji package on my PC?

Could the error be due to the javassist? 

Parsing /ifs/home/oo370/.m2/repository/org/javassist/javassist/3.16.1-GA/javassiSkipping artifact com.sun:tools:1.6.0_24 (for org.javassist:javassist:3.16.1-GA): not found

About WWW: Fair enough, but you got an invalid jna .jar file twice in a row now.

Yes, of course you can compile on a PC and run on a cluster, the major advantage of Java over pretty much everything else (including Python, because to make it fast, you still have to compile native code) is that you indeed can compile once and then run everywhere. The identical compiled code runs on all platforms on which you have Java.

The message "Skipping artifact com.sun:tools:1.6.0_24" BTW just says that MiniMaven failed to realize that tools is supposed to be a system dependency, i.e. it should expect that dependency in the JDK itself and not download it. (Eventually I will come around to fix it, but this is a non-fatal bug and I'd rather fix some fatal bugs before going into the beauty business).

In order to compile it locally I assume I would need source code and also Eclipse SDK. I could not find the source code. Could you help me with it?

In order to compile it locally I assume I would need source code and also Eclipse SDK. I could not find the source code. Could you help me with it?

Never mind comment #9 and #10. I just got a little bit confused. 
If I use javac to compile code locally, and use cmd, which file/folder I should compile?

Why not try to use ./Build.sh? Since you probably cloned using Git for Windows, you have a perfectly fine Git Bash to use.

I get an error: 

'.' is not recognized as internal or external command, operable program or batch file.

"Build.sh" seems to work but I still get some error: 

Downloading sc.fiji:javac:2.0.0-SNAPSHOT
C:\Program Files (x86)\fiji\Build.sh: line 192: stat: command not found
Downloading net.imagej:ij-minimaven:2.0.0-beta-7
C:\Program Files (x86)\fiji\Build.sh: eval: line 349: syntax error near unexpect
ed token `('
C:\Program Files (x86)\fiji\Build.sh: eval: line 349: `sh /c/Program Files (x86)
/fiji/bin/ImageJ.sh --mini-maven -Dimagej.app.directory="/c/Program Files (x86)/
fiji" install'
C:\Program Files (x86)\fiji\Build.sh: line 307: cd: /c/Program: No such file or
directory

You left a space between "." and "/Build.sh", but I suggested "./Build.sh" without a space.

The other errors come from the fact that I never tested with Git for Windows itself, but with the SDK for Git for Windows (because I co-maintain that project).

Will find some time later today to test and fix the issues.

I double checked and there was no space. 
It would be great if I can finally compile fiji. Thank you.

The other reason I cannot accomplish it on the cluster could be that I run out of space allocated for my directory.

Created attachment 107
Screenshot building on Windows

I added a fix to fiji.git: https://github.com/fiji/fiji/commit/e21dac71 and to scijava-common.git: https://github.com/scijava/scijava-common/commit/2ae35fe3 for the Git for Windows issue.

As to the space: this is how "./Build.sh" is supposed to look like in Git Bash (see the attachment http://fiji.sc/bugzilla/attachment.cgi?id=107).

Furthermore, I just thought about something else: are you sure you want to build Fiji? There are pre-built packages available from http://fiji.sc/Downloads (kept up-to-date by our continuous integration server).

Thank you for all your help. I tried to run pre-built version for linux64, but all I could find there is ImajeJ-linux64 in the Fiji.app folder.

The reason I would like to build Fiji myself is because I would like to run it in the headless mode since cluster does not support any GUIs. Is there any other way to do this? 

When trying to compile fiji on Windows, I get this: 

Failure to download jars/ij-minimaven-.jar
Exception in thread "main" java.lang.NoClassDefFoundError: imagej/build/MiniMave
n
Caused by: java.lang.ClassNotFoundException: imagej.build.MiniMaven
        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Could not find the main class: imagej.build.MiniMaven.  Program will exit.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   589  100   589    0     0    619      0 --:--:-- --:--:-- --:--:--   619
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 16711  100 16711    0     0  19846      0 --:--:-- --:--:-- --:--:-- 19846
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  121k  100  121k    0     0   165k      0 --:--:-- --:--:-- --:--:--  165k

As Fiji is just ImageJ, ImageJ-linux64 *is* the launcher with which to start Fiji on your cluster.

As to the build failure, this is a bug I introduced inadvertently yesterday; it worked here, so I pushed, and Jenkins agreed that it worked. But the daily (full-fledged build-everything-from-scratch) job agrees with you that there is still a problem. I'm on it, will keep you posted.

The Fiji-daily build is happy again, see: http://jenkins.imagej.net/job/Fiji-daily/. Maybe the build works for you now?

But again, the downloadable Fiji package is most likely what you want and need.

I tried to start ImajeJ-linux64 on the cluster by typing into command line: "ImajeJ-linux64", but it says: 
"-bash: ImajeJ-linux64: command not found" 
Am I launching it right? 

The cluster does not support GUI, and I would like to use fiji in the headless mode.

If you substitute the lower-case 'j' by a lower-case 'g', it might work: ImageJ-linux64 instead of ImajeJ-linux64. Computers are really finicky.

As to headless support: yes, it is there: --headless. However, it also activates this automatically when the DISPLAY environment variable is not set (on Linux only). Note that ImageJ-linux64 will not run on Windows... ;-)

I had to put ./ in front of ImageJ-linix64. When I type:

./ImageJ-linux64 --headless -eval "print ('Hello World');"

I get an error: 

Error while executing the main() method of class 'fiji.Main';
java.awt.HeadlessException

Does the launcher support headless mode automatically? Do I need to load headless.jar manually?  

Thank you.

Oh, I forgot: you also need to pass ''-batch'' so that ImageJ does not try to show a GUI.

./ImageJ-linux64 --headless -eval "print ('Hello World');" -batch

Would be nice if somebody could find the time to document this on http://fiji.sc/Headless, too...

Actually, I just found another bug, but before that, I found another bug: if I do not pass --headless, I get a completely different stacktrace from yours:

On Tue, 9 Jul 2013, Olexandra Ovsiy wrote:

> Dear Johannes,
> 
> When I run ImageJ-linux64 launcher from the cluster, I still get an error:
> 
>  ./ImageJ-linux64 --headless -eval "print ('Hello World');"
> Error while executing the main() method of class 'fiji.Main':
> java.awt.HeadlessException
>         at
> java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:159)
>         at java.awt.Window.<init>(Window.java:432)
>         at java.awt.Frame.<init>(Frame.java:403)
>         at ij.ImageJ.<init>(ImageJ.java:137)
>         at ij.ImageJ.main(ImageJ.java:670)
>         at fiji.Main.main(Main.java:130)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at imagej.ClassLauncher.launch(ClassLauncher.java:224)
>         at imagej.ClassLauncher.run(ClassLauncher.java:161)
>         at imagej.ClassLauncher.main(ClassLauncher.java:72)
> 
> Does the launcher support headless mode? Do I have to manually load
> headless.jar?
> 
> Best,
> Olex

$ DISPLAY= ./ImageJ-linux64 -eval 'print("Hello world");'
Error while executing the main() method of class 'fiji.Main':
java.lang.InternalError: Can't connect to X11 window server using '' as the value of the DISPLAY variable.
	at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
	at sun.awt.X11GraphicsEnvironment.access$100(X11GraphicsEnvironment.java:52)
	at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:155)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:131)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:169)
	at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:68)
	at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:89)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:169)
	at java.awt.Toolkit$2.run(Toolkit.java:834)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:826)
	at fiji.gui.FileDialogDecorator.registerAutomaticDecorator(FileDialogDecorator.java:142)
	at fiji.Main.premain(Main.java:87)
	at fiji.Main.main(Main.java:123)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at imagej.ClassLauncher.launch(ClassLauncher.java:224)
	at imagej.ClassLauncher.run(ClassLauncher.java:161)
	at imagej.ClassLauncher.main(ClassLauncher.java:72)

Will have to postpone that for a couple of hours, but then fix it and keep you posted!

After discussion with Johannes, I pushed a branch intended to ensure "-batch" always gets passed whenever "--headless" is given. It is at:

https://github.com/imagej/imagej-launcher/compare/headless-batch

Unfortunately, we forgot that "-batch" requires a macro file as additional argument. It seems that ImageJ1 only disables the GUI when -batch is given, and since -batch requires you to pass a macro file, you cannot do this sort of "headless expression evaluation" as things stand. ImageJ1 would need to be enhanced to support disabling the GUI in some other circumstance.

Johannes, what do you think is the best way forward here?

Well, on second thought, I guess we could hack it to always put "-batch" as the final argument, and only if "-batch" isn't *already* the final argument. This works because ImageJ1 *does* support "-batch" without a macro filename as long as "-batch" is the final argument. That seems very hacky to me, though. Would be better if the "-batch" argument made the filename optional, such that if the subsequent argument also starts with "-" then it is not treated as a macro file.

I fixed the headless-batch branch (linked above) to append -batch only as the final argument to ImageJ, and only if it was not already specified. So we're getting closer now. But I did not investigate the Linux DISPLAY variable stuff. Dscho, I hand off to you, hopefully having saved you a little time.

Wow, we really went through quite a couple of issues, ending up in 'better headless support by the launcher' (when the subject is still 'cannot build fiji on linux').

In any case, I merged the branch with minimal changes (I want to be C89-compliant for ease of compilation with non-GNU C compilers -- such as TinyCC -- so we cannot have declarations after statements, besides, we do not need two variables to record whether -batch was seen and whether we need to add it, still).

For some reason, Trac shows me as author, even if I am just the committer... oh, well.

Olex, if you want to test, feel free to download http://jenkins.imagej.net/job/ImageJ-launcher/label=master/lastSuccessfulBuild/artifact/target/nar/ij-launcher-2.0.1-SNAPSHOT-amd64-Linux-gcc-executable/bin/amd64-Linux-gcc/ij-launcher and replace ImageJ-linux64 with it. That should address your problems.

Thank you all for all your help! 

Apparently, I was able to build fiji despite the error that I was getting (that it could not unzip file). In addition, Build.sh builds ImageJ-linux64 launcher which works as well. 

I was able to test both with the commands: 
./fiji --headless -eval "print ('HEllo World');" -batch

I am working on small script to test batch. I assume the input would be: 

./fiji --headless "macrosExample.ijm" -batch

since -batch has to be the final argument.

Oh, sorry, no, -batch does not *have* to be the last argument. Having it be the last argument is only a work-around for the limitation that you cannot specify to *evaluate* a statement in batch mode otherwise.

See https://github.com/fiji/ImageJA/blob/master/src/main/java/ij/ImageJ.java#L47 for the correct syntax.

If you call Fiji with '-batch <file> <arg>' it will work. In that case, <file> needs to be a path to a file containing a macro that can enquire the argument via http://imagej.net/developer/macro/functions.html#getArgument. The <arg> is actually optional, you do not *have* to specify it.

If, however, you want to evaluate *statements* (rather than a macro stored into a file), you have to call Fiji with '-eval <statement>'. And that does not switch on batch mode without a trailing '-batch' which in turn leads to the HeadlessExceptions you reported.

Things clearer now?

Thank you.  It seems that I am all set.

Cool!