"rharari" wrote : Hi Brad, | | I´ve a question: | | anonymous wrote : | | We are evaluating a few open source portals. | | | | Please, can you post or send me and e-mail describing which open source portals your team are evaluating? And also explain why you have decided to use jboss-portal? I´ve also evaluated some portals (open-source and commercial) before starting my project and in my opinion jboss-portal has the best cost/benefit relationships. I agree with you that the documentation is not the best but who provides a complete documentation? Personally, I think source code is some of the best documentation you can have. | | and.... | | anonymous wrote : | | Google gadget integration (who really needs that?)? | | | | I do! ;p | | | Thanks | | r.harari | Here are some answers to your questions (opinions are liberally sprinkled throughout my response ;-)) Two summers ago, when JBoss Portal was 2.0.1 (+/-), I quickly put together a portal for an intranet project here. At the time, JBoss portal was the smallest, fastest, and easiest to customize. Once JBoss Portal started adding in things like IPC, WSRP, and changing directions with the security model, and of course, adding more 'stuff' to the CMS portion, I find that the portal starts to get significantly slower, much more complex, and often times quite fragile. So this year (late 2006-to-present) we've reevaluated liferay, exo portal, jetspeed 2, and jboss portal. Of these, JBoss is still a better portal primarily because it is easier to get started with and build a development process around. So our reasons for using (or attempting to use) JBoss Portal for a current internal project (moving from BEA Weblogic Portal 8.1.4 to JBoss Portal 2.6.X) are the following: a.) an initial very positive experience with a younger JBoss Portal b.) we're basically standardized on using JBoss App Server, Hibernate, and many other JBoss components in our architecture. c.) relative ease of use, customization, development process (just create multiple wars for a particular portal implementation in JBoss). Some of the pain we have had using JBoss Portal 2.6 and the success we have had using Seam + Ajax4jsf + Facelets has led us to now pursue a path in which JBoss Portal 2.6 will be a temporary stop-gap solution to evolve our original BEA Portal. Our plans now are to continue converting BEA portlets to standard JSR-168 portlets deployed in JBOss Portal; in this conversion, we are now using Facelets and JSF (myfaces + tomahawk) for our presentation layer. After this initial conversion, we will be all set architecturally to drop out the JSR-168 API's and go to a complete Seam-based architecture. I've found that the combination of Seam + Facelets + Ajax4JSF + Richfaces + Tomahawk allows us to solve a vast array of user-interface development problems. Plus, this combination allows us to make a 'portal-enough' user experience that takes full advantage of Ajax and other Web 2.0 techniques without the 'noise' of JSR 168. One comment on the google gadget thingy - I have nothing against a google-gadget portlet or add-on module, but I really think that JBoss Portal would do better if it was a delivered as a basic Portal 'engine' with a lot of the bells and whistles available as easy-drop-in add ons. Unfortunately, a lot of the bells and whistles (such as a google-gadget portlet) are simply lumped into the basic portal - making the whole product complex, hard to document, and fragile at times. Splitting the Portal into logical pieces allows each piece to evolve independently - most likely the core engine won't change too much because the fundamental building blocks are a JSR168 portlet container plus the paging and customization system. And finally, yes, the source code is good documentation - it's an invaluable resource during development for solving the tough problems of using any technology. Hope this helps. Brad Smith View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4046870#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...