Difference between revisions of "Overview of Fiji's source code"
(→The Fiji launcher: update the completely outdated version)
|Line 12:||Line 12:|
== The plugins ==
== The plugins ==
[[Why Closed-Source Is Wrong|]][://./fiji/ ]''.'' . the ''.jar'' .
plugins that be . Example: the ''.jar'' stored in ://./fiji/.
the ''plugins.'' in ///
== Libraries ==
== Libraries ==
Revision as of 11:39, 11 June 2014
This page will give you an idea how Fiji's source code is organized. Every directory referred to is relative to the Fiji root, i.e. the directory into which you cloned fiji.git.
The Fiji launcher
The plugins served from Fiji's update site are all Open Source. The source code lives on GitHub, in repositories reflecting the name of the .jar file generated from the source code. Example: the source code for Fiji_Plugins.jar lives in https://github.com/fiji/Fiji_Plugins.
The only special rule applies for plugins whose file names end in an underscore: that underscore will be stripped. Example: the sources of Arrow_.jar are stored in https://github.com/fiji/Arrow.
All of our plugins are maintained as Maven projects; this allows developers to build the code with their integrated development environment of choice.
Plugins maintained in Maven projects consist of
- a pom.xml file in the top-level directory
- the Java sources in the src/main/java/ directory, and
- the plugins.config file in src/main/resources/
If the plugin sources contain unit tests, their sources are in src/test/java/ so that the generated test classes will not be included in the final .jar file.
Some plugins require third-party libraries such as Jama. Such libraries are not stored in plugins/ (lest an underscore in their filenames would make ImageJ mistake them for plugins), but in jars/ instead.
Some of the libraries' sources are stored in src-plugins/ (in subdirectories corresponding to the basename of the respective .jar file).
Some components of Fiji are stored in submodules, i.e. in Git repositories of their own right. This is the case for ImageJA, many third-party libraries, and some plugins collections that existed before Fiji, such as TrakEM2 or Bio-Formats.
These submodules are subdirectories in <Fiji-root>/modules/, and they may, or may not, be checked out.
Every submodule is "committed" at a certain revision, i.e. Git not only records where, say, ImageJA is to be cloned from, but also what revision is current for any given commit in fiji.git.
If submodules are checked out, you can cd into the respective directories and work with them as with other Git repositories.
Our policy, however, is that you do not need to check out the submodules if you do not want to work on them: the result of the most recently committed revision needs to be committed as binary in <Fiji-root>/precompiled/. For example, the .jar file generated from the bio-formats submodule is committed as precompiled/loci_tools.jar.
The Fiji Build system
For historical reasons, the Fiji Build system's source code lives in <Fiji-root>/fake/Fake.java. It will be compiled into <Fiji-root>/fake.jar.
To avoid a chicken-and-egg problem, a fake.jar that can compile the current Fiji Build system is committed to precompiled/ (and for the same reason, precompiled versions of the Fiji launchers for all supported platforms live there, too).
The precompiled/ directory
Precompiled versions of all .jar files generated from submodules, of fake.jar and of the Fiji launchers live in precompiled/.
The bin/ directory
Quite a few tasks -- such as committing a new submodule or sources for a plugin, or releasing a new version of Fiji -- are performed by scripts. These scripts live in the <Fiji-root>/bin/ subdirectory.
Some of these scripts are shell scripts, others are Jython scripts with special shebang lines which trigger them to be called with the current Fiji launcher.
The nightly-build/ directory
We have a cronjob that builds Fiji every night, from then-current sources. The responsible script is bin/nightly-build.sh.
Of course, it might often be quite handy to do the same locally, i.e. compile from a completely pristine state (e.g. to ensure that your latest commit includes all necessary files). You can easily do that by calling ./bin/nightly-build.sh HEAD, which will automatically create an appropriate nightly-build/ subdirectory (if it does not exist yet), and simulate a from-scratch build.