We'd like to thank everyone for their comments - on twitter, on IRC and in the comments section. There have been some excellent concerns raised, and, believe it or not, those same reasons are at the heart of why we want to make the changes we discussed here. We have exactly the same concerns the community has raised.
We would like to reassure everyone on a few points:
- We are convinced that one of things that drove people to adopt Seam 1 and Seam 2 was strong focus on how to build real applications. We are well aware that Seam 3 hasn't offered that and we want to focus on providing that
- We still believe in portability and standards, and we want to take the knowledge we have about building portable standards and applications out of the Seam silo, and to the rest of the Java EE ecosystem. We will continue to standardise APIs and ideas that we believe are necessary
- That we love the Seam community and their passion and that we want bring this community into the heart of the Java EE community, where it belongs
- We will ensure that apps built using Seam 3.x will continue to run. We will continue to support anyone who wants to build a CDI extension
However we made a mistake. We told you about the outcome we think is the right way to address this. We didn't tell you why we want to do it, or how it supports these goals. We don't want to jump right in with a half-baked position right now, and make that mistake again. So we ask that you give us the benefit of the doubt, and trust that we do have the community's best interests at heart, and watch this space for the whole picture over the next couple of days.
I'd like to take a few moments to update everyone on what is happening within the Seam project, and to clear up a few rumours that have started to float around before they start to balloon out of control (how do these things start up anyway???). As some of you might know, we recently held a JBoss face to face meeting in Toronto, Canada where besides consuming vast amounts of alcohol and staying up into the wee hours of the night coding and talking about important stuff like politics and humorous YouTube videos, we actually made a number of important decisions about the direction and focus of the Seam project as a whole.
Over the years, Seam has evolved by quite a substantial amount - if you were to ask the core team members for an executive summary of what Seam was, then the answer would have changed every year. In the very beginning, Seam was intended to solve some of the shortcomings of developing applications with JSF and EJB (and unfortunately this is the impression that has stuck with many people, even until now). It quickly grew into a powerful DI component framework, and more and more features have been added over time. It has spawned quite a number of innovations and sister projects - CDI, Weld and Arquillian to name a few. I'm also pleased to say that Seam is successfully powering many, many production web sites and rich internet applications today.
So, that brings us to the present. In the latter part of 2011, what is Seam's focus, and what goals does it set out to achieve? Well, let's start by looking at the goals it has already achieved. The core features of Seam - dependency injection, contextual component model, event bus, interceptors, i.e. the frameworky
stuff has all been standardised as JSR-299 (CDI). Since this is now all part of the Java EE specification, and comes as standard in any compliant Java EE6 container, we now have a fantastic foundation to build on. However, it is just a foundation - as an experienced home renovator I know that the foundation is the most important part of building a structure, however having a foundation alone doesn't give you a place to live - you still need to build a house on top of it.
That's where Seam comes in. It helps you, the developer, by providing the tools and materials necessary to build a house on top of the CDI-based foundation. It does this by integrating various useful libraries - libraries that are important for everyday application development - with the CDI component model so that you can write one kind of stuff
, to coin a phrase that Gavin came up with quite some time ago.
But wasn't this already the goal of Seam 3?
Well yes, yes it was. But we've recently come to the conclusion that the Seam project shouldn't be a destination, it should be a journey. Ooh, so Zen!!...but what does this mean? Well, let me explain - Seam's goal is all about supporting the CDI ecosystem, and promoting CDI Everywhere
. Why? Because, if we're all building our tools and libraries on the same standards-based component model, then we're all going to be much more productive when it comes to developing our rich internet applications. So, in light of this goal it doesn't make sense for Seam to be gathering crops - rather it should be planting seeds. In other words, there are many modules currently in Seam that we think would make better sense if they were situated somewhere more closer to home
, so to speak.
Let's take a look at a concrete example - the Seam Persistence module. This module provides an extension-managed persistence context, useful for when your project needs to inject an EntityManager into a POJO bean, or if your persistence context needs to last longer than a single request. These are features that we consider to be essential for day to day application development. But in light of the goal of strengthening the CDI ecosystem, do these features really belong in Seam? At JBoss we have another well known project which deals with EntityManagers and persistence contexts and other databasey-related stuff - perhaps you've even heard of it (I'll give you a clue, it starts with H
).
So instead of Seam trying to capture
all of the CDI extensions in one place, like Pokemon, we should be trying to propagate them throughout the greater developer community instead. To that end, our focus is going to shift somewhat, and we've already made some concrete plans towards achieving that goal. Here's a few of the changes that we're proposing:
- Seam Persistence - Move into the Hibernate core project, re-brand as
Hibernate CDI
- Seam Validation - Move into Hibernate Validator, make CDI support part of the core offering
- Seam Wicket - Moving into the Wicket project itself, this is already in motion
- Seam REST - Moving into the RESTEasy project
- Seam Faces - Moving into RichFaces as a standalone
Faces CDI
integration library
As a part of the Seam community, you may have concerns that these changes might fracture the Seam project, or the community itself. I'd like to address this concern up front, and say that what we want to achieve is the exact opposite of this. Our aim is to broaden the existing community, by working closer with other projects to achieve a common goal. The current module leads will stay the same, however they will be working together with the other project leads to deliver native CDI support directly from their project. The end of result of this can only be a positive gain, as projects take more ownership of their own CDI integration, and work more closely with the Seam developer community to leverage the experience we have at building CDI extensions.
Seam's role in this new world
So while some modules may graduate from Seam to become part of the broader CDI ecosystem, there are still many features that are unique to Seam itself. These modules will remain within the Seam project for the foreseeable future, and Seam will continue to be an incubator for innovative development solutions and ideas. We still have much work to do, and many ideas on how we can provide new value-added features to Seam for our users.
So will there still be Seam releases?
We are planning on our next bundled release (3.1) to be our last. Note I said bundled
- this release is basically a big zip file that contains the latest versions of all our modules. With our new focus, the bundled release just doesn't make a whole lot of sense any more. What we will continue to do however, is release each Seam module whenever it has received enough bug fixes and feature updates to warrant a brand new release.
From what I have heard personally, most of our developers are using Maven for dependency management anyway and so this change isn't going to make an iota of difference to them.
In Summary
So to sum up, Seam is not going away, rather its new goal is to unite the CDI developer community, and it will continue to foster innovation and encourage new ideas and improvements. If you have any questions or concerns about this, I look forward to addressing them in the comment section below.
