Raible Designs

Maven 2's Transitive Dependencies

I spent a few hours this week integrating Maven 2's Ant tasks into Equinox. Here's a things I discovered in the process.

• The JAR you need to include to use the Maven Tasks is quite large, weighing in at a hefty 833K. Regardless, it's easier to include a ~1MB JAR in CVS than it is 10MB of JARs. Equinox (w/o the extras directory) weighs in at 10.2MB before, 1.3MB after.
• The transitive dependencies feature needs to be cleaned up a fair bit. There are a *lot* of unnecessary dependencies downloaded for many libraries. For example, Hibernate downloads a bunch of JBoss JARs and the Display Tag downloads all the various web framework JARs. I found myself excluding almost as many dependencies as I added.
• Using in-line dependencies (where you specify each one in your build.xml) is cleaner and requires less XML (b/c of attributes vs. elements). I went this route at first and it worked well, but to allow greater flexibility (for those who might want to use Maven 2), I ended up creating a pom.xml. 48 lines in build.xml turned into 195 lines in pom.xml.
• The Maven Developer team provides fantastic support - both on the mailing list and IRC. Thanks Brett!
• Maven 2.0 RC was released today.
• I need to figure out a way to "install" the persistence/web framework options in Equinox. The easiest way from a maintenance perspective is to parse pom.xml to add new dependencies. Entity includes might make the project more extensible though - and easier to upgrade.
• Once you have pom.xml in place, it's pretty easy to make the build/test/package process M2 friendly.
• Maven 2 is faster than Ant.

Overall, it was a pretty frustrating experience, with lots of trail-and-error. In the end, I got it all figured out and the only "hack" I had to do was delete servlet-api-2.4.jar after copying dependencies into my WAR. This is b/c Ant is not smart enough to know that dependencies with a "provided" scope shouldn't be copied. I could probably have a 4th dependencies path to solve this, but deleting sounded easier at the time.

I'm not going to check anything in yet b/c I still have to modify all the installers to specify their dependencies. The main advantage I can see in using a download-dependencies feature is easier upgrading of dependencies. It'll also make a lot more sense in AppFuse b/c certain parts of project (i.e. appfuse-dao.jar) can be published as re-usable modules.

In the meantime, if you'd like to try out Equinox with this feature (works with both Maven 2 or Ant), you can integrate it into a CVS version with the following steps:

• In the equinox directory, create a lib directory and download maven-artifact-ant-2.0-dep.jar into it.
• Replace your build.xml with this build.xml (view diff against current).
• Download pom.xml and put it in the equinox directory.
• Delete web/WEB-INF/lib.

That's it! I'm sure some things can be improved - please let me know if you find any issues.

DWR and Script.aculo.us now included in AppFuse and Equinox

Last night, I integrated DWR into both AppFuse and Equinox. AppFuse has had Script.aculo.us integrated since 1.8.2 and it's been great to work with - so I added it to Equinox as well. I added these with the philosophy that it's easier to remove them than to add them.

Thanks to Joe Walker (DWR), Thomas Fuchs (Script.aculo.us) and Sam Stephenson (Prototype) for authoring (and supporting) these great open source projects.

