Jakarta Turbine Web App Framework 2.3 Released


News: Jakarta Turbine Web App Framework 2.3 Released

  1. Jakarta Turbine Web App Framework 2.3 Released (9 messages)

    The Jakarta Turbine web app framework has been released today. Turbine 2.3 features a completely overhauled templating engine (which no longer supports (WebMacro, Freemarker or Castor), and maven for the build environment, and commons-logging and commons-configuration.

    Check out http://jakarta.apache.org/turbine/.

    -----Original Message-----
    From: Henning Schmiedehausen [mailto:henning at apache dot org]
    Sent: Thursday, September 04, 2003 7:47 AM
    To: announce at apache dot org
    Cc: Turbine Users List; Turbine Development List; Tetsuya Kitahata
    Subject: [ANN] Jakarta Turbine 2.3 released

    The Jakarta Turbine team is pleased to announce the release of the next version of the Turbine Web Application Framework:

                     Jakarta Turbine 2.3

    The CVS tag for this version is TURBINE_2_3
    The branch tag for maintenance versions is TURBINE_2_3_BRANCH

    You can find a list of changes here: http://jakarta.apache.org/turbine/turbine-2.3/changes.html

    Source and binary distributions for JDK 1.3.1 and JDK 1.4.2 are available from the apache mirror system or from http://www.apache.org/dist/jakarta/turbine/

    Some Notes

    * Turbine 2.3 no longer supports WebMacro, Freemarker or Castor
    * Turbine 2.3 is the first release to consequently use commons-logging
      and commons-configuration to remove the need for its own logging and
      resource services
    * Turbine 2.3 can load and use Avalon Components with the Avalon Service
    * The Templating engine at the core of Turbine has been completely overhauled and is now much more flexible and stable. However, this comes at the price that using "/" for template separators is no longer possible (This is a major change from our previous versions).
    * Turbine 2.3 uses maven as its primary build tool. Building with Eclipse is possible but not officially supported. Building with ant only is no longer supported.

    The Turbine team really would like to thank all the contributors, users and members of the development and user list that helped with comments, patches and critisism to make this the best Turbine release yet. The announcement author would also like to thank the Torque team because I stole the layout of the announcement from you. ;-)


    Threaded Messages (9)

  2. This is progress?[ Go to top ]

    I'm not sure if their decision to stop supporting FreeMaker and WebMacro a good thing or not, any thoughts on that issue?
  3. This is progress?[ Go to top ]

    No, it isn't progress. Turbine should have been taken out of service long ago. It has so much cruft in it that it is essentially unusable. Back in 2001 I looked at it as a possible web framework and while I liked the ideas I hated the implementation...hence JPublish.
  4. This is progress?[ Go to top ]

    I've used Turbine for almost 2 years and to be honest I has gotten quite stale. I actually agree with removing some of the templating interfaces, as pretty much the user group as it is simply use Velocity. Whilst you can use JSP, the reality is that its poorly supported.

    The unfortunate thing is that most of the developers have upped and left. I was stuck using Turbine 2.1 for ages as some developers were working on Turbine 3, another few decided to start another one called Plexus, all the while the existing user group where left to rot and nothing along the roadmap was implemented.

    That said it did the job nicely and its not the only game in town for top side server tasks.
  5. This is progress?[ Go to top ]

    I've been fairly happy using Turbine 2.2 with JSP on a couple of projects, although I agree that a lot of the questions on the mailing list pertaining to using JSP with Turbine tend to be answered by attempting to steer the person asking the question towards Velocity. Actually, I tend to agree that Velocity is a better templating mechanism than JSP, but, JSP is more mainstream, and if that's what the customer wants, that's what I build. Also, JSP seems to be getting better with things like JSTL and Server Faces. It's nice to have the option, IMO, to use another templating engine.
  6. Good news.But the security(User-Role) system is not flexible
  7. RE: User/Group/Role not flexible[ Go to top ]

    That's suprising to me. I found the security framework to be very flexible, but maybe because I didn't need to push it too far. Out of the box, it comes with a database or LDAP security implementation. I haven't used the LDAP, but the database defines Users, Groups, Roles and Permissions. Roles are collections of Permissions, and Groups are things that Users have Roles and/or Permissions in. With that, I feel like I'm able to lock down any part of the application easily, and provide a user interface to manage it all.

    The major drawback, in my mind, to the Turbine 2.2 security is the fact the security database schema cannot easily be integrated with the application schema. That is, the Tourque (O/R mapping layer) schema is separate from the application schema, so that, for instance, Groups can't easily be used in relational joins through Tourqe. This situation is supposed to have been improved in 2.3. We'll see.
  8. RE: User/Group/Role not flexible[ Go to top ]

    To do that you can use the new Torque Security service. As long as your app DB is being handled by Torque and your tables overlap with the security DB schema, you can use your app tables with app related columns.

    On this same security thread, has somebody used OSUser from OpenSymphony? Anything that you want to share about your experience?
  9. struts?[ Go to top ]

    Why not use struts as a more std framework?
  10. RE: why not struts?[ Go to top ]

    Why not use struts as a more std framework?

    In my case, I wanted more "out of the box" than Struts seemed to offer at the time (I was looking at Struts 1.0.1). I was initially trying to build a user customizable portal with "email push" delivery based on Jakarta Jetspeed (which is a Turbine app), but ended up dropping down a layer to plain Turbine in order to meet a short deadline.

    In general though, the comparison between Struts and Turbine may not be "apples to apples". Struts is a nice implementation of MVC for the presentation tier, and clearly has gained critical mass in terms of mind share. Turbine, on the other hand, is more of an "end to end" Web app framework, which contains an MVC servlet, an O/R mapping layer (Torque), a services framework (Fulcrum), and a collection of pre-built services that you can use, without having to code them. IMO, a more apt comparison of Turbine might be to a framework like Expresso (which, I believe uses Struts for it's MVC servlet) or to another "end to end" framework.

    It is possible to write your own services and/or plug in other code as a service in Turbine. For instance, you might be able to plug in Hibernate, or something else, to replace Torque. I don't think the MVC servlet can currently be replaced with Struts though, since the Turbine servlet is central to the whole framework. The existing MVC servlet really isn't that different from Struts IMO (e.g. Action classes, reflection based form processing, etc.) I would prefer that it were more mainstream though.