X11 / VIM / Screen / jdb

I use my favorite bare-bones combination of VIM with GNU Screen. Yes, I am from the vi School. I run tomcat and jdb in the other screens.

Here is a screen capture of the complete

From tomcat I start with a script:

#!/bin/sh

export JPDA_ADDRESS=8000
export JPDA_TRANSPORT=dt_socket
export JAVA_HOME=/usr

/usr/local/jakarta-tomcat/bin/catalina.sh jpda start

Java Platform Debugger Architecture (JPDA) allows me to debug in this configuration and in others.

From VIM, I reload from the base directory and simply call:

:!ant reload

For the debugger, I run JDB:

$ jdb -attach 8000

This allows me to interactively debug the Tomcat session with breakpoints, stepping, and catching exceptions. It's a little tedious because to set a break point I need to type "stop at MyClass:100" or "stop in org.cip4.elk.ElkEvent.getTimestamp" to stop in a particular method.

Eclipse

My next attempt was to use the well known editor (particularly well know in the JAVA crowd), Eclipse. While this is a huge project and I understand the appeal, I had lots of problems with this approach.

My workstation for this project is a 667 MHz G4 PowerBook with 512MB ram. It's a decent machine but does not handle Eclipse. Besides Eclipse the only other programs I have had any slowness in are high intensity games. I have no clue why Eclipse eats so much of my RAM and CPU, but its a hog. I blame JAVA.

Beyond this, the environment while spectacular, does not look at all native to my OS. However, options are so plentiful it takes me hours to figure out how to make some small modifications.

Eventually, I was able to debug Elk in Eclipse. The debugger experience some memory thrashing and could not step into every function. The real value was in the junit and javadoc (move javadocs) integration.

Xcode

The third and finally environment is one which shipped with my OS, xcode. I am quite impressed with xcode in all areas. In particular, I enjoy working on native applications in C and C++ via Apples Carbon API and writing some Python, as well. Xcode is great, give it try. Because Apple seems to also embraces JAVA, it's not a bad fit for pure JAVA development with Tomcat.

I found Tim Fanelli's Blog Entry entry quite helpful. Based off Tim's advice, here is what I did to get Tomcat working and debugging in xcode:

1. checked out the Elk sources (full instructions)

2. In xcode, created a new empty project with the same directly the sources were checked out. Name the project with the same name used as the module, this case, "ELk". NOTE: the .xcodeproj file should end up in the same directory as your build.xml file. This is also a good time to set up Source Control Management (SCM). I add CVS , but note xcode also support our friends over at Subversion.

3. From the finder, dragged the src/ directory into the "Elk" item in the project window.

4. Removed any unwanted items from the folder hierarchy now in xcode. For example. removed all the .jar files.

5. Project -> New Target. Chose 'Shell Script Target'.

6. In the new Target, double clicked on "Run Script". Under the "General" tab, entered, "/usr/bin/ant;"

7. Project -> New Build Phase -> New Copy Files Build Phase

8. Control + Click "Copy Files" (or right click if you have Mighty Mouse)

9. Add "Empty File in Project". Choose the dist/ directory. Create a file matching the output from your Ant build. Mine is called "elk.war".

10. Double click on the "Copy Files" phase. Type the absolute path to your tomcat deployment directory. Mine "/usr/local/jakarta-tomcat/webapps/".

11. Project -> New Custom Executable. Enter "Tomcat" and make the path "/usr/bin/java".

12. Select the Arguments Tab enter:

    -classpath /opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/commons-logging-api.jar
    -Dcatalina.home=/opt/tomcat
    -Xmx128m
    -Xms64m
    -Xincgc
    -Djava.awt.headless=true
    org.apache.catalina.startup.Bootstrap -debug start
    

Under the Debugging tab, choose "Java Debugger".

What is 'Safe'

What makes a "Safe" programming language depends entirely what your trying to protect and from whom.

Python is Safe

Overall, Python requires some trust to be placed on the programmer and on the others in it's environment. Other language loose luster sometimes due to the extraordinary lengths people have taken to make them Safe. I would trust Python on a lengthy and large, mission critical application.

I do not know if I gave the VP of Marketing the correct answers--causing her to make the jump to Python for use in a commercial situation. However, sometimes a length explanation may help someone better see the aspects of both sides. As with many great tools, they may also be used as weapons when in the wrong hands.

Overview

Elk Framework provides the needed services for a JDF (Job Definition Format) Device or Controller. JDF (another XML format) is a data format which describes common operations in the printing industry. By doing so, it serves as the answer to the printing industries requests to get up to speed with the digital age. It incorporates all printer related operations including: Sales, Administration, Pre-Press, Design, Production, and Post-Press by bridging the gap between each operation and the Management Information Services (MIS).

Elk Project goal is to create an JDF enabled application. In doing so, Elk creates a wonderful framework for testing or to serve as a stating point for others who wish to create a JDF enabled system.

Sponsors and Leadership

Elk is sponsored primarily by CIP4 and in part by Linkoping University's Center for Creative Media Technology (Sweden). The project leader is Claes Buckwalter, a Ph.D Candidate from Likoping University. Ola Stering (Uppsala University) is a major contributor, as well. I have already seen the great personal benefit of working with and learning from these two highly intelligent and hard working programmers.

Why Contribute

For the past ten years, the Printing Industry was my source of income while the Open Source community was my source of fun--Never the twain shall meet. Until now, I never found any open source printing project which also server the Digital Printing world on a grand scale. The only exceptions I can think of are ghostscript and CUPS. Although, these projects are not specific to the printing industry and as with most printing related open source projects (more found here on SourceForge's Printing Foundry ) there seems to be more focus on Desktop Printing and Device Drivers. However, my interests are in: High-Volume digital printing, Print on Demand, Variable Printing, Prepress, and Commercial Lithography workflows. So Elk, which embodies a bit of all of these, is a good fit.

I am looking forward to helping out with Elk any way I can. Feel free to contact me if you have questions regarding the Elk project. Also, will be attending Print05 here in Chicago this September and am willing to meet up with any interested parties.

Install

You may want to make changes to diffback.py. Just open the file with a text editor and change the default settings. Currently supports:

• Macintosh, Window, and Unix. Basically, anything Python friendly. Of course, this was build on a mac.
• Subversion or Concurrent Version System (CVS)
• FileMerger.app (via opendiff), VIM (VI-iMproved), kdiff3

Requires: Python 2.2 or greater

You may also want to add it to somewhere in your system path, ie:

sudo ln -s  diffback.py  /opt/local/bin/diffback

Have fun. Please let me know if you have improvements bray (at) sent.com.