I’m very happy to announce the details for the first phase of our Seam.Next plan. I’d like to thank everyone for waiting patiently while we worked on this, and for providing feedback either directly via e-mail or IRC, or through the Seam forums. I’d also like to thank the module leads, key community members and other people that were involved in helping to shape this plan, it was very much a collaborative effort and we are very excited about the ideas and goals that were discussed and direction going forward.
Before I get into the nitty gritty of the details, I’d first like to describe the motivations for wanting to make such significant changes, and talk about the overall goals that drive us. I think the best starting point for describing this is Seam 2.
Seam 2
Looking back at how we did things in Seam 2, I think it’s safe to say that many of the aspects of the framework were quite successful. I think that one of the most defining factors of its success was the integration - Seam 2 provided the core framework features (Dependency Injection, Contexts, Events, etc) and enough useful features built on top of that core framework to make application development quite a productive activity.
It also provided integration with a number of third party technologies, such as Drools, jBPM, Wicket, Spring and others. On top of that, it provided excellent documentation that tied the whole lot together, and did a pretty good job of bringing new developers up to speed, and not to mention decent tooling in the form of seam-gen and JBoss Tools.
All in all, Seam 2 has proven to be a mature, well rounded framework that solved many of the problems that developers face when building modern web applications.
Along Came CDI
CDI changed everything. By standardizing many of the core framework features of Seam and making them part of the Java EE platform, with an added focus on type-safety and extensibility, there is no longer a requirement to BYO framework - any compliant Java EE 6 container provides a comprehensive programming model out of the box, without having to supplement it with additional libraries to provide core services.
This was a great step forward - writing your application against a standard is a good thing. It helps you to avoid vendor lock-in, and means that as a developer your knowledge is portable. It also puts you into a great position for tapping into a growing ecosystem of extensions and tooling.
CDI Everywhere
Since CDI was released, one of the principles underlying all our work is that of CDI Everywhere. By enabling CDI support in as many places as possible, our goal is to make developer productivity stronger than ever. To that end, we have been encouraging and assisting other project teams to provide CDI integration directly from their own projects. We believe this is one of the key ingredients in strengthening the CDI ecosystem, and providing an environment where the developer can concentrate more on solving business problems and less on fighting with his tools.
This of course means that you no longer require an integration framework like Seam to provide support for a number of CDI-enabled technologies, such as Drools and jBPM (CDI support coming soon), GWT, Wicket and many others. Furthermore, since the tooling we provided for Seam 2 (i.e. seam-gen and JBoss Tools) was based on its proprietary core framework, any new tooling going forward should naturally be focused on the now standards-based component model provided by CDI. This is the reason why Forge is now a standalone, top level project in its own right, with a focus on building Java EE applications.
Seam 3
Looking at the previous diagram, we can now see that as a result of standardization, quite a few of the bits that made up Seam have moved outside the scope of the original project. This has meant a change in focus for Seam. Instead of providing a fully integrated framework stack, Seam 3 has taken the remaining bits and turned them into a collection of portable extensions for CDI. Essentially, what we did was implement many of the most useful features that were present in Seam 2, as well as adding a number of new features, in a modular structure so that Java EE developers can easily add support for these features to their application by simply dropping a jar file into their project.
At this point, in hindsight we think we made a poor choice here by calling this new project Seam 3, seeing as the nature of the project has changed so drastically from the previous version. While it is most definitely a worthwhile goal to create a set of useful extensions for CDI, Seam 3 by itself is no longer the fully integrated framework stack that Seam 2 was. As a direct result of this change in focus many of you have been disappointed with the documentation and getting started experience for new users.
What do users want?
The feedback we received from the community covered a broad spectrum of concerns, however there were some common areas such as:
- Documentation
- Getting Started Experience
- Tooling
- Lack of Drools/jBPM support
- Lack of certain features, e.g. entity framework
- Lack of migration guide
Underlying these, we also noticed two strong messages:
- Some developers are interested mainly in portability. They don’t want their application locked into any particular container implementation, and it’s important to them that they have the freedom to use the framework in different environments.
- Many developers just want an end-to-end framework that works, without having to piece together all the bits themselves and work out how to integrate them. They don’t want to have to read multiple sets of documentation from different projects, and their primary requirement for an application framework is productivity, i.e. getting the job done quickly and efficiently.
So the question is, how can we return to the fully integrated framework stack and productivity that Seam 2 provided, and also provide a set of portable extensions, optionally consumed a la carte, that will run in any environment where CDI is present? We’ve been working with community leaders and module leads, and have come up with a proposal that we think will rise to the challenge of addressing these concerns.
The first step we will take is to create a community-owned set of portable CDI extensions; a de-facto set of features that developers can take and use within their own applications, in whichever container they wish to deploy to. One of the major goals of this project is to grow and unify the Java EE community. By joining forces with other CDI extension developers, such as the Apache MyFaces CODI team and the CDISource team, as well as other key members of the Java EE community, we are creating a community that is stronger than the sum of its separate parts.
This must be a real community project, without any corporate affiliation to ensure that the project remains neutral. We’ve identified Apache as being a great place to host this project, as they are a non-profit organization with no corporate agenda, and have a strong reputation in the community for producing successful open source projects. So without further ado, let me introduce the Apache DeltaSpike project.
Apache DeltaSpike
By the time you’re reading this the proposal for Apache DeltaSpike has been submitted to the Apache Incubator and begun the process toward becoming a top level Apache project. DeltaSpike is a set of portable CDI extensions, built collaboratively by the Java EE community. It will be seeded by code contributed from various Java EE open source vendors, and provide a number of essential features for building enterprise applications. Portability will be the main principal of this project, satisfying the need of many developers for a framework that will run in a number of different environments.
After its initial release, the existing Seam development team (consisting of both full time and volunteer contributors), along with the MyFaces CODI team, CDISource team and other members of the greater Java EE community will carry out ongoing development on DeltaSpike - this includes the creation of new features and innovations, bug fixes and other enhancements. While it is not my place to talk about the release schedule for DeltaSpike (this is decided by the Apache DeltaSpike Podling Project Management Committee (PPMC)), I am 100% confident that it will be a lively, active project that receives the attention and contributions that it deserves, and produce many ongoing releases.
The first release of Apache DeltaSpike will consist of a common core, a set of extensions that will provide the base on which to build other extensions. It will be tested extensively across multiple Java EE containers to ensure portability, and provide a solid foundation for the development of other features. Eventually the plan is for Apache DeltaSpike to incorporate many of the features that you can find today in Seam.
An Integrated Framework
We have also mentioned that we’d like to address the needs for developers that require an end-to-end development stack. While we’re still working out the details for this, I’d like to reassure everyone that it is a high priority for us to provide a fully integrated framework in the spirit of Seam 2 but with even better productivity. We have some great ideas in motion to provide a full integrated framework for your needs. We know you’ll be excited as we are about what’s in store, so please watch this space over the coming months for more details.
What about Seam?
For those developers who have already invested heavily in Seam, don’t worry, we’re looking after you also. We’ll be continuing development on Seam 3 for the foreseeable future, in fact Seam 3.1 which is due for release shortly contains a number of exciting new modules and other improvements. We’d like to also reiterate that we are fully committed to the Seam Community - the initiatives that we’ve described above are all for the benefit of you guys, to give you the most productive framework and tools for building your applications that run the world. We ask that you be patient with us as we roll out this vision over the coming months, and thank you for your continued support.
A brilliant collaboration. I am so impressed with the community's ability to refactor and redirect into a more unified Java EE community. I am proud to be a part and would like to contribute where I can.
The world was changed so quickly.
Is the AIM of DataSpike to kill the Spring Framework (where they do whatever they want and don't listen the community)?
I don't understand you. Instead of making Seam what it was and should be - integrated framework - you move all responsibility to Apache community. And do nothing to make Seam what it should be.
You write about standards - instead of Seam Forge you should use Maven archetypes.
Now I clearly see that Seam 3 never will be integrated framework and time spend on it is lost, because enterprise will never adopt it as it is.
So now developers have no choice: Seam 2 is rather outdated (no JSF 2, no EJB 3.1 support), Seam 3 has no future, Deltaspike doesn't exist yet. Thank you very much...
So DeltaSpike will address the portability issues, that is very cool. But what about 'integerated framework ala seam 2' stuff? We didn't see any plans about that.
To me the sentence indicates that nobody is willing to commit to that cause.
Will Seam.Next be Seam.End?
If I can read between the lines, you will announce sometimes in the following months a new Seam 4 that will consist of DeltaSpike + Various JBoss stuff (AS, logging, servlet, weld, etc) + documentation + tooling that we can deploy and use in no time ?
Count me in.
Opening one door doesn't mean that the current floor is lost. It rather might as well mean that you now have much more space!
Basically there are lot important things we have considered while discussing this proposal the last few months
1.) the view from a developer in a company who likes to write own Extensions. Those poor guys had to mostly reinvent all things over again. Because up to now it was not easily possible to use cool parts of Seam3 (e.g. AnnotatedTypeBuilder) together with cool parts of CODI (e.g. ProjectStage, @ProjectStageActivated). This will become much easier, because all those tools will perfectly fit together!
2.) the view from a developer who likes to simply use CDI to conveniently create his own applications. On this front it's pretty simple as well: a.) the bigger the community - the faster the pace! b.) the more container vendors involved- the more portable the result! c.) users now get the cool features from Seam3 and CODI in one homogenic package! d.) there are already a few other extension projects which like to join forces!
3.) the view from a former Seam user. Actually Seam3 was already a big break as some Seam2 concepts do not fit 1:1 into the CDI world. BUT: by having much more hands to help and a solid base functionality (deltaspike-core) as foundation, more people can focus on creating a good Seam2 migration path! We thought about this really well right from the beginning, and we did NOT forget about you folks! Actually I could add even more. Nowadays it's really seldom to have a real win-win situation - but that's exactly what it is!
I tried to keep it small, but really, the benefits are poping out all over:
1.) While testing DeltaSpike with Arquillian and ContinousIntegration against various Servers (Weld standalone, OpenWebBeans standalone, Glassfish, JBossAS, TomEE, etc etc) we gain REAL portability!
2.) We will pretty surely hit a few things we must fix in the CDI spec itself - this will improve CDI overall!
3.) By using Arquillian for our tests we will also improve Arquillian - this will benefit all JavaEE folks!
4.) We will for sure find a few bugs in Weld, OpenWebBeans and a few EE containers - nuff said?
yada yada yada... the list of positive benefits can be continued pretty long ...
Moving the CDI responsibility for modules to the teams with the knowledge about the module, seems like the only sane thing to do. Making 3.th. party code talk CDI is IMHO not the responsibility of JBoss. CDI is after all not a JBoss standard, as Seam DI was.
This will also free up JBoss focus and resources to recreate and maintain the new "integrated framework" or "Seam stack", while a cross organizational effort can be put into making the individual modules stable and ensuring that they "play nice together".
To me this sounds great. The only down side I can see in all this is the long wait.
In Seam 2 you put Jboss, Seam 2, Richfaces and you could be sure it will work together. If no, you could write to Seam or Richfaces forum and had a big chance to get problem fixed. You had only two tabs with documentation (Seam, RF) and examples with everything working in standard Seam distro.
Now you have a freedom to choose everything and can only pray that it will work together. If it doesn't, you don't know where to write for help. You will fight with different versions of component from multiple vendors. Documentation will be splitted. You will have a problem what to choose, because I doubt there will be one integrated repository with all CDI extensions described. You will not find good examples in documentation (because documentation doesn't cover integration with other components), you will not find it on blogs too because it's more then sure that author have different stack of components than you chose.
I know that everyone like freedom, but in enterprise software you doesn't need it as much as good guidelines, examples, framework, documentation and stability - it's everything Seam lacks of.
I applaud the fact that Seam stuff will be contributed to Apache DeltaSpike. As the community around CDI extensions becomes larger and more unified.
What I do not understand: what's the future of Seam?
Should we start picking code from DeltaSpike and Seam? What's the additional value of keeping seam alive after release 3.1?
Or will seam project be the place where you can find the documentation of how you integrated all those DeltaSpike extensions and where you can fully functional examples as Seam 2 provided?
So lets sum this up as I understand it:
- Seam 3 + other 3rd party CDI extensions -> Apache DeltaSpike
- Apache DeltaSpike + X -> Seam.Next
Frankly I think that the heading of this post is somewhat misleading because you talk more about what is happening to the current Seam 3 codebase then what actually will become the project. It is only mentioned that we will have to wait a few months before we will get word about how the next real Seam version (means ent-to-end Seam framework) will look like.
Having said that I think in general this is the right direction. I congratulate the Seam team for having the balls to admin that mistakes have been made and they are not too shy about making big changes to get back on track.
Just don't let the people wait too long for info about what the real Seam.Next (again: the Seam framework as we knew it) will be. After all this is what the Seam 2 users are really interested in.
Thanks
I'm all for collaborations but I (like many others) could use some overview on how stuff works together.
Currently, If I drop in Catch, Servlet, Faces and Transactions from Seam 3, they are all aware of each other and integrate to the best of their abilities. Will all these modules migrate under the DS-umbrella? Will they auto-integrate in the future, too?
(and I hope the projects will be kept clean so that I don't see the whole apache-commons* dragged in as soon as I add a maven dep to DeltaSpike) ;-)
Some more questions
_Nicklas Karlsson wrote on Nov 30, 2011 06:01:_
I'm all for collaborations but I (like many others) could use some overview on how stuff works together.
(and I hope the projects will be kept clean so that I don't see the whole apache-commons\* dragged in as soon as I add a maven dep to DeltaSpike) ;-)
# Where will the community forums be hosted?
# You \*are\* going to use git, aren't you?
# You \*are\* going to use JIRA, aren't you?
</blockquote>
# Yes, no foreign dependencies. IF we need something, then we can simply copy it into the project or we can shade it into a private package (as last resort).
# we will use GIT, main repo hosted at apache.org plus mirrors on github
# JIRA will be used
# mailing list will be setup up. See the proposal. We could additionally use the community forums over here, but main questions should pop up on the mailing lists. They are backed up at nabble, markmail and 10\+\+ other locations + easy to search, etc
Interesting move if it really merges Seam 3 / CODI, even if it implied to wait 6 month / 1 year more for Seam 2 -> DeltaSpike migration ;(
Awaiting anxiously for Integrated framework / Seam 2 migration plans now ;)
Cheers
N.B. this means seam-faces and Myfaces CODI JSF will be merged ?
I really like some features from MyFaces CODI.
Hi, From the enterprise point of view, it is hard to make a decision based on what is being explained in this post.
Seam 2 was well driven by the JBoss community but it has its EAP version which was sold with JBoss AS EAP Server, so we could justify to our boss our decision.
Apache projects have been proved to success as independent products, but when it comes to integrate different projects the experiences are not good enough.
Please, refer to Apache Shale project (2005 more or less) and check out project goals. Upppsss... they are the same 7 years later. Shale was a great project but it failed to succeed.
Regards
What about stuff which exists in CODI and Seam? (ViewConfig, Transaction, etc...) CODI Persistence/Transaction stuff is more leightweight and does not have extra integration for JSF etc.
Actually, by using CDI inside the Extensions itself we can offer both the lightweight and the fully integrated. The guys from OpenKnowledge even will like to contribute a very elegant JTA implementation.
Here is how it works. This is just an example about how CDI-Extensions can easily be built modular. This trick (and many others) can/will be used all over:
We have ONE single TransactionInterceptor:
https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
and this is ALWAYS the same!
BUT it actually doesn't contain any functionality, but just delegates to a @Dependent PersistenceStrategy. This PersistentStrategy can be either a very simple one (default) or in another jar could be a @Spezialised JtaAwarePersitenceStrategy extends DefaultPersistenceStrategy. Since it's @Dependent there wont be any proxy in between eating away the performance!
In your customer project you can always just use @Transactional - and it's completely decoupled whether you will use JTA or a simple SE solution!
And Seam Solder and other Seam modules contain similary cool stuff as well! So we are now putting together all the lessons learned the last years and create an even better solution!
Two pros:
= Some extensions (like Persistence, Validation, JSF) that earlier were to be moved to specific implementation projects (Hibernate, RichFaces) are now kept in order to assure portability
= Seam now decouples from JBoss, moves to Apache and is likely to be perceived even more as AS portable
But one con:
= The RAD part - Seams IDE Tools and Gen gaves us a nice integrated development environment. But Forge is not going to DeltaSpike, so... is Maven Archetypes the RAD part DeltaSpike will provide (static and unflexible)? Or will they create a Forge plugin (unlikely)? If Forge also was going to DeltaSpike that'd be sweet because then I'd assume that any DeltaSpike CDI Extension would be nicely integrated in Forge.
Thanks for driving this forward!
Jens
Have no fear. Our next step will be to make an announcement about exactly what Seam.Next will be, and hopefully clear up most of your questions. Please bear with us and know that we are taking our time on these announcements because we want to be sure that we are telling you what will actually happen, not what we think will happen and then have to chance the message when it does not.
Regarding Forge in DeltaSpike - there are no plans to move JBoss Forge to DeltaSpike because it is not part of Seam 3, and it is a much higher-level tool (not technology specific, e.g. We are even working generating Spring MVC projects with it .) https://github.com/forge/plugin-spring-mvc
But be assured that we will be working on providing an integrated set of plugins for you. This is definitely in the picture, and we will of course be looking to the community for what the real needs are.
Glad to see Seam continue to evolve. For what it's worth, JSF 2.2 has better support for CDI . Every kind of object created by JSF is now injectable.
Ed Burns JSF spec lead.
This is really the most exciting news for Seam 2's NEXT in the past years!! But for Seam 2's CURRENT, could you please do a little on it? Because there was no upgrade since Seam 2.2 release on July 30,2009. Many Seam 2 users have been waiting for JSF 2 support on Seam 2, but it looks it never comes. We really appreciate it, thank you so much, Seam team!
I'd like to take a moment to address the Seam 2 questions.
First, we've announced back in October about Seam 2.3.0.ALPHA, you can find the downloads on the Seam 2 Downloads page. The message must not have gotten out very well because it's only been downloaded about 500 times, we're sorry about that. This release contains many bug fixes our QE department have found and fixed. It is based on Maven, something many in the Seam 2 community had requested. It also should work with JSF 2! I know those maintaining Seam 2 would appreciate comments, bugs, and also contributors in helping. Please take a look at it if you have not.
Seam 2 is not being abandoned, it will still be maintained for some time and will also be usable in future versions of JBoss AS. You can see how to do this on Marek's blog. We're not abandoning the Seam 2 users, please don't think that. If you would like more information about Seam 2 and 2.3.0+ please get in contact with Marek as he is the steward of Seam 2 now. I also believe his blog will be the place to find more information.
Author of Seam Catch
I think that a bad "auto-goal" for JBoss as now, after I have heavily invested on Seam 2, I'm stuck waiting for JSF2 support so now I am working on something "from scratch" with new technologies and I'm avoiding Seam 3 because I don't trust it anymore...sorry about that but a product has to be properly supported for a certain time (and also no clear migration path has been done so that's another problem for many)...
So I can see that moving to Apache could be good if you think long term, but I still don't believe we (Seam2 users) will be able to "move on" in a short term...
Dem
Use Spring Framework.
It was a year ago when Seam team members were calling for reform of the JCP. Some of the arguments included:
"The JCP also fails to respect the nature of software development. Instead of following an iterative process, JSRs target big-bang releases that have no clear continuum to the next generation. These major shifts in the platform make it increasingly harder for consumers to carry out migrations. Smaller releases would be easier to adopt. There are also huge lapses between releases, which is time for the technology to fall out of date.
How can we expect to define a unified and consistent platform that integrates well if the technologies bundled are created in different campuses at different times? The decisions that occur behind close doors effectively turn off would be participants and consumers. The community becomes frustrated because they don't know what's going on."
Glass houses...
Unfortunately, I agree. I have given up on Seam and have discussed issues with Mark Little to no avail obviously...
Very good points, Seam is not enterprise grade frmwk (highly scalable, fault tolerant, performant) for large EE systems with complicated integration requirements, etc. and most likely never will be; like he said you can't plan your projects properly for upgrades/migrations, etc. That being said I did enjoy working on the JSF 1.2, RF 3.x, Seam 2.x stack. It's really a shame. It's obvious that there is not enough funding behind Seam and the core dev team (compare to Spring core dev total members). If you need 3rd party devs to help out, there is no guarantee on hitting dates, etc.
In any event, I wish the team and community the best but upper management @ JBoss doesn't seem to be doing a good job in many areas. I have been and continue to be very concerned.
I think that for continued corporate adaption/acceptance there would a need for some from JBoss. Seam used to be the in their end-to-end development stack. Surely the glue in the stack is not nowadays ? ;-)
I know I sound harsh and I'm not that harsh myself but I'm just trying to voice something that I think many will be facing when explaining their software stack choices to management. It's easy to say
I know these arguments and they had some truth in them for Seam2. That (e.g. the cluster unfriendlyness of the persistence handling in Seam2) did make quite a lot users choose Spring instead of Seam2.
Also the fact that Seam2 did in practice only run really well on JBossAS4 (you don't want to know how many customers still have AS4 because of that!) did not add only positive arguments. If you honestly tell your manager that you have exactly 1 server vendor/version you can run Seam2 apps on out-of-the-box, then this will quite often make people scratch their heads and use something else instead. All those points were the reason why I personally never suggested Seam2 to any customer!
And that was also exactly the reason why CDI (replacement for the 'glue' in Seam2) did some design decissions a bit different. Of course, breaking up with old (sometimes bad?) habits also has consequences on the compatibility side!
But look how many customers already adopt this 'new world' and all the parts which are derived from Seam2 (Unified EL, JSR-303, CDI itself!, JSF2)? Have you ever been to a hacker conference lately or into manager meetings at customers?
Actually a hell lot of those customers are currently switching to EE6 and thus to the stuff which are heavily influenced by Seam2. But they like to avoid the downsides which Seam2 did have.
For getting the whole picture I think we should split the roles of DeltaSpike and Seam.next (please note: I'm not a JBoss guy and have no details about their internal plans!).
I personally don't see the goal of the DeltaSpike project as to create a 'bugfixed Seam2 replacement', but to create a TOOLBOX (in the spirit of what Seam2 and MyFaces Orchestra was in the past) of components and mechanics which make development with the new world (JavaEE 6) a breeze!
I think (that's what I grasped between the lines) that JBoss will be providing a Seam2 compat layer on top of DeltaSpike plus convenience tooling plus professional support, etc.
Will the be the end of Spring?
Marx, and all others who have commented something like this, I want to assure that we definitely see the benefit of an integrated framework. with coherent, consistent documentation etc. Personally, I think this outweighs all other concerns. And we certainly do plan to provide just that. We're just not ready quite yet. We still have a little more work to do on the foundations.
Look guys, cutting to the chase, we had a choice. We could either wait, and delay starting work on this collaborative project with the great guys in the community such as Apache and CDISource and discuss our plans for both parts. Or, we could announce this now, get started on the work, and discuss our plan a little bit later.
We went back and forth on this quite a bit, and in the end we decided we really wanted to get started right now on the Apache project. If we, the Java EE community are to make this collaboration work, we need to be open from day one, and make sure everyone is equal. This, I think, is critical. Also, there is a lot of work to do - we have to align all of the areas of overlap between Seam, CODI and others. That's not an easy job.
So please, do one more thing for us, and concentrate on the massive benefits this collaboration brings, and let us show you what you can expect from JBoss around CDI and extensions very soon.
Me too!
The intent is definitely to the frameworks. We think this is massively valuable for the Java EE community.
I'll ask you to be patient for a little while longer. What we plan for the will definitely be what you want!
I certainly envisage that Forge will be able to generate projects which use functionality from DeltaSpike. In fact, I hope we can end up in a position where one of the decisions you make when you add CDI support to a project is to have DeltaSpike added as an extension.
I can only apologise for the poor support for Seam 2, and have to take part of the blame for that. The words of Arbi and others have been heard. I'm checking right now exactly what the plans for Seam 2 are, especially around JSF 2 support, and will let you know what I find out!
Ok Pete,
JBoss AS 7 or JBoss EAP 6 plus Seam 3 plus Forge plus JBoss Tools would have been a good hit for JBoss (.com not .org). Complete, full stack solution packed ready for productivity. We will keep waiting and bringing as much support as we can. Regards
Ok, first, congratulations to all of you for this direction. I believe that unified community is good. Despite all of this, I (and maybe seam users in general) want to know about, What will happen with brand?
For example I have a potential customer and asking me,
What should I do? Should it answered with,
Of course, as seam is community and opensource project, my question is out of scope. It is easy for you to say to me, .
While I'm fine with that answer, I see one problem here: a brand. IMO, for people that only knows seam in general, or never read many conversation/announcement about seam, or for a manager/decision maker that never know things in detail, this is only mean to one thing: seam (brand) is dead. We need to choose another stack.
So my suggestion is, please keep the brand. You guys have successfully raise the brand, and keep it exist is the harder part.
Of course, I'm biased here, since you could answer, . Well, no I'm not ;) . Instead, I should say thanks for the framework because of seam, I learn all about Java EE, not only .
Esteve, I think you have developed telepathy and are channelling me directly!
I was astounded to read this article and also I'm wondering why this project is handed to Apache, BTW I'm looking forward to hearing from end-to-end development stack.
Hi Omid!
Seam3 is not beeing 'handed over' 1:1 but it's core merges with 3 other pretty good CDI Extensions!
Seam3 was really good in some areas, but in other areas MyFaces CODI was better (check the CODI scopes and WindowHandler). Plus we also have CDISource' Spring bridge and the Quartz and JTA extensions from OpenKnowledge.
The problem was that all those Extensions used lots of duplicated and often non-compatible code under the hood. And we are now going to take the best ideas and remove these obstacles. The base parts can be used by other Extension vendors as well of course!
Also please note that DeltaSpike will only target JavaSE and EE JSR spec APIs and no implementation specific code. I assume that all the 'extended' parts will be based on deltaspike-core but maintained in the respective projects, e.g Hibernate, etc.
I have no information other than 'we cannot talk about it yet' about what JBoss plans to do with the Seam2 shim, but I would not surprised if JBoss will surprise you with a nice announcement in a few months ;)
Thanks for the update.
It seems JBoss is now again committed to a Seam Integration Framework, even though a number of the SEAM modules are going to their third-party homes (and the core of Seam is now integrated into JEE6.
As someone new to Seam and keen to start a new project with Seam I'd like to ask will it be worthwhile me waiting for the new Seam.Next integration framework?
If I should just please provide at least one demonstration application (sorry if I have missed them) to show me in use of Seam3 and JEE6.
From my perspective Seam2 was just as much about the integration framework as about the CDI and modules.
You will not see any example, because there are no Seam 3 framework to show. I really doubt it have sense to start new project with it. And it takes at least one year to mature a framework and DeltaSpike isn't written yet, which gets about half year probably. I don't understand wasting time for example Ceylon by one of core Seam developer, while Seam has drown...
Moving from the J2EE/Struts and pure JSF 1 background to Seam 2 was one of the best investments I made. After the steep learning curve, (thanks Dan for Seam in Action) I felt that it was worth it. Getting a project off the ground in rapid fashion with seam-gen and then using all the fancy richfaces JSF components and seam EntityHome and EntityQuery objects was fun and also at the same time was able to impress a lot of customers and end users with the applications that we built.
In making the decision to invest in Seam over 3 years ago, I took a gamble that learning the seam stuff would come in handy with future versions of JEE as the stated goal of JBoss was to promote some of the concepts to JCP and with Gavin and Pete etc leading some of these efforts, my gamble paid off as when JEE6 was out, I was able to quickly jump into it with ease.
Sadly that meant that the reason to use Seam was no longer that strong. Seam 2 did not have JSF2 support and with JEE6 I had to wire things up myself but it was not as hard as the J2EE days so in a nutshell I think the decision made to move Seam 3 to Apache makes sense and if we are to go by some of the hints from the Jboss folks, their new is the way to go and I hope they use the Seam brand and not start a new one as the Seam brand took a while to get to where it is now.
But will they loose most of the community by the time it comes out? Seam really did not take off after been around for so long. I think one of the reasons was that the key JBoss technical leads like Gavin and Pete were too busy with the JCP process and then Gavin went off and did his own thing called Ceylon and Seam did not have that high profile person behind it where Spring on the other hand had Rod Johnson right behind it for a very long time from inception.
Nowadays, there are a lot of new lightweight frameworks going around. The playframework looks to be very promising. Even for web apps, is Java the right way forward? I believe Java has already lost the battle with other lightweight frameworks like PHP which now have good MVC frameworks like Symfony. Then you have Ruby on Rails that is also very popular. But the most promising looks to be thin pure html(5)/javascript frameworks for the web front end that will communicate via REST API's (mainly JSON) to middletier services built on Java. So maybe its not worth investing in java for the web tier but focus on it for the middle tier.
Or is Java going through a slow death? Even the great Gavin King has abandoned Java for Ceylon. Or maybe not. That just could be Redhat/JBoss wanting their own language so they don't have to dance to the Oracle folks. I hope the Redhat/JBoss folks don't abandon Java and also get some benefits for themselves for all their contributions and effort over the years towards the JCP process.
My company is planning to start a new project based on Seam. Is it safe for us to use Seam 3 for this new project? I am concerned about the Seam 3 support. Also is there a new version of JBoss Developer Studio available to support Seam 3?
I like Seam 3 and I need justifications so that I can convince the management to use Seam 3.
It is three, yes THREE, months later and nothing from you or the other core developers. What is the current status of JSF 2 support in Seam 2.3?
You can register a best forex demo account with brokers like avatrader, plus500, and other which will all include free forex charting. Tell me forex how to trade ? Usually if you have registered at any of the above mentioned institutions you will already have access to a forex broker as well as forex demo account. All good forex brokers these days offers a free demo trading account where you can practice your trading strategy with play money before you will risk your real money.
They are fabricated of big-ticket abstracts such as top superior leather, boa, crocodile, lamb and biscuit skin. The fakes are fabricated of bogus covering and vinyl, can feel asperous and rugged. joey atlas' naked beauty symulast method system
At some sort of five-paragraph dissertation, such a fantastic certainly is the nearly all ; such a fantastic joined up with upward with in add-on to (and it may be or Air Conditioning Service North Palm Beach maybe simply ) yields five-part dissertation greatly significantly a reduced amount of definitely typically extra with great joined up with upward with in add-on to great!!!
Great article and your blog template is so cool. alliance home warranty extended home warranty
I am a newbie and your success is very much an inspiration for me. High Pagerank Backlinks Buy High Pagerank Backlinks .EDU Backlinks .GOV Backlinks SEO Package
Great information you got here. I’ve been reading about this topic for one week now for my papers in school and thank God I found it here in your blog. дизайн студия интерьера дизайн интерьера Москва
I want to thank you for this great and valuable information. how to be rich stop loss order world economy debt ceiling
Hey there thanks for showing me this. I must say that your blogpost was the most enjoying read I've seen in a long time. Greetings from Personal Trainer Ibiza
The world is changing fast. people are also being changed.day by day we are becoming more dependant on degital system.yoU make me think of this really.You have a nice way of sharing your thoughts.High Pagerank Backlinks High Pagerank Backlinks
Well, this got me thinking what other workouts are good for those of us who find ourselves on the road or have limited equipment options.home workout
The Forever Yours PDF ebook and complete guide to understanding and connecting with men. Gain instant access to amazing tips, insider techniques, and connection secrets on how to painlessly defeat his emotional barriers, get inside his heart, and form an unbreakable bond with the help of relationship expert and best-selling author, Carlos Cavallo.https://www.rebelmouse.com/foreveryours/
At the end of this post, I have also placed some important consumer alerts about various schemes I've found from dodgy websites promoting Fibroids Miracle (FM) with absolutely no knowledge of the product and that may have ulterior motives to try and trick you into visiting their sites. https://www.rebelmouse.com/amandaletofibroidsmiracle/
I want to thank you for this great and valuable information. Buy SEO Packages buy quality backlinks manual directory submission pagerank backlink buy backlinks Buy High pagerank backlinks Social Bookmark Services Buy Link Wheel Service directory submission pr5 backlinks High Pagerank Backlinks
Most research that, when given to kids who need it, GH accomplishes the objective of including significant size to the kid's prominence with little to no adverse reactions. browse around this site
Growth hormone has been proven to enhance improve post-transplant kids suffering from growth failing. This is because pre-transplant; kid's systems may be pressured so that they cannot develop normally. visit site