Next up: integrating Ivy (or Maven 2's Ant Tasks) for downloading dependencies. Hopefully both will still allow bundling JARs in a release so both AppFuse and Equinox can stick with the 1-download-to-get-everything philosophy. The main reason I'd like to integrate a dependency downloading tool is to reduce AppFuse's size in CVS, as well as make it easier to upgrade dependencies.

Seam

I have to admit, there's something about Seam that intrigues me. Maybe it's because they put up a really nice-looking demo (I'm a sucker for eye-candy), or maybe it's because it seems to be well documentated, or maybe it's the fact that it's based on J2EE standard technologies (EJB3 and JSF). It could also be that I greatly respect the work of Gavin King (who's always been respectful to me when I asked Hibernate questions back in the day).

It could be the lack of configuration, but I think it's the simplicity that gets me. A POJO (Entity Bean), a Session Bean for your business logic, and a view page (w/ Facelets no less, which is very cool). Other new frameworks this year include Wicket and Stripes. While these frameworks look cool, I really like the idea of a full-stack framework much better (I do use AppFuse after all). Well done Gavin - Seam looks very cool IMO.

On a related note, I upgraded AppFuse to MyFaces 1.1.0 yesterday w/ minimal effort. You can grab the latest from CVS if you'd like to get started with MyFaces quickly.

The Display Tag Project is not dead

Despite the lack of support and code contributions, it's good to know the Display Tag project is not dead. Fabrizio has been doing a lot of refactoring lately, including Maven 2 integration and support for long lists. Nice work Fabrizio! In addition, it's good to see all the activity on the mailing lists. Thanks to all of you that've been answering questions.

[DJUG] Building an Open Source ESB and Ruby on Rails

Managing Chaos
Building an Open Source Enterprise Service Bus from Scratch

Bruce Tate got rained out in Texas, so Bruce Snyder and Jeff Genender are talking about building an ESB with open source software. Bruce and Jeff created this product in the last project they were on. I was lucky enough to work with them on it the first half of this year - but only after the ESB was created. The final product was very stable and the client loved it.

Bruce is a Geronimo committer and one of the founders of the Castor project. Jeff is also a Geronimo guy and is currently working on a JBoss Live book for SourceBeat. The problem that the ESB was trying to solve was fixing a horrendous data flow. A lot of the data flow was occurring between people's PCs, shared drives, FTP servers, HTTP Servers, web servers - and rarely were things automated. Bruce recalls one of his first days when he heard the trading guys yelling at each other to "close the spreadsheet".

The solution to the problem was building an Enterprise Service Bus (ESB) that performed the following:

• Centralized Management of Activities
• Powerful Scheduler
• Guaranteed Event and Activity Execution
• Durable Transactions
• Pluggable ESB Components for Activities
• Staging Database for Single Common Data Location
• Logging and Notification of Activities
• Proactive Response to Failed Activities
• J2EE Architecture - Provides for True 24/7 Uptime

The pluggable components were called transformers and were standalone JARs that lived on their own, but could be managed by the ESB. Notifications were key so the traders would be notified when something went wrong.

Architecture

Scheduler (Quartz) » Workflow (jBPM) » Persisted Guaranteed Messaging (JMS). JMS talked to Activities (a.k.a. transformers).

The Quartz Java Scheduler is an open source project from OpenSymphony. It's a persisted scheduling engine, so it'll live through app server restarts. It also has millisecond granularity.

For workflow, the Java Business Process Manager (jBPM) was used. It doesn't use BPEL, and was used to track multiple activities and make decisions based on an activity's completion or failure status. Other functionality included tracking the activity state (running, cancelled, completed) and sending/managing notifications. Workflow was very important because the previous system had no way of detecting where things failed in a process. With the new system, downstream dependencies were handled, the escalation path was based on success or failure - and automatic retry occurred on failures if the failure reason was a known and configured expectation.

For messaging, JMS was used - implemented with EJB and MDB. This provided guaranteed and persisted messages. Events were automatically recovered if the server failed.

Activities/Transformers were pluggable components (wrapped with EJBs for transactionality). The nice thing about using EJBs was it was easy to create JARs for each transformer, drop them into JBoss and they'd immediately become available.

The system was all managed with a management console, that was a webapp implemented in Struts, Spring and Hibernate. Most of the Spring and Hibernate classes and configuration was generated with Middlegen and XDoclet. The management console allowed you to kick off activities, monitor their progress, as well as manage users with Active Directory and single sign-on with NTLM and jCIFS.

Solution Facts

Since December 2004, over 200,000 jobs have been run through this system. Of those, 500K activities have been run, with < 10,000 failed activities (2% failure rate). Nearly all failures were due to external issues, such as unavailability of remote systems and databases, or source files not available.

Tools and APIs Used

When Jeff showed up, it was a Microsoft shop using ASP, Visual Studio and some PowerBuilder. They brought Jeff in to help them use and adopt open source. The first thing they did was install and begin to use CVS (previously source control was done on shared drives). They also used Maven to build everything and produce a project site - which the managers and C-types loved. One thing they mentioned is they often got questions from higher-ups like "How much does it cost?" They did have problems with Maven, but it was mainly due to the poor documentation. They found a lot of Maven solutions by cracking open plugins and looking at their Jelly files.

Development Lessons Learned

Configuring EJBs and MDBs as singletons helped solve some problems (a JBoss setting allows you to configure this). As for running Spring in a heavily-managed environment, they found that setting singleton="false" solved a lot of problems. The next problem they had was mixing Hibernate and JTA Transactions. No details, just that they had an interesting time and it took them a few days to get it working. The last problem they encountered was using Hibernate and/or Spring JDBC to manage hundreds of thousands of records. Since these O/R tools create objects for each record, OOM errors occurred with large resultsets.

Business Lessons Learned

All notification messages came from the ESB, leading many to believe the problem was the ESB - rather than the data sources it was talking to. By using open source, they saved the company $500K in licenses fees. The interesting part was the company had a 3rd-generation agreement with IBM, and owned $12 million worth of licenses for WebSphere and WSAD. The reason this group used open source was because there weren't enough licenses.

Bruce and Jeff's presentation was good, but they looked like a couple of goofballs standing up there in their t-shirts and shorts (standard Virtuas gear). I guess that's what happens when you get a 2-hour notice. The worst part about the presentation was the fact that the A/C doesn't work and it's about 85° in here. I told Geary he'd better keep in short or I'm outta here.

Ruby on Rails
David Geary

David got into Rails by reading an article called "Rolling with Rails". In the article, the author claimed that you can develop webapps in Rails at least 10 times faster than in Java. David responded to the article on his blog with an entry called the Ruby on Rails Koolaid. He experienced quite a butt-whooping from various folks, including Rails' founder - and realized afterwards that the claims might be valid. After working with Rails, David believes that Rails is probably 5-10 times faster.

Ruby

Potent mix of SmallTalk, Perl and Python. Everything is an object. No static type checking. Duck Typing (talks like a duck, walks like a duck, it probably is a duck). Testing usually solves the lack of static types. Blocks - like anonymous inner classes, but retain state. Mixins - a cheap way of doing multiple inheritance. Dynamic classes - can modify at runtime (add methods, renaming methods, etc.). Rails takes great advantage of the dynamic attributes as part of its framework.

David is now showing a ContactsController that has 5 methods for CRUDing a Contact object. 4 of the 5 methods are one-liners. It kinda reminds me of my Hibernate DAOs after integrating Spring.

Rails

Ruby-based MVC framework. Convention over configuration. Scaffolding - builds pieces of your application for you. ActiveRecord does O/R Mapping. Has a built-in testing framework. Near-zero configuration (no XML). Zero-second deploy time (development environment).

David's first demo is being done by audience member Kirk. David asked for a volunteer from the audience with MySQL experience, and the ability to type in a few commands. David said his 6-year old daughter was able to do this demo last night successfully - so Kirk's gonna look pretty bad if he can't pull it off.

Using scaffolding, Rails generates 1 controller, a test for it, a helper class, a css file and 5 rhtml templates. Kirk pulled off the demo, even though he had a bit of trouble with the Mac environment. This is a lot like AppFuse's AppGen in a sense - except AppGen has to parse a bunch of XML files and reconfigure them.

David keeps hammering that the most productive feature of Rails is that there is zero deploy time. Save. Refresh. It looks very similar to developing a static HTML site.

Rails has ActiveRecord, ActionPack (MVC), ActionMailer, ActionWebService, Ajax Support, Transactions and Security. Currently at version 0.13.1 - the last version before 1.0.

David is delivering an excellent presentation, but it's too damn hot without A/C - I'm outta here.

[JavaOne] Tapestry in Action

Last night was much milder than the previous night, and I actually feel pretty good today. I'm sitting in Howard's Tapestry in Action session, having just missed the session on Shale. This is a introduction to Tapestry, but it seemed like the most interesting session for this time slot.

Yesterday was a long day, mainly because of the Bomb Squad festivities from Monday. I did a book signing and actually managed to sign a few books. Spring Live is now #11 on the best sellers list at JavaOne.

Last night was a good time. We hit the Mergere party and learned a bit about Maven 2. It was cool to learn that Ant 1.7 is going to include Maven 2's dependency resolution. From there, we tried to go to a session on APT, but the room was packed and lacked A/C, so we bailed. From there, a whole slew of us (from Virtuas) went to a Southeast Asian restaurant that served excellent food, family-style, for hours on end. We hit the Tangosol+Solarmetric party after that and closed down the place. Click on the image below to see a bunch of pictures from the event.

Tonight, there's a big party at Moscone - complete with comedian Dennis Miller.

XDoclet for JDK 5

From the xdoclet-user mailing list:

I just uploaded a snapshot of xjavadoc that (among other fixes) provides support for Java 5, as of XJD-41. Many thanks go to Anton Adamansky for his work on this issue.

You should be able to just replace the xjavadoc-1.1.jar from a Xdoclet binary release with this snapshot and use jdk1.5 features with Xdoclet.

Have fun,
  Heiko

Let us know if you find any issues.

Notes from DJUG: Rhythm and Open Source Strategies

Last night I had the pleasure of listening to two great speakers at Denver's JUG. Not only did Brian and Lajos know their stuff, but they were very comfortable on stage and interesting to listen to. Below are my notes from this event. When I did a print preview of this in Dreamweaver, it came out to be 5 pages - so just to warn you, this is a pretty long post.

Brian Boelsterli - Nudging your organization towards agility: Ingredients for an agile execution environment

Even if you have a dream team of developers, it doesn't mean the project will succeed. Process Matters. A lot of what Brian's Rhythm process was developed while working at Sprint - where they completed 169 iterations on their way to production. There are problems with agile methodologies: team has no rhythm (restart, pause, delay all the time), project plans are big and heavy and just about worthless, methodology teams get in the way, specifications are close to worthless, design review meetings are horrible. In order to combat these problems (regardless of your methodology), Brian has developed a Rhythm Process that helps agile methods succeed. This system contains a number of ingredients to solve problems with agile methodologies.

The Heartbeat is the logical representation to the physical thing called an "iteration". Starts Thursday morning, ends Wednesday night - based on psychology b/c it fosters sustainability. By giving 2 days to start a new iteration, they've found higher productivity because no one wants to work the weekend.

Rhythm advocates weekly iterations, regardless of deliverables. The primary reason for this is to maintain the heartbeat. Rather than doing XP-type iterations where you do everything in an iteration, you do Stacked Iterations. In an iteration, you still do full lifecycle (requirements, development, deploy), but the Business Analysts are 1 iteration ahead of the developers and the developers are 1 iteration ahead of the deployment team. In Rhythm, there's an Iteration Advocate who gathers and manages requirements, Developers do the development, and the QA team does automation and deployment. I've worked with this system in the past with Brian and this process works quite well.

Iteration Advocate: Traditional "Process Mentor", in disguise. They're responsible for making sure the spin happens and the work gets done. Responsible for one thing: Ensuring the successful delivery of each and every iteration. A big reason that Rhythm advocates this role is because they've found that Project Managers tend to spend 80% of their time doing PM work. By having this role, the PM can concentrate on managing the project and doesn't have to be concerned about managing people and their deliverables. As part of each iteration, artifacts are produced. This makes it possible to put the project in hibernation at any iteration transition point.

Software Iteration Plan (SIP): A simple artifact that includes features and tasks, as well as defects to fix for each iteration. As part of the weekly planning, this artifact is re-visited and updated. Depending on how formal your organization is, this document can be kept on a wiki site, in a word document, etc. Meetings are held every Wednesday afternoon - where PMs sit in a room and team members come in and report their status.

Iteration Transition Meeting (ITM): Backbone of the process - happens every Thursday morning and involves all parties involved in the project. Similar to SCRUM's Post-Sprint Meeting. It's an official buyer/seller marketplace for cross-functioning teams to buy/sell iteration artifacts.

• Definers are selling their requirements, analysis and design specs
• Developers are selling their functionality
• Testing are selling their test plans and specs

Participation requires a minimum of one representative from each respective group. Project Manager conducts, Iteration Advocate facilitates. Brian says this meeting has virtually eliminated the need to do status meetings.

From working with Brian, I know that one of the key ingredients to this process is the Testing Team. The folks that typically fill the QA Developer role is on a whole new level from most testers I've seen. Rhythm Testers are automation experts and know how to setup CruiseControl, run Ant/Maven/Unit tests, as well and configure and deploy to production servers. These folks are the ones who handle the initial installation and configuration of the test, development and production servers.

As part of Rhythm, it's also important to plan for "Featureless iterations" - where nothing is done but run performance tests and regression tests. Done at both 40% and 60% project completion. This was a good presentation about an excellent process that I still try to use today. In my experience, the hardest part to implementing it is finding good QA Engineers that are automation experts as well. Nice job Brian!

 » Download Presentation (PPT)

Lajos Moczar: Creating A Successful Open Source Strategy

Lajos is a committer on OpenEJB and has written two books: one on Cocoon and one on Tomcat. Lajos has been working with open source since 1995 and has a company called Galatea Information Strategies in Colorado Springs. Lajos mentioned that he recently became well-known in the open-source world by writing a paper titled "Start developing and deploying J2EE apps on the first open source J2EE server". This title apparently pissed off the JBoss guys to no end, their PR Firm called JavaWorld and they renamed it to A first look at Apache Geronimo. Because of the JBoss controversy, Lajos became inspired to write The open source monopoly, which explains why he thinks doesn't think JBoss is open-source.

NOTE: The big reason Lajos doesn't like corporate-backed open-source is because he feels that quality app servers like JOnAS deserve lots of press too. However, they don't have the marketing dollars that JBoss has, and are therefore overshadowed. He also mentioned how dangerous it can be when a project's committers get so full of themselves that they start veering from a standard (i.e. J2EE) and developing their own add-ons. If companies and developers use these add-ons, it leads to Vendor Lock-in, which is the same as the lock-in you find in commercial products with proprietary APIs.

Bottom Line for open source adoption: Open Source is mature for the enterprise, as long as you're mature in your approach to it.

The state of OSS: Over the past past 4-5 years, OSS has gone from youth to adulthood. Now a viable choice for large-scale organizations, common talk in business and news. Recent report from CSC on enterprise usages of OSS:

• 70% have Linux and/or Apache
• 42% are using Tomcat
• 14% are using PHP

OSS in young adulthood, where childhood was free software, not a thread to the mainstream. OSS was born of the hacker culture of the 70s (and earlier). Richard Stallman and GNU dominated open source in the 80s and early 90s.

In Adolescence, open source went a big crazy (late 90s). The Big Split was when open source was redefined as a methodology instead of a culture. Eric Raymond, Netscape and the launch of "commercial" open source. Open source != free software. Open source + the Internet = Linux, which leads to popular access to open source.

Now in Young Adulthood, where there is an explosion of choices (in Operation Systems, Containers, Technologies (i.e. PHP, Perl, Python, etc.), Web Frameworks). 34,000 open-source projects on freshmeat, 86,000 on sourceforge. There's also an explosion of licenses. Explosion of technological advances in web services, Java and development technologies. This has all resulted in an explosion of adoption in many large organizations.

Is OSS Mature? Open source faces a crisis of maturity:

• Does it achieve the ideals of its origins and stay as a separate force in the technology world?
• Does it get subsumed by the increasing trend of corporate open source?

With the "corporate open source" model, the project is essentially a product, except that it's free and and you can see the source. Are we losing the intrigue and excitement that the 2:00 a.m. developer experiences? The "corporate open source" model seems to discount the roots of open source - when developers stayed up until the wee hours of the morning to develop something they were passionate about. With the corporate model, it becomes their job and could lead to a loss of passion.

Some Challenges: As OSS matures, there are challenges that face OSS implementers, particularly those in advocacy/evangelization roles. Inherent problems - a lot of releases (difficult to keep up), is it really free, etc.

More Challenges: Overwhelming choices (choose a languages (Java, Perl, C#, Python, C++) , choose a direction w/in a language (i.e. Java 1.4 or 1.5) , choosing a technology direction (J2EE or just part of it - sans EJB).

After this overview, Lajos went into an example of how open source is typically adopted in an enterprise. It starts off with a web application pilot, where a developer downloads Apache + Tomcat, spends a day getting them talking to each other, and then configures everything using the default settings. From there, an application is developed w/o code or directory structure standards, without security and without failover solutions or backups. Nothing is documented as development ensues. This pilot becomes a production application and the IT organization has no idea how to support the application, and new developers have no idea how to maintain it, or start a new project based on the same architecture and tools. Bottom line: using a pilot like this is an irresponsible way to introduce OSS to your enterprise.

Typical OSS Introduction problems: The first step towards successful OS is organizing the problems or "challenges". Use of technology problems, process problems and choice problems. OSS has the strange effect of highlighting inherent problems in your enterprise or IT strategy. These problems can be fixed.

• Technology problems: Technologies come and go, but the core business stays the same. What is important is that you know how to use and what you choose. Commons IT mistakes: The latest and greatest, bleeding edge software, technology for the sake of technology, instead of for the business. Sounds obvious, but you must always start with one question: what is the purpose of IT?
• Process problems: OSS highlights already existing process problems b/c it's very accessible, tends towards permutations in options and versions and there's less work done in the way of best practices than we need. You need a solid infrastructure - processes and principles - to handle the problems with OSS and to insure complete success with it. More than ever, this is the time for process: no OSS implementation should be w/o them! Develop, test, upgrade, deploy, etc.
• Choice problems: Factors influencing choices: technology direction, project viability and health, knowledge base, license type, corporate sponsorship, "spirit" of founders.

Principles of a Pilot: Your pilot is the most critical step in OSS implementation. The pilot must demonstrate: sound and viable technology choices, solid processes and principles, vertical slices.

Starting a web pilot right: Research the options: which version of Apache/Tomcat/MySQL is the most stable (use mailing list). What is the proven integration solution, security "best practices", licensing concerns? Are there documentation concerns? Do you have to pay for it? Is it any good?

When starting with open-source you need to plan, plan, plan.

• Organize your directories for repeatability, ease of maintenance.
• Separate program directories from development directories from deployment directories
• Document all configurables, installation quirks, directory locations
• Define a solid and repeatable build process
• Never take all the defaults! Determine what to change.

Authentication and Security. Problem: multiple logins is the curse of the modern enterprise - don't reinvent! Use single sign-on if possible. Don't have an LDAP server, install one! Kerberos is a good option if you are starting out: a bit of work, but worth it. Problem: OSS is not inherently more secure than anything else. Solution: research for the most low-risk products. Keep currently with he project bug lists and security announcements. Subscribe to all relevant mailing lists.

Development processes. Problem: Need a development process for OSS-based applications. Solution: Use CVS with replication (CVSUP). Use Ant/Maven with a well-documented target/properties schema for builds. Implement a three-stage process, of development, QA and production. Create a simple process for tracking application releases and enabling rollbacks.

While listening to Lajos talk about all of this stuff, I couldn't help thinking to myself that AppFuse solves a lot of these problems for you.

Understand the Pitfalls of OSS:

Version mania and product instability: establish your own release criteria and testing plans. Always upgrade with a rollback plan. Once you find stability, keep it!

Lack of product infrastructure: Great products are useless w/o the proper infrastructure. If any of the following don't exist around an open source project, it's a warning sign that it might not be ready for prime-time.

• premier documentation (i.e. books)
• training services
• tiered support services
• integration services
• security alerts
• intuitive administration and operator interfaces
• interoperability testing - does the release announcement provide upgrade paths?
• load testing
• release criteria (i.e. basic interoperability testing, tested functionality, etc.)

Free software is not really free - there will be costs:

• Training
• Consulting
• Hardware
• Support

Flavor-of-the-month technologies: ask the hard questions about any technology, jumping on the bandwagon for its own sake will be expensive, older proven technologies are often better. Ruby on Rails fits into this category.

Corporate open source and branded technologies: beware brand names backed by VC funding - they could end up being monopolies. Can lead to Vendor Lock-in. Beware of technologies dominated by a single entity. Standards are the best way to prevent this from happening. The best solution: community-driven standards - complete with best practices.

Open source or "free" software requires the same approach and dedication as does commercial software:

• Software infrastructure
• Training, documentation, support
• Sound implementation, upgrade, support processes

At this point, Lajos gave his recommendations of good open-source projects that are ready for enterprise adoption. I wasn't fast enough to write down the ones he mentioned for Security, Integration and End-user applications. He did say he'd post his slides, so hopefully I can fill this list in later.

• Operation System: RedHat/Fedora, SuSE, FreeBSD, OpenBSD, Mandrake
• Data: MySQL (note the license), PostgreSQL, MaxDB, dbXML, Xindice, eXist, Castor, Hibernate
• Security
• Web Services: Apache SOAP/AXIS, Tomcat, Jetty, JBoss, JOnAS, OpenEJB, Resin, Geronimo, LUkAS, ebXML, Jabber, SIM, CryptIM, Magpie (PHP RSS), Jena, ircd, OpenCMS
• Integration: JMS (OpenJMS, SwiftMQ)
• End-user: Firefox, Open Office

Implement: Once you have organized your choices, divide and conquer. Determine what you will keep commercial: mainframe apps? High-end database platforms? Take one slice at a time: database, communications, server platforms, end-user platforms, web services, networking, etc. Be careful of tightly integrated components.

This marked the end of Lajos's (very enjoyable) presentation. I've known of Lajos through his Apache+Tomcat FlashGuides, so it was very cool to meet the man behind the knowledge. It's also pretty neat that we're both doing the same line of work. I hope to sit down and have a beer with Lajos in the near future. During the QA Session at the end, I picked up a couple of audience tips: Google has their open-source code at code.google.com and Revolution OS is a good movie to rent.

 » Download Presentation (PDF)

This is one of the best Denver JUG meetings I've been to in a long time, and this summer looks like it'll be packed full of good sessions. July's JUG Meeting is going to be awesome: Bruce Tate talking about Beyond Java followed by David Geary talking about Ruby on Rails.

AppFuse 2.0: JDK 5, Annotations and JSP 2.0

For the most part, I haven't used JDK 5 on any of my recent projects. You can compile and run AppFuse with JDK 5, but it doesn't use any JDK 5 features. After doing a code review at Bouvet last week and seeing how much cleaner their code is with Generics, Varargs and the Enhanced for Loop, I think it's time to dig in. I don't know how soon we'll start, but I think it's time to start creating a branch for AppFuse 2.0 - which will use these features. For AppFuse 2.0, I'd like to go whole hog, bleeding-edge and use all the stuff that's out there to make developer's lives easier. This includes JSP 2.0, Annotations (especially for Hibernate and Spring, as well as Tapestry) and all the JDK 5 features that seem useful.

Since most developers won't be able to deploy on a JDK 5-compliant server for quite some time, we'll continue to maintain the 1.x branch as JDK 1.4-compliant. I expect to release AppFuse 1.8.1 later this week (with mostly bug fixes + latest releases of Hibernate/Spring) and 1.9 in the next month or so. From there, we'll likely do 1.9.x releases with bug fixes and do all the major upgrades (i.e. Tapestry 4.0.x) in the new branch. Working with new features in JDK 5 should be a lot of fun.

I'm hopeful that we can get rid of XDoclet and we may even give Maven 2 a run for its money. Last week in Norway, I found that most Java developers were using Maven on their projects and I also discovered that many of the core Maven 2 developers are getting paid to work on it full time. There were even claims that Maven 2 is going to be twice as fast as Ant - which definitely intrigues me.

Later: I just realized the hardest part of this migration is going to be replacing AppGen. It currenly uses XDoclet templates for all the class templates - and we'll need a new solution based on annotations. Oh well, it's kind of ugly anyway, but it'll likely be difficult to figure out a new solution. Hopefully we can create some sort of tool that involves easy-to-customize templates and a GUI to drive it all.

Why Wicket looks cool

I like the looks of Wicket for a couple of reasons - without even using the framework yet.

• Its project homepage looks good. If you're using a Java web framework, chances are you're developing UIs too. If you don't know how to make sites look good - it's time to find a new line of work IMO. Of course, learning how to make good-looking UIs is another option.
• Its Wicket Stuff project. It provides Hibernate, fValidate and Spring integration. It also appears to provide an option to use Velocity for your templates. I'm not sure what the Velocity integration provides - since HTML templates (ala Tapestry) should do everything that's needed.

What I don't like about the project:

• The Buzz page has a quote that's (apparently) from this site. Unfortunately, it looks like I said it - which I didn't.
• There's no books being written about it. If it's really that good - where's the books? Ruby on Rails will have 3 by the end of this year. Any good framework should inspire books to be written about it.
• The Wicket Stuff project has no documentation. Javadocs don't cut it. Tutorials are king.

I hope this project succeeds - Tapestry needs some competition and I don't think JSF is providing it. If JSF adds HTML Templates (or I figure out how to use Java Studio Creator to manage an AppFuse+JSF project), that's a different story.