Seam 2.0.0 CR2 is now out. You can find it here.
This is the first release we've done under the new maven-ized build system. Not only does it help us track our dependencies better, but it has helped use to trim back the JAR bloat from CR1. We're still working on reducing the download size furthe, for those who don't want all the examples and all of their many dependencies. If you just need the latest JARs, remember that you can get them directly from the repository.
We have been extremely pleased with how thoroughly the Seam community has been looking at CR1. We've diligently attacked all the issues reported, and that's made this release very solid. If we've missed something, please let us know so we can fix it before the GA release.
Speaking of the GA release, when will it be? We expect it will be about a week. If you check JIRA, you'll see we are going to be working on the documentation over the next week. We are also taking to heart our need for more and better testing, and the entire Seam team will be taking a few days to crank out tests and improve our test suite. We realize everyone out there wants the GA release out quickly, (trust me, nobody wants that more than we do) but we think the few extra days of wait will be worth it.
Oh, and before I forget, I want to take a second to welcome our newest Seam committer, Dan Allen. Dan has been contributing quite a bit to Seam, so we're very happy to have him as a committer.
Unfortunately seam-gen doesn't run ootb, you need to run ant build /before/ running seam-gen. Apologies for that!
You can find the JBoss Maven Repository here and, for example, Seam UI here.
Woops. We need to look at the release procedure to see how that slipped through. Still, there's a reason why we did a CR2 here - to make sure all this stuff works before it goes out to everyone. To any observers, if you are NEW to seam, it might be better to wait a week for the GA release so we can get all the kinks out of the new release process.
Thanks for your hard work, guys!
Very glad to hear about the coming test suite improvements. Much more important than a quick release, IMO.
Guys,
Seam may demo superbly on the JBOSS site...and it looks great. But with ZERO IDE support this product is going nowhere. If you cannot produce code that can be loaded into one of the mainstream IDES like Netbeans Eclipse etc, and simply 'run' then nobody is going to use what you have written. It's 2007 and people are way beyond hacking their IDE to bits just so your stuff can be made to run. That's not the way it works any more. Please do something...we want to use Seam but do not have the time to lose just trying to load it in an IDE...we actually have real work to do.
Thanks.
Andy, you'll be pleased to know that Max and his team have been working hard on some excellent Eclipse integration for Seam. Check it out here. This first version has got autocomplete for EL everywhere, project creation wizards, hot deployment and packaging support. It's pretty stable now :)
And there is lots more in the pipeline!
Please don't include transitive dependencies in the .poms that get deployed in your public repository (like this one http://repository.jboss.org/maven2/org/jboss/seam/jboss-seam/2.0.0.CR3/jboss-seam-2.0.0.CR3.pom).
Why? Because if I inadvertently end up using your repo to download artifacts for packaging, I run the risk of picking up jars that break my app. For example, seam-ui declares a dependency on el-api.jar - packaging this in my war causes class loader exceptions in a war that worked fine prior to builds based on the CR3 stuff. Yes, I know I can put exclusions, but how is it better to have a pom that not's correct and then having to spend time to undo the broken stuff?
Please don't include transitive dependencies in the .poms that get deployed in your public repository (like this one http://repository.jboss.org/maven2/org/jboss/seam/jboss-seam/2.0.0.CR3/jboss-seam-2.0.0.CR3.pom).
Why? Because if I inadvertently end up using your repo to download artifacts for packaging, I run the risk of picking up jars that break my app. For example, seam-ui declares a dependency on el-api.jar - packaging this in my war causes class loader exceptions in a war that worked fine prior to builds based on the CR3 stuff. Yes, I know I can put exclusions, but how is it better to have a pom that not's correct and then having to spend time to undo the broken stuff?