1 2 Previous Next 15 Replies Latest reply on Sep 27, 2005 10:00 AM by jfelfouly

    JBoss Portal vs. LifeRay and eXo

    scrut

      How does JBoss Portal compare to LifeRay and eXo?

      The two latter portals seem a lot more mature and provide a lot of portlets already.

      Why should someone use JBoss Portal instead when starting a new project?

      How is JBoss Portal different from the other systems?

      I find it hard to decide which platform to choose...

      Here is my backdoor: what if I decided to use eXo or LifeRay for now and develop my own portlet - can I later deploy it with JBoss Portal as is and integrate it? I mean, all three claim that they are JSR168 compliant so in theory this might be a suitable backdoor. What is your opinion on that?

      scrut

        • 1. Re: JBoss Portal vs. LifeRay and eXo

           

          "scrut" wrote:
          How does JBoss Portal compare to LifeRay and eXo?
          The two latter portals seem a lot more mature and provide a lot of portlets already.


          Mature how? We're not in the business of developing portlets. The goal of this project is to provide a scalable, flexible, and reliable portal framework, not bible and weather portlets.

          That being said, Novell is bringing roughly 35 portlets to the LGPL table. ;-)

          "scrut" wrote:

          Why should someone use JBoss Portal instead when starting a new project?


          Because we back JBoss Portal with proven JBoss support services, and companies like Novell are knee-deep in assisting the portal effort with us.

          "scrut" wrote:

          How is JBoss Portal different from the other systems?


          I've never gone thru and compared us feature for feature. You can see a complete feature list for portal here: http://docs.jboss.org/jbportal/v2.0RC/user-guide/en/html/features.html

          "scrut" wrote:

          Here is my backdoor: what if I decided to use eXo or LifeRay for now and develop my own portlet - can I later deploy it with JBoss Portal as is and integrate it? I mean, all three claim that they are JSR168 compliant so in theory this might be a suitable backdoor. What is your opinion on that?


          If its spec compliant, then you can plug them in to eXo and move it to JBoss Portal. I don't know about portability in Liferay portal.

          • 2. Re: JBoss Portal vs. LifeRay and eXo
            scrut

             

            "roy.russo@jboss.com wrote:
            Mature how? We're not in the business of developing portlets. The goal of this project is to provide a scalable, flexible, and reliable portal framework, not bible and weather portlets.


            But Portlets are what makes a portal useful. So being able to pick 80% of your portlet needs from a "out of the box" list of portlets is a bonus and reduces the time to get started.

            Even if you don't provide portlets yourself, I think that you should provide a list of sources for those portlets.

            "roy.russo@jboss.com wrote:
            That being said, Novell is bringing roughly 35 portlets to the LGPL table. ;-)


            Like a list of those ones...

            "roy.russo@jboss.com wrote:
            Because we back JBoss Portal with proven JBoss support services, and companies like Novell are knee-deep in assisting the portal effort with us.


            That's nice. But after all, what really counts are the answers to the questions: "Can system xyz get the job done better than the others? Can I use it for my specific needs? Does it provide the functions and features I need?"

            And right now I am not so sure about JBoss Portal.

            In order words: If I do a bit of configuration in eXo or Liferay, I can SEE results and with my own eyes I can see that large fractions of my portal needs are met already.
            With JBoss Portal I see mainly promises at the moment.


            "roy.russo@jboss.com wrote:
            If its spec compliant, then you can plug them in to eXo and move it to JBoss Portal. I don't know about portability in Liferay portal.


            How is Liferay different? Is the only issue the question whether or not it is spec compliant? Or is there more to it?

            Thanks

            scrut

            • 3. Re: JBoss Portal vs. LifeRay and eXo

               

              "scrut" wrote:
              But Portlets are what makes a portal useful. Even if you don't provide portlets yourself, I think that you should provide a list of sources for those portlets.


              Most of the people I've dealt with don't find the freebie portlets useful at all. They do very little of the heavy lifting, and other OS portals seem to offer a bucket of google and toy portlets that I find quite useless, atm.

              "scrut" wrote:

              That's nice. But after all, what really counts are the answers to the questions: "Can system xyz get the job done better than the others? Can I use it for my specific needs? Does it provide the functions and features I need?"


              So why don't you articulate your needs, instead of asking broad and general questions?

              "scrut" wrote:

              With JBoss Portal I see mainly promises at the moment.


              Would it soothe you to know I'm a man of my word?

              "scrut" wrote:

              How is Liferay different? Is the only issue the question whether or not it is spec compliant? Or is there more to it?


              Don't know. Are they spec compliant? Try pulling one of their portlets and porting it. The freebie portlets they have are intimately tied to their struts-portal-architecture, so portability is a no-no.

              • 4. Re: JBoss Portal vs. LifeRay and eXo
                scrut

                 

                "roy.russo@jboss.com" wrote:
                Most of the people I've dealt with don't find the freebie portlets useful at all. They do very little of the heavy lifting, and other OS portals seem to offer a bucket of google and toy portlets that I find quite useless, atm.


                I agree with you on this one.

                "roy.russo@jboss.com" wrote:
                So why don't you articulate your needs, instead of asking broad and general questions?


                I need a portal system that provides me, out of the box, with
                - a Wiki
                - a Forum
                - a News System
                - a Blog

                I then want to write my own portlet and add it to this configuration.

                The important things for me are:

                1. That I can specify roles such as "Guest is allowed to read all content in Wiki, Forum, Blog and News but not the content in my own portlet" and "user is allowed to read the content in my own portlet and read/write in forum and wiki" and so on. I want to define that in a central spot so that it effects all portlets installed.

                2. Once a user is logged in, he can navigate in the whole portal and use it according to the rights and restrictions associated with his user account. (Single sign on)

                3. I want to create a portal page with login field and menu on the left and my portlet and the news portlet in the centre. From the menu, a user can navigate to Wiki and Message Boards. Depeding on the logged in user, the menu has to change (e.g. if I am logged in I probably want a function to edit the content in my own portlet which a normal user can't do).

                4. I don't want the user to be able to change the layout of the portal page (eg. I don't want the user to be able to close the news portlet so it disappears)

                5. I want that my own portlet can access his own database which is disjoint from the portal database (I want to manage my own data)

                6. I want that my own portlet can access the filesystem to read and write files it has to manage. (No, I don't want to use a DB-BLOB)

                7. That I can use a template-like technology to change the design and look&feel for all components involved


                "roy.russo@jboss.com" wrote:
                Would it soothe you to know I'm a man of my word?

                ;-) Well, I know that JBoss Portal will most likely evolve very fast. And I tend to put more trust into JBoss than some companies that might be behind other portal system. So you have the advantage of my trust.

                Yet the issue remains: I have to get a job done (see above).

                I can wait for the "out of the box" portlets for a few weeks or months (e.g. if you say "we are working on providing a super Wiki portlet but that won't be done until July" it would be fine with me.)

                But I need to get the portal done.


                "roy.russo@jboss.com" wrote:
                The freebie portlets they have are intimately tied to their struts-portal-architecture, so portability is a no-no.


                That is, in fact, a serious issue! I will investigate that.

                thanks

                scrut

                • 5. Re: JBoss Portal vs. LifeRay and eXo

                   

                  "scrut" wrote:
                  I need a portal system that provides me, out of the box, with
                  - a Wiki
                  - a Forum
                  - a News System
                  - a Blog


                  I don't have an ETA right now on the XWiki portlet. I was migrating it over, but had to drop it for this release cycle. Forums we have. News, someone needs to port from Nukes. Blog we have... kind of... its an rss reader that read from blojsom.

                  "scrut" wrote:

                  1. That I can specify roles such as "Guest is allowed to read all content in Wiki, Forum, Blog and News but not the content in my own portlet" and "user is allowed to read the content in my own portlet and read/write in forum and wiki" and so on. I want to define that in a central spot so that it effects all portlets installed.


                  Our current permissions scheme supports this.

                  "scrut" wrote:

                  2. Once a user is logged in, he can navigate in the whole portal and use it according to the rights and restrictions associated with his user account. (Single sign on)


                  Also can be done presently.

                  "scrut" wrote:

                  3. I want to create a portal page with login field and menu on the left and my portlet and the news portlet in the centre. From the menu, a user can navigate to Wiki and Message Boards. Depeding on the logged in user, the menu has to change (e.g. if I am logged in I probably want a function to edit the content in my own portlet which a normal user can't do).


                  Our page system and theme api allows you to do this.

                  "scrut" wrote:

                  4. I don't want the user to be able to change the layout of the portal page (eg. I don't want the user to be able to close the news portlet so it disappears)


                  Currently, the user cannot. How your portlet reacts to user actions, is up to the portlet though.

                  "scrut" wrote:

                  5. I want that my own portlet can access his own database which is disjoint from the portal database (I want to manage my own data)


                  This is up to your portlet, I believe.

                  "scrut" wrote:

                  6. I want that my own portlet can access the filesystem to read and write files it has to manage. (No, I don't want to use a DB-BLOB)


                  Again, up to your portlet.

                  "scrut" wrote:

                  7. That I can use a template-like technology to change the design and look&feel for all components involved


                  I'm working on the theme api documentation, currently. the theme api is already in the RC release.

                  "scrut" wrote:

                  I can wait for the "out of the box" portlets for a few weeks or months (e.g. if you say "we are working on providing a super Wiki portlet but that won't be done until July" it would be fine with me.)


                  I can't promise anything, but the super XWiki portlet may be finished by then as it is needed for the JEMS site.


                  • 6. Re: JBoss Portal vs. LifeRay and eXo
                    scrut

                    Thanks

                    That was very helpful.

                    Looks like JBoss Portal can essentially do what I want. I will certainly consider using it for our project.

                    scrut

                    • 7. Re: JBoss Portal vs. LifeRay and eXo
                      antoine_h

                      Hi,

                      That being said, Novell is bringing roughly 35 portlets to the LGPL table. ;-)


                      where can I find them ?
                      on web search engines, I see only articles talking about it (in march 2005) ?

                      Thanks.

                      • 8. Re: JBoss Portal vs. LifeRay and eXo

                        We've decided to move ahead on the portlet community site without depending on Novell's portlet contributions. Something will be announced this week. Stay tuned.

                        • 9. Re: JBoss Portal vs. LifeRay and eXo

                          So are the Novell contributions (35 portlets) still going to materialize???

                          • 10. Re: JBoss Portal vs. LifeRay and eXo

                            I have no ETA.

                            • 11. Re: JBoss Portal vs. LifeRay and eXo

                              That's an honest answer...thanks and have a GREAT evening, morning...whatever your timezone.

                              Anthony

                              • 12. Re: JBoss Portal vs. LifeRay and eXo

                                they will!
                                It simply took us a lot longer than anticipated to free up some resources to port these portlets. We are actively working on this effort, so I hope we can publish some early versions not too far in the future. However, I want to caution people: We have bigger plans with our portlets, so we need to ensure a substantial set of functionalities in the framework. We're converting a set of 5 portlets to start with so we can find the missing pieces in the current portal framework. Once the missing pieces are identified, we need to fix those areas first before we can move on and migrate the bigger bulk of portlets.
                                Since our resources are just now coming up to speed, this process will take some time.
                                I hate to put more promises out there, but that's all I can say for now. It will take longer, but you'll get better quality and much more functionality whenever it is ready. Once we have a template for the migration of our portlets, we'll open this up to a more agile model. Perhaps we can get some help migrating ? ;)

                                and just to mention some of the functionalities we're looking at ( don't take this as a guaranteed feature list though !):
                                * localization
                                * typed preferences
                                * scripting support for portlets and preferences
                                * ajax (that one actually throughout the portal...)

                                So: no more promises, you'll simply have to wait until we're ready, but the good news is that we're working on it.

                                • 13. Re: JBoss Portal vs. LifeRay and eXo

                                  Hi Martin -
                                  Is there the possiblity of anything in the coming weeks?....b4 the end of the year?

                                  Thanks,
                                  Anthony

                                  • 14. Re: JBoss Portal vs. LifeRay and eXo

                                    I certainly hope so, but I can't make any commitments at this time.

                                    The nice thing is that portlets aren't tightly coupled to the portal release cycle (only to some degree), so they might not be ready for the 2.2 release, but you might get them before the end of the year. But as I said, no promises.

                                    1 2 Previous Next