Apache has announced the release of commons-jelly 1.0, an extensible Java and XML based scripting and processing engine for turning XML into executable code.

Notable changes since the 1.0-RC1 release:

• Internal caching was changed to remove a memory leak
• Jelly is now distributed as an application with its dependencies and main tag libraries

Jelly is one of the underpinnings of Maven.

The last released version (the release candidate) was from November 2004.

;-)

Someone had to put the chairs on the tables and turn out the lights.

(btw, thanks to the jelly team for not abandoning it in beta).

Someone had to put the chairs on the tables and turn out the lights.

Can someone clue me into why Jelly apparently has no future?

I suppose jelly is not the worst apache product. I welcome their efforts to support XUL-like markup for both swing and swt like swixml and xswt do. But I think we should look at jelly as a handy tool but not the scripting language.

In my view jelly lacks good documentation (as most of the appaches) and several user friendly features, e.g. XML schema for core tag libraries. Finally, I wish a good luck to the Jelly team !;)

I did a little bit of research and it looks like one Jelly's main uses was in Maven. However, Maven2 seems to be moving from Jelly to Marmalade (that earlier Commons-Peanut-Butter comment doesn't seem so crazy now, does it?). It looks like that's what has people assuming Jelly has no future.

./.../
It looks like that's what has people assuming Jelly has no future.

I don't think so.
Jelly is a pretty, small and very-extensible template engine.
I use it for everything I need to template (ouput, simple business rules and so on...)
It's like JSTL, but w/o JSP engine and more easy to extend.

FYI: Jelly is also used internally by the JIRA issue tracker from Atlassian, which not only it's widest distribution (far larger than Maven, I think) but also a commerical product! I don't know if it's also used in their Confluence product, but I wouldn't be suprised.

Here's a link to how Jelly in used in JIRA, and also the custom Jelly tags created for scripting JIRA. I think it makes sense to teach customers XML attriubutes than, say, integrating a javascript engine for customization. I thought it was a pretty slick idea, myself.

http://www.atlassian.com/software/jira/docs/v3.2.1/jelly.html

I would like to give it a try, but looking for example scripts through viewcvs is painful...

I'm still waiting on Commons-Peanut Butter!!

Just look at these comments.
Oh dear I wouldn't want to be one of the developers, imagine the sheer embarassement...

Just look at these comments.Oh dear I wouldn't want to be one of the developers, imagine the sheer embarassement...

I think the reputation of Jelly comes from Maven, i.e. Maven plug-in writers. Implementing complex plug-ins in XML is a really bad idea. Moreover Maven plug-in API is far from friendly.

Personally I have nothing against jelly, but Maven is a monster;).

I've designed a plug-in API for one commercial product and initially we had only java plug-ins. Then we've added support for XML-based plug-ins and jelly was one of the scripting languages(we've decided to add support for BeanShell too). In my view jelly fits well for creating small sized plug-ins, without dependencies on java specific APIs, especially if plug-in should provide a lot of meta-information in XML form.

Regards,
Theodore Kupolov

been using it. very handy for object-to-xml conversions and SAX pipelining. makes sense, and if it wouldn't exist, it would have to be written.

this release proclaimation does not like others which could be known what the release is. i can see something like maven, object-xml, been shell, blablabla. but what the hell jelly is? the friend of Tom in Disney?

Its creators give it the unfortunate description of "Executable XML"; which is true (think "XML scripting language"), but sells Jelly short IMO. The whole concept of "executable XML" seems like a solution in search of a problem.

In practice, however, Jelly is fabulous for other uses. One interesting and practical use for it is to provide for "active configuration". For example, rather than just having an XML config file with static values, you can actually provide some intelligence capability as to how those values are used, or perhaps in conditionally determining what those values should be.

It also makes a fine scripting engine in general. Sure, we have all kinds of scripting engines that use real languages rather than contorting XML into an executable language, but if your audience are not Java/TCL/Ruby et al programmers, then I think you can make a decent argument that XML is a lengua franca that can be used for internalizing functionality via an external script engine.