We are pleased to officially introduce Tynamo project and announce our first releases and immediate availability of tapestry-model, tapestry-hibernate-seedentity, tapestry-conversations and tynamo-archetype modules. Tynamo is a continuation of Trails framework and is based on Tapestry 5.
- tapestry-model provides a model-driven development and a CRUD-framework for Tapestry 5
- tapestry-hibernate-seedentity allows you to seed your database in an object-oriented manner
- tapestry-conversations provide a conversational scope
Feel free to link to us, we are just getting started and we have many other modules, such as security and REST, waiting under our wings so stay tuned for more releases! Meet us via IRC at #tynamo on irc.codehaus.org or subscribe to firstname.lastname@example.org at http://xircles.codehaus.org/my/email/subscriptions to stay up-to-date.
Hope the headline generates some buzz but I have to first correct myself: Trails is not dead per se, rather Trails 1.x is in maintenance mode and Trails 2 (Tapestry 5 based version) has been renamed to Tynamo. Here's the full scoop (an edited version of what I had posted about it on trails-user list earlier):
Behind the scenes (actually on the dev list) we've been mulling over our strategy regarding Tapestry5. We lost the trailsframework.org
domain over a year ago (we, the current committers, never owned it so it was complicated anyway) and ever since we've been in a stalemate
about what to do with it. We finally decided a few months ago that the easiest option is to just rename the project and launch Trails 2
under a new name - Tynamo (still hosted at Codehaus). This is unannounced but the move is well under way and at this point we've
moved the codebase to a new repository and renamed the relevant modules and packages. Overall, I think there's a pretty good chance
that we'll have the initial Tynamo release out before the end of the year. We'll formally announce what I just said later.
So please, come visit us at http://tynamo.org. We are busily working on the new site and getting ready for our first releases. Snapshots are already available at http://ci.repository.codehaus.org/org/tynamo/. Obviously much of the code is the same as what we had in Trails except for the rename so it's not like we are starting from scratch. The source repository is already migrated, the new domain is up and our continuous builds are succesfully running so we are already back in business with Tynamo. By the time we are announcing Tynamo project to larger audience later this year (hopefully!), we should have multiple modules lined up for the release as well as decent documentation and examples to go with them.
As mentioned, Tapestry 4.x based Trails 1.x is now in maintenance mode but if there are any serious issues or questions regarding it, we are more than happy to support you. Many thanks to Codehaus and Ben especially for patiently working through our support request during the transition.
The Trails development team is pleased to announce the trails-conversations-0.0.1 release for Tapestry 5!
An implementation of conversation-within-page concept for Tapestry 5
Have you ever wished to have a scope longer than a request but shorter than session?
Have you ever spent hours optimizing your pages just to avoid the use of sessions?
Have you ever wondered why you have to elaborately describe your page flows in a lengthy XML format, when all you want to do is to make your objects survive through redirect-after-post pattern?
Don't you just wish that your web framework would automatically clean up the session-persisted objects once the user is done using them?
If you answered yes to any of the questions above, trails-conversations is for you!
More information at: Conversations+in+Trails
Changes in this version include:
o Initial implementation of ConversationModerator component Issue: TRAILS-176.
o Initial implementation of conversation-within-page Issue: TRAILS-175.
o Wiki example does not work Issue: TRAILS-171.
o Conversations don't work at all Issue: TRAILS-170.
Usage in your Maven project as follows:
(May require a few hours to pass before the release is synched up from codehaus repository to repo1.maven.org)
Or, for a manual installation, you can download trails-conversations-0.0.1 here:
Sorry people, the trunk may be a bit unstable for some time. Why? Alejandro has started a furious effort of coding Trails 2.0 and merging in T5! In the meantime, I've been enjoying development with the superb ajax features of T4.x series (eventlisteners, async forms etc.) With that said, we had an interesting discussion on #trails over IRC, here's an excerpt (Alejandro aka billy):
Just like that, only half a year behind the schedule (practically nothing in open-source circles) we are releasing Trails 1.2.1! This version integrates with Tapestry 4.1.5 and will be the last major release based on T4. The release represent maturization of Trails codebase and hard work solely by Alejandro. The undersigned has mostly been enjoying the fruits of this work and meanwhile using the superb ajax-features of the matured T4 codebase, on top of a Trails-based application, how else. The release contains more changes under the covers than the release history shows, and for most Trails users should be a painless upgrade. Enjoy!
Trails 1.2.2 is still planned for the 1.x line, but waiting under the wings for the upcoming Tapestry 4.1.6 and a few other tricks Alejandro may have in his sleeve.
This is a partial re-posting of discussions on Trails dev list, to give everybody a re-cap on what's up with Trails. As most people following Trails know, Tapestry 5 has been a constant topic on our mailing lists and in 2.0 Trails will move to it! Since T5 is an entirely different beast from T4, it opens up a possibility for a whole slew of other changes. Another all-time favorite topic is session-per-conversation, one of the remaining "holy grails" of web applications. Despite the fact that session-per-request pattern doesn't provide any practical advantages over session-per-conversation (though you can argue about potentially lower memory usage), it's the prevalent implementation because implementing session-per-conversation in a generic way is just too difficult. To my understanding, JBoss' Seam is the first web application framework that really provides a generic support for session-per-conversation; not suprising considering Hibernate comes from the same people. Spring WebFlow comes close, the issue is tracked at http://opensource.atlassian.com/projects/spring/browse/SWF-92 (note the mention of improvements coming in SWF 1.1). Regarding conversation support in Spring, these discussions are related: http://forum.springframework.org/showthread.php?t=37174, http://forum.springframework.org/showthread.php?t=32270 and http://forum.springframework.org/archive/index.php/t-41582.html. Of course, there's been various other tries in implementing it, and session-per-conversation hass been used as a performance optimatization in custom cases, but a generic approach remains a challenge. For Tapestry, James Carman mentioned he was working on a long conversation support as part of his Tapernate module but I believe this effort stalled at some point. We later merged Tapernate into our codebase in order to be able to modify and bug fix it.
The issue with both Seam's and Spring WebFlow's approaches is that if you step out of the conversation, your conversation is "lost" and will remain open in the (servlet) session till it expires. Seam's default answer is it doesn't matter: they make the open sessions explicit in their sample applications with their workspace concept; basically reminding the user he had started but never finished these "tasks", and thus allowing the user to jump back in the middle of earlier abandoned conversation. This is a fine approach for enterprise web applications that are closer to desktop apps which require high amount of interaction but don't necessarily have a high number of users. In Trails, we are in a unique position compared to the other full-stack web frameworks like Rails and Grails, even Seam, because Tapestry has such a strong emphasis on high user-count, high-performant web applications. Not that I'm bashing either one; in contrary I applaud their efforts and innovations they've brought to the web application space. (And btw, there are interesting performance comparisons of the two at: http://www.anyware.co.uk/2005/2007/03/23/rails-and-grails-performance-compared/ , http://thoughtmining.blogspot.com/2007/03/grails-versus-rails-comparison.html and http://docs.codehaus.org/display/GRAILS/Grails+vs+Rails+Benchmark ). It might be an interesting experiment to reproduce the tests in Trails, although they don't really focus on testing the view layer performance). Grails supports long conversations via Spring WebFlow integration. However, Trails simply is quite different from these frameworks in many ways and so I'm not convinced the somewhat xml-heavy WebFlow integration would be the right path for us.
Of course, nothing prevents one writing a semi-automatic workspace management layer on top of Seam that would take care of detecting and closing abandoned conversations. The Seam guys have carefully removed any dependencies to JSF. In practice, integrating Tap5 with Seam might be the fastest way of getting practical results for a conversational scope, and wouldn't solve only one but two problems at the same time (conversations and session-per-conversation), of course at the expense of tying the implementation more closely with Hibernate or at least JPA, but that's probably what the majority is using anyway. I'm sure the Seam guys would love to see Tapestry support for Seam. We are not alone in craving for Tapestry/Seam integration. Actually, such an integration already exists by Igor Drobiazko, a Tacos committer (see http://tacos.sourceforge.net/tacos5/tacos-seam/index.html). Unfortunately, at least the current integration doesn't address session-per-conversation, but simply the bijection of Seam components into a Tapestry application.
Given that Trails has traditionally been a full-stack web application framework and we've been good at using and integrating numerous other modules, we'll base off an initial version of Trails 2.0 on T5, Seam and tacos-seam integration. Even with current Trails, it's debateable whether Spring is needed, but it was always too late or too laborious to get rid of it. With a spanking new, built-in Tapestry IoC and Seam's bijected dependencies, Spring looks somewhat extra and at least initially we'll manage without it for Trails 2.0. The development will happen in a new branch, which we haven't even created yet.
Before we get heavily into Trails 2.0 development, we still have Trails 1.2 to clear out first. 1.2 will be the last major Trails release from T4 line. Most major stuff have been implemented, but we are still waiting on T4.1.4 release and then sorting out the remaining bugs. It's likely that some of the less important ones will be moved out for possible future bug-fix releases. After 1.2, we'll be steaming ahead with Trails 2.0. (The Tapestry/Seam explains the word play with Steam, but I'm sure we can produce a bit more than just hot air ) In the meantime, happy trailing!
Trolling with Java Web Frameworks by Fred Daoud
Brilliant, funny, certainly geeky.
I can't stop laughing!
Just three days after releasing 1.1, we are releasing 1.1.1. And no, we didn't have a major screw-up or suddenly find some odd bugs in the codebase, but nevertheless we had two issues. One of them was that the archetypes were referring to snapshots versions and the other one a issue with one of the latest check-ins which went unnoticed through two unit tests particular to the issue and some amount of manual testing. Well what can I say, these things happen. We could have bumped up the version numbers of only the affected modules, but since that would have required more manual changes than just rolling out a new point release, we took the sure - and more automated - way. Most of the code is 100% the same as in 1.1, so we'll treat 1.1.1 as our official 1.1 release and just chalk up the earlier release as a fire drill Now, enjoy.
Right on schedule, we are releasing Trails 1.1! It feels it's been so long, even though it was less than six months ago we hit 1.0. I almost keep forgetting because I've been using 1.1 for months, but the single biggest difference between 1.0 and 1.1 is the modularized architecture. The documentation gives you an overview of the new modules, but the important thing about it is that it allows Trails to be used in more heterogenous use cases, independent of whether your project is using Hibernate or Acegi. Definitely cool stuff. As usual, Alejandro has done a lot of the heavy lifting in the modularization and various other areas. One of the other more visible changes he made is the new default user interface and layout that's designed to be compatible with AppFuse so users of that project should feel right at home trying out our examples. One more super-exciting feature he worked on is our first draft of full-text search based on Trails-Compass integration that we have a whole section about in the User Guide. The release history gives you a brief overview of the major features and a summary of the 30 bugs that were fixed in this release.
While the initial plan for 1.1 was to integrate with Tapestry 4.1.2, 4.1.3 contained important bug fixes for us and since it was released just recently, we decided to go with it for 1.1. Earlier unannounced and technically not part of the release, we've also quietly merged our Confluence-based site with a custom Maven site style, transparently blending Maven site reports with the Codehaus project wiki. For example and to see what other dependencies we've upgraded, check out the dependency report. Just as when I'm writing this, I can see Trails 1.1 is already available in repo1.maven.org. Enjoy and let us know how we can improve!
Let's see, what did I say in the last post? That "we get the improvements to the presentation layer for free". In the next point release of Trails, version 1.1, we've focused on upgrading the framework to use Tapestry 4.1.2. While the Tapestry core itself is great and stable, the new byte-code compilation enhanced OGNL has taken some time to mature. It's slowed us down a bit but once again, Alejandro has done a lot of ground work to make the upgrade happen and Jesse Kuhnert has been great at fixing emerging OGNL bugs. A lot can be said about Tapestry 4.x' learning curve but I doubt many would seriously challenge its position as one of the leading and most comprehensive Java web application frameworks at the moment. On top of it, Tap 4.1.2 introduces built-in integration with Dojo. In 1.1 we won't rely heavily on AJAX functionality, but we'll demonstrate some parts of it and we have great plans for it in future versions.
Not to make this post a praise on Tapestry, there's also a few other main features we wanted to introduce in 1.1. We are tracking those fairly closely on our simple roadmap and at this point the feature work for all of them is already done. One feature highlight is the security enhancements that provide a real, rigid security for Trails application out of the box - compared to the earlier light approach that was simply based on hiding the information from the view alone. Personally, I've grown to hate the "hello world" examples that demonstrate how super-easy it is to develop something simple with that new next-generation web application framework of choice, but then stop short of providing anything for those more complex, but equally critical real-world problems like providing security. We decided to tackle the issue by providing something for the typical scenarios, and so, as a result in Trails 1.1 a use case where a user can edit his profile (and ONLY his own profile) can be secured with just a single annotation. Not bad, huh? And of course, it's implemented with extensibility in mind. We call the concept "owner instance" -based security, where the currently logged in user is required to have some relationship with the entity he wants to view or modify. Are there any other Java web application frameworks that do the same out of the box?
The remaining items before we we are ready for a release involve collapsing the development branch to the main trunk, adding some test cases and then revising the documentation. Our informal estimates have been holding up surprisingly well so far so we are hoping to get the release out sometime this Fall for all of you Trailers!
PS. While I have no ambitions to make Trails the most popular Java web application framework ever, I'm a bit frustrated that Google still ranks the old trails.dev.java.net site way higher than our current trailsframework.org, even though we switched over a year ago and Trails has matured quite a bit since the early days. Linking to old material might be confusing for newcomers that are looking for a better way to implement web applications. What you can do, is to link to http://trailsframework.org and make sure you change/remove the old links. Thanks
At JavaOne this year, there was a presentation on "Grails, Trails and Sails - Rails Through a Coffee Filter". There's been a few comments on it scattered in various blog posts (at least http://www.juixe.com/techknow/index.php/2007/05/29/grails-sails-and-trails-rails-through-a-coffee-filter/ and http://blog.shinetech.com/?p=18), so it seems fitting to have some reply to it here. As mentioned in the blogs, I had the honor of announcing that I had just weekend before JavaOne tagged Trails 1.0 release.
Overall, I thought Trails faired well against the competition, and while the presenter used several months old version of Trails, he made a decent job demonstrating it. Only Sails doesn't seem like an active project, so mainly it was a comparison of Trails to Grails. The presenter mentioned that Grails is semantically closest to Rails and it's picking up steam compared to others, and that he's not sure if Trails is addressing enough pain-points. Certainly, even the whole Tapestry community is small compared to Struts or JSF, which already has an effect on the number of people interested in Trails or those who've even heard about it. But I'd have to disagree with the latter statement about pain-points. I've always thought that besides helping you to start quickly with your project (which all of these Rails-like projects do), the greatest strength of Trails is that it combines all of these state-of-the art frameworks into one and leverages their strenghts rather than introducing yet another way of doing things, such as the custom presentation layer in Grails. Tapestry has already solved some hard problems, like concurrency issues, caching the templates and re-using presentation objects, which allows us to focus on cases that none of the current web frameworks support: instance-based security, web flows, long conversations and modularizing the framework in order to have built-in support for different persistence layers etc. Currently, Trails uses Tapestry 4.0.2, but we are committed to moving to Tapestry 4.1.2 in Trails 1.1, and when new versions come out, we get the improvements to the presentation layer "for free".
Whenever these comparisons happen, there's always the question whether the separate projects could leverage each others or even merge. It's said many a times that it probably wouldn't have been possible to implement Trails-like framework without Tapestry, and so Trails is dependent on it. There's no way nor need for Trails to change to something else, and therefore couldn't merge with any other project. Similarly, Grails is married with Groovy - the project undoubtedly wouldn't exist without it. Groovy is cool though, and you could technically write Trails/Tapestry code with it, but it wouldn't help any when writing the Tapestry code templates - arguably the hardest but most powerful part of Tapestry. And that's final advantage of Trails: it is a remarkably flat framework, there are no additional layers obscuring you from customizing the application with the techniques available in each framework. So, if you are versed with Tapestry, Spring and Hibernate, it's almost a no-brainer to use Trails for a new web application.
After a year of development, with lots of changes in the team and project hosts, moving to Maven as our build system, re-writing most of the docs and fixing a number of bugs, we have finally made Trails 1.0 release! Follow the Quick Start guide to get started!
Archimedes Trajano tells us why he chooses Trails in his blog: http://www.trajano.net/2007/02/why-trails-is-better-than-rails.html
Over the past few weeks, you may have noticed things changing. The site has been moving to a new home at The Codehaus, and quite a bit has gone on as a part of that move. Here's a short list of what's been done so far:
- Site Content
Over time, the information for Trails has become spread out over several different sites, including java.net, inspiring.nl and a few others. This lack of a central document repository makes it difficult to get started with Trails. New users need to be aware of these different locations for things, and bounce around to collect the different information. As we bring that information together under the http://www.trailsframework.org banner, there will be a single source for all information about Trails.
- Source Repository
Codehaus provides excellent tools for managing developers and their contributions to Subversion through Xircles.
If you haven't seen FishEye, you owe yourself a look. Being able to subscribe to source repository changes with your RSS reader is a treat!
- Continuous Integration Server
http://ci.codehaus.org provides Continuous Integration services, and Trails is set up with Continuum. Over time, we expect Continuum to notify developers over IRC and mail when build failures occur, providing a higher level of usability for the source tree trunk.
- yDoc JavaDoc
Codehaus projects are licensed for yDoc, which generates navigable UML diagrams directly into the project JavaDoc. Over time, we expect Continuum to keep this updated automatically. The JavaDocs tell the entire story.
Some folks have started to congregate at irc://irc.codehaus.org:6667/#trails. Please feel free to join us!
And here are some things that still need to be done:
- Maven Repository
Very shortly, we should have the Trails artifacts available at http://repo1.maven.org/maven2/org/trailsframework. This will allow everyone to get trails without adding an explicit repository reference to their POM!
- Mailing Lists
Bob is working on getting the mail import finished. He's using RoR, so it's taking a long time Seriously, we're really excited to get the lists moved over so we can start to take advantage of the great tools in Xircles for list management. As a part of this, we would like to find someone who has an archive of many or all of the messages from the past. If you have ideas, please contact Brian Topping.
- JavaDoc Content
In an effort to make it easier to get involved with Trails, a push is being made to get the project documented. At the same time, some members are simultaneously bringing the code up to the JDK1.5 level and refactoring it for better readability. If you would like to participate, documentation is a great way for new contributors to come on board, in large part because new people see unfamiliar code with great vision for how to explain it. Please post to the dev list if you are interested.
- Jira Move
While Confluence has been moved and is being used to generate the site, Jira is still waiting to be moved. Please take a moment to participate by voting for this issue to be resolved in Jira!
- Site Redesign
It would be really great if someone with the HTML skills to redesign the site were available to help us make our site look great.
Interested in helping? Please ask!