This assumes you have already obtained a working copy of the codebase.
The build scripts have been tested only on Linux. On non-Unix platforms, they will likely need some work.
Ensure you have Java Development Kit (JDK) 6:
java -version
Ensure you have Perl 5:
perl --version
Change to the directory of your working copy. For example:
cd working-copy/
Test the build script:
textbender/a/b/demo/build --help
If this is your first build, it will fail. The way to fix it depends on the error message.
Can't locate Module.pm in @INC...
Above, it is complaining about a missing Perl module. Simply install the module, e.g. from CPAN.
unable to parse textbender/a/b/Build_config.pl: No such file or directory
Above, it is complaining about a missing config file. Config.pm explains the reason, and how to fix it.
Usage: build clean build [argument] build --help | --man Arguments: demo Builds the demo. This is the default argument. boot Builds the boot jar, textbender.a.r.page.BootApplet.jar. Returns the jar file name. clean Deletes all build files. Options: --help Outputs a brief help message and exits. --man Outputs the full manual page and exits. --sign | --no-sign Specifies whether or not to sign the jars. By default, jars are signed. --verbose Increases the level of console output.
Eventually, when nothing more is missing, the command will run to completion, and print a helpful message, as above.
Build the demo.
textbender/a/b/demo/build --no-sign
As in the previous step, this may fail, until you supply missing modules or config files.
demo base jar (compile 230... (jar files 1297... (jar all-in-one ... boot (compile 1... (jar files 51...
When it succeeds, it prints out its progress, as above. The code is now built. All that remains is to test it.
Run the desk daemon from the command line. This basically duplicates a JNLP (Web Start) launch, as described in the user instructions.
java -enableassertions:textbender... -Xfuture -classpath /out/jar.jar:/out/textbender.jar:/out/textbender/o/jlfgr.jar textbender.a.r.desk.Run
Substitute your own build's out/ directory.
If there are any problems, compare your command line with the JNLP descriptor. They specify basically the same thing.
The desktop half of the software is now running. All that remains is the browser half.
Grant yourself permission to run unsigned applets. Create a Java policy file (for example, ~/.java/deployment/security/java.policy) and add something like the following to it, It grants permissions for applets both in the build out directory, and the temporary directory. You will need both:
grant codeBase "file:/out/-" { permission java.security.AllPermission; }; grant codeBase "file:/tmp/-" { permission java.security.AllPermission; };
Otherwise, you must rebuild without the ‘--no-sign’ option. And for that, you need a code-signing certificate.
Create a couple of test documents to work with. The two I use most often are called (appropriately) 1.xht and 2.xht. You can copy them (being careful to do so using the browser's source view, like the demo instructs users to do) from http://reluk.ca/project/textbender/_/scratch/.
Two URI's will need to be modified, to point to your working copy of the source code:
In all other respects, these test documents are encoded exactly like normal documents.
Now follow the user instructions for the demo. But whenever you load a document in the browser, substitute one of your test documents, and use a boot_root parameter to point it to your build, thus:
file:/home/user/1.xht?textbender_a_r_page_boot_root=file:/out
That should be enough to make it through the demo, running entirely from your own build.
You can tweak the the Plug-In for debugging. First, launch the Java Control Panel.
/opt/jdk/bin/ControlPanel
You can ask it to “always show console” (in the Advanced settings), which is useful.
You should add these options to the applet runtime:
-enableassertions:textbender... -Xfuture
Maybe add an option like this, if you want to configure the logger:
-Djava.util.logging.config.file=/opt/java-applet-logging.properties