MyArch Jython task has a number of advantages over built-in <script language="jython">
way of invoking Jython from Ant.

Specifically, the task provides the following benefits:

• More graceful exception handling. Jython code invoked using "script" could generate long error stack that includes the Java stack trace of the "script" task. This is especially painful if you invoke other Ant tasks from Jython (you can do it using MyArch PAnt utility) that add their own Java stack trace. MyArch Jython task produces a brief readable error stack. I personally think that unwieldy error traces is a big issue in the industry and it's far from innocuous.

• You can use Ant properties as parameters (the task makes them available in the local namespace of the calling script).

• Ant "project" object is passed in the global variable "antProject" (available from the built-in namespace). In other words, "antProject" is available to all modules/functions invoked using "jython".

• Convenience "import" attribute.

• There is also a JythonPath task for easily setting jython path from Ant path.

• Jython interpreter is initialized once per Ant project. All scripts invoked from the same Ant project reuse the same built-in namespace. So you can define variables and imports in one call and use them in a subsequent call.

• Task name ( the name that prefixes all console output from Ant for a given task) is generated automatically based on the supplied Python code.

Example:

Ant code:

<jythonPath pythonPathRef="python.path" />
<property name="testProp" value="testVal" />

<jython>
print "Property from ant:", testProp
# define a var that we can use in other scripts
s="test"
</jython>

<jython>
print "Var created earlier: ",s
</jython>

<jython  import="from testmodule import *" exec="test(testProp)"  />

"testmodule" python code:

def test (prop):
    print "Passed parameter: ",prop
    print "Test property: ",antProject.properties["testProp"]

Jython task attributes:

• exec - python code to execute. This has to be a single line, e.g., mod.fun() although you could combine multiple statements separated by ";".
• import - a convenience attribute for providing "import" statement. Its only purpose is to make the task invocation more readable. Alternatively, you can have "import" as part of the"exec",e.g., exec="import mod;mod.fun()".
• execfile - execute a python script. This has to be an absolute path to a python file.

JythonPath task attributes:

• pythonPath - python.path to use.

• pythonPathRef - the python.path to use, given as reference to a PATH defined elsewhere.

Jython task is part of myarch-antutil project. Download jython task.

You may also be interested in PAnt - Ant python wrapper.

IBM WebSphere 7 (currently in beta) comes a property-file based configuration tool that provides a "human-consumable" interface to the currently XML-based configuration repository of the application server. This is another proof that XML is simply not the right mechanism for managing configuration of complex software products.

From the release notes:

Properties (name/value pairs) files are more consumable for human administrators than a mix of XML and other formats spread across multiple configuration directories.

Kudos to IBM for recognizing that.

It is still not clear though how hierarchical relationships between configuration objects will be supported.

Back in WAS 6 world, I've been using a simple jython script that converts python named parameters into wsadmin format. This is an example of a resource described in this format:

 WASConfig.DataSource(parent="testJDBCProvider", name="testDS", jndiName="jdbc/testDS",
                              description="Test DataSource", propertySet=dict(
                              resourceProperties=[
                                  dict(name="dbName", value="testDB", type="java.lang.String" ),
                                  dict(name="connectionAttribute",value="", type="java.lang.String")
                               ]))

I think that a slightly more streamlined python-based format will be superior to properties.

Most developers and administrators working with WebSphere Application Server (WAS) know that both JACL and Jython languages can be used for various WAS administration and configuration tasks. However, JACL has always been a preferred choice, simply because this is the default language used by the product's admin tool (wsadmin) and also because JACL examples and documentation are more complete.

Using JACL might have been a valid option just a few years back (when WAS just came out) given the uncertainty surrounding the Jython project. Today, however, jython is clearly alive and well; an alpha version supporting Python 2.5 was announced recently. Therefore there is really no point in using JACL any longer, except may be for shops with a large collection of existing JACL scripts. JACL syntax is quite arcane compared with Python and the language is clearly not as widely used.

IBM confirmed this view by releasing JACL to Jython converter a couple years back.

Unfortunately, up until recently, jython was not officially supported in another IBM product, WebSphere Portal, which comes with wpsript tool for managing pages, deployable modules and other portal artifacts.

But since portal scripting relies on wsadmin's shell, jython is in fact fully supported by the product, it's just not documented. All that you need to do to switch to jython is to invoke wsadmin with "-lang jython" and "-wsadmin_classpath " followed by the list of portal jars (you can copy the classpath from SCRPATH variable definition in wpscript.sh).

As an example, I put together a simple Jython script for cleaning up a page hierarchy. Removing pages before applying an XMLAccess script with page definitions allows to start portal configuration from a clean "known" state. Very often, especially in a development environment, an application's page hierarchy gets polluted with various "test" pages created by developers. The script gets rid of them.

In WebSphere Portal 6.1 Jython is finally made a first-class citizen. The product's documentation proclaims that JACL support will be phased out and that jython is the way to go. Surprisingly, though, all examples still use good old JACL. I assume it's just a matter of time before they convert.