TSS Article: Introducing the eXo Platform

Discussions

News: TSS Article: Introducing the eXo Platform

  1. TSS Article: Introducing the eXo Platform (36 messages)

    The eXo platform is an open source, JSR 168 implementation, enterprise portal built from several modules. Exo is based on innovative tools, APIs and frameworks such as JavaServer Faces, the Pico Container, JbossMX and AspectJ. This article overviews the eXo platform and of all its modules, focusing on the architecture, and highlighting the design decisions that were made while the platform was being built.

    Read Introducing the eXo Platform

    eXo has released a second beta of the project

    Go to the eXo project home page

    You can download eXo here:

    binaries:
    http://prdownloads.sourceforge.net/exo/exo-portal-bin-beta2.zip?download

    sources:
    http://prdownloads.sourceforge.net/exo/exo-portal-src-beta2.zip?download

    Threaded Messages (36)

  2. Jetspeed portlet for Slide?[ Go to top ]

    I saw in the article that you wrote a jetspeed portlet for slide?? was this ever released? I looked for one a long time ago and could never find one.. which I knew you had one....

    Also any chance that eXo Portal will run on the Weblogic App Server? (7.0 or 8.1)
  3. Jetspeed portlet for Slide?[ Go to top ]

    For the portlet we will provide one for our own CMS :).

    We are currently working on making a universal deployer to make the platform runs on every application server (the express edition even with tomcat only)

    the eXo dev team
  4. LMS and LCMS[ Go to top ]

    Hi,

    I read that you have some LMS/LCMS communication components? What kind of components do you provide?

    Thanx!
    Lofi.
    http://www.openuss.org
    Open Source J2EE eLearning.
  5. LMS and LCMS[ Go to top ]

    We provide enhanced communication tools that come from the very first version of eXo. There are mail, forum, and chat (we also have an IRC server you can download on SF site); those tools include java applet editors (like maths editor or slide editor) to provide more information than just plain text. We built a framework to manage those plugins.

    Therefore, you can create any type of editor (from finance to football) and include the result of the editing in the message sent. To develop those plugins you just need to implement a simple API to communicated with the platform. That plus the CMS module can be the basis of a powerfull LMS and LCMS platform.

    Note that all of this is not explained in the article which is already quite long...

    the eXo dev team
  6. LMS and LCMS[ Go to top ]

    OpenUSS already supports mailinglist (EJB based, stand-alone), forum (EJB based, stand-alone) and chat (Babylon). The math editor is indeed very interesting! I'll check this out.

    It's nice to see that we'll getting nearer to reusable presentation layer (portlets). For ExoPortal and LPortal maybe it would be nice if both projects can exchange those available portlets. At least to show that those portlets are reusable in different portals ;-)

    Regards,
    Lofi.
  7. LMS and LCMS[ Go to top ]

    The point is not in the communication tool themselves (chat, forum and mail are commons these days), but in their interaction with the plugins editors.


    We talked with Brian Chan and proposed him to focus on portlets (they have a large portlets repository, but quite EJB centric) while we focus on the core development (kind of join efforts :) ), but he said it was to early. I still hope he will change his mind.

    the eXo dev team
  8. Anybody think would be possible/easy to hack eXo to support server-side callbacks ? I mean, eXo UI components receive events from the browser but if I need to fire an event in server and notify the client (browser) using may be, http streaming like Pushlets does ? Ok, I know the eXO developer does not have to worry about the browser issues and logic must reside in server side but there are some apps like Instant Message that would use this feature.

    Thanks
  9. I don't have experience with Pushlet, but I once write an application , using hidden iframe and java script to submit request and javascript DOM to modify html page. It should work with exo and you don't need to know any thing about exo platfom as well.
  10. Tuan,

    Thanks for the help but I did a mistake. I was thinking not about eXo but Echo Web Framework instead. :| This is what happen when you work and browse at same time...

    Regards
  11. GPL license[ Go to top ]

    I was seriously looking at eXo, then realized that it is GPL licensed. I don't have a problem with the GPL, or with people making a dual GPL/proprietary license to generate revenue to help support development of the code. But GPL is still a hard sell to corporate clients... and they pay my bills :)
  12. GPL license[ Go to top ]

    I can understand that GPL is difficult to sell to compagnies and to say the truth this is exactly why we use it :).

    We want to provide Open Source software but also live out of our work (what a great life indeed) and GPL is the way to go. As the eXo dev team owns the intellectual rights, it can make custom commercial licences to be bundled with compagnies application without forcing them to open their code. In other words, no one can bundle us transparently, and I have to say that I feel good with that.

    Therefore, if you want to use the platfrom with another licence, just contact us, we will see what we can do for you :).

    the eXo dev team
  13. GPL license[ Go to top ]

    Hi Benjamin,

      Different companies offer different interpretations of the GPL license. If I develop a portlet and distribute it with Exo, clearly I must distribute the Exo source. Must I distribute the portlet source as well?
  14. GPL license[ Go to top ]

    The answer is yes unless you contact us for custom licence.

    But you can of course distribute the portlets without the eXo platform.
  15. GPL license[ Go to top ]

    Benjamin,

    I too have a problem with the GPL as a commercial entity. However, your website lists the license as LGPL (which is much more usable). I'm happy to contribute changes and fixes that we make to the Exo code back to the project, but my use of Exo shouldn't mean that all our other code is hence GPL'ed.

    Could you clarify what the _actual_ license of Exo is? LGPL or GPL?

    Chers,
    Mike
  16. The Licence is GPL[ Go to top ]

    The licence is GPL unless you ask us for a custom one that would allow you to distribute eXo with your application without opening your code.

    This is the copyleft concept : with GPL you must use the same licence.

    In other words, if you are a consultant or a software compagny and want to distribute eXo with third party close code, just contact us, our lawyer will write a nice nice for you.

    the eXo dev team
  17. Clarification about GPL[ Go to top ]

    Quoting from the GPL license:

    You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program...

    and

    If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

    So in the case of a server, what's considered as a work based on the Program? I mean, let's say we have a GPL J2EE server, and we make a J2EE application. I think it's evident that this application is not a work based on the program (in this case the J2EE server) as you haven't modified any portion of the program, so you don't have to publish the source of your application as long as you distribute them as separate works.

    Anyway, what does "distribute them as separate works" mean? Distribute it in separate zip files? Distribute them in separate directories in the same CD? Distribute them in separate CDs in the same bundle? Give your client a CD one day and the other one the next day? Ask your client to download the server?

    I have put the example of a J2EE server, as I think the case of eXo must be similar, as any portlet following the standard could be deployed in it, isn't it?

    Regards
    Jose
  18. Clarification about GPL[ Go to top ]

    I will try to make it clear :)

    In one hand, you can distribute eXo with your portlets, if your portlets only depends on the portlet API as this is a standard; in that case you do not have to open your code (but you still need to distribute eXo code).

    On the other hand,if your portlets use a custom eXo service or if your application interacts with the eXo platform in a non standard way, then you need, either to distribute your code under the GPL licence, either to contact us to make a custom one or negociate a partnership.

    the eXo dev team
  19. RE: Clarification about GPL[ Go to top ]

    <benjamin Mestrallet>
    In one hand, you can distribute eXo with your portlets, if your portlets only depends on the portlet API as this is a standard; in that case you do not have to open your code (but you still need to distribute eXo code).
    </benjamin Mestrallet>

    Ummm... no. If the eXo license is GPL, then simply distributing eXo with my portlets means that I *must* GPL my portlets.
  20. RE: Clarification about GPL[ Go to top ]

    As long as your portlets only interact with the eXo platform only through the portlet API you don't have to use GPL for them :

    in that precise case :

    "identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works." (GPL)

    And this is the case for every J2EE API.

    Note that all the information I give you come from the FSF emplyees :)
  21. RE: Clarification about GPL[ Go to top ]

    "identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works." (GPL)

    >

    I stand partially corrected :)

    I was thinking of the GPL license in terms of *bundling* not *derivative* works. For example, I come up with a whiz-bang CMS system that uses eXo as the basis. If I bundle eXo with my portlets and other code, an installer, etc, the whole thing must become GPL. However, if I just distribute my portlets with an installer that copies in eXo from another CD or from the web, I'm in the clear. At least that's how I understand it, I'm not a copyright lawyer, nor do I want to be.

    You could make life easier for everyone and just license eXo as BSD/MIT licensed ;)
  22. RE: Clarification about GPL[ Go to top ]

    Now all your statements are corrects, and you even pointed out why the licence is GPL :)

    "I was thinking of the GPL license in terms of *bundling* not *derivative* works. For example, I come up with a whiz-bang CMS system that uses eXo as the basis. If I bundle eXo with my portlets and other code, an installer, etc, the whole thing must become GPL."

    Yes unless you contact us to make a custom commercial or partnership licence.

    This is how we make the development of such an Open Source platform possible :), it is much work and time... and we need to eat :)
  23. RE: Clarification about GPL[ Go to top ]

    This is how we make the development of such an Open Source platform possible :), it is much work and time... and we need to eat :)

    >

    Let me reiterate that I have no problem with what you are doing, or with the GPL license. You wrote it, license it how you want. Hell, I even support what you are doing in principle: making a low-cost alternative to pricey, license restricted enterprise software. (I'm assuming eXo will be low-cost compared with fully commerical portal containers :)

    For something like eXo, however, it would be nice if I didn't have to worry about GPL constraints, as I might want to use portlets from commercial vendors or from other open-source projects, or deploy eXo into Tomcat || Orion || JBoss || Websphere.

    I would also suggest that you make clear eXo's non-GPL license terms, and cost, for potential evaluators. I'm looking at JSR-168 portal containers like eXo, Jetspeed, and Liferay. Along with the underlying technology used, the license of the software matters.

    cheers
    Pratik
  24. RE: Clarification about GPL[ Go to top ]

    I would also suggest that you make clear eXo's non-GPL license terms, and >cost, for potential evaluators.


    Actually we have not defined a template licence for the non GPL one. We are waiting to see how people use the platform and what they wish to do with it.

    It will depends a lot on the compagnies or consultants that would like to distribute the platform. It could go from a simple partnership to a custom commercial licence.

    Once again, compagnies just have to contact us and we will see how we can collaborate.

    >I'm assuming eXo will be low-cost compared with fully commerical portal >containers

    Anyway the cost of the non GPL licence will be truly cheaper than fully commercial portals.
  25. RE: Clarification about GPL[ Go to top ]

    Patrik,

    I'm not 100% up to speed on the terms/conditions of GPL. However, your statement

    >For something like eXo, however, it would be nice if I didn't have to worry >about GPL constraints, as I might want to use portlets from commercial vendors >or from other open-source projects, or deploy eXo into Tomcat || Orion || >JBoss || Websphere.

    what sort of constraints exist? If I take a portlet from a vendor and deploy it into eXo why would this matter?

    I guess I'm missing the point of why GPL affects your decision to use eXo as a Portal solution within your company. I for one am in a similar situation where I am evaluating Portal solutions(For our corp intranet) from many vendors and if I can go open source w/o any problems..all that much better. Significant cost savings.
  26. RE: Clarification about GPL[ Go to top ]

    Have a look to the MySQL licence page :
    http://www.mysql.com/products/licensing.html

    We basically use the same concept.
  27. RE: Clarification about GPL[ Go to top ]

    As I understand , if you use porlet API only, then you can bundle your portlet with Exo , either in binary package or src package, without open your portlet source code.

    [quote]
    You could make life easier for everyone and just license eXo as BSD/MIT licensed ;)
    [/quote]

    And how can we continue to live :-)
  28. Pico[ Go to top ]

    Out of curiosity was Spring evaluated before deciding on Pico?
  29. Pico[ Go to top ]

    Yes it was.

    There were three micro-kernel evaluations :
        * JBossMX micro kernel
        * Spring
        * Pico container

    What we wanted was :
        * as light as possible
        * as less XML as possible
        * IoC pattern implementation
        * dynamic scanning

    Actually we use JBossMX micro-kernel with pico container to provide these features. Little by little we will move to pico only with NanoMX implementation to provide JMX registration of our components (what we call services).

    If you have more precise questions feel free to ask.

    the eXo dev team
  30. Pico Development[ Go to top ]

    I'm developing a framework with pico too, my problem is it's seem that my component for pico is stateful, maybe I have two choices:

    * make a threadsafe container to obtain components, of cause there is componet pool, then when the component come back, reset it.
    * clone componet when clinet code calls container to find component, and then destory it.

    I want to know what solution on your pico and component ?

    Thanks!
  31. Pico Development[ Go to top ]

    We call pico components services and therefore we made them stateless.

    The idea of the pool is a good idea to me (depending on how often you use the pico.getComponentInstance())

    the eXo dev team
  32. Pico[ Go to top ]

    FYI, basicPortal.com is also moving (slowly) towards Pico.

    But we will not support Portlets (nor EJB, or JSF for similar reasons), only (Struts) tiles action + JSTL as now, and then skip portlets/JSF and move to:
    http://www.xmlrpc.com/directory/1568/implementations
    (see how it supports PHP, Perl, etc.)

    iBatis DAO + Pico + XMLRPC + XUL (rendered in browser - via Flash) is the long term plan for us.

    .V
  33. Pico[ Go to top ]

    And Exo Group has supported and will continue to support Portlet, JSF as well the other technoly that you mention ;-)
  34. Pico[ Go to top ]

    Note that I truly think that avoiding the portlet spec is an erro for a portal. Even commercial portal solutions not written in Java like plumtree (35% of the market:) )implements the JSR 168 (they use a trick with web services to contact their Java portlet container from their portal written in...asp)

    Moreover you can build a custom portlets to support XML-RPC and XUL, and btw we studied the possibility do it.

    Last thing got to our demo site to see how we wrap PHP applications in portlets.

    the eXo dev team
  35. Pico[ Go to top ]

    Even Exo uses PHP Forums, no? How much JavaScript or other client side can you do w/ 168?

    Sharepoint, PHP Nukes, Zope, Plone, etc. are popular. all do not support 168, and could use XML RPC.

    pP is a portal based on business needs (Ex: Shopping Cart, Membership mailing, Forums, Content Management, Rich UI, etc.) and not on technology (JSF, EJB,
    168. I also wonder what the licensing on this will be).

    I am trying to use as little technology as possible, KISS Style. ( I find JSF, EJB and 168 technology in search of a problem; ex: people use Ibatis type DAO not EJB; people use rich JavaScript UI such as toolbox calendar tag not JSF, and I find Tiles more useable then Portlets)

    Idea is that this will make bP simpler to teach, maintain and customize. (JSP 2, Struts, Ibatis) with lots of business functionality out of the box.
    I think that having a lot of technology, limits how much businesses you can build on top.
    It will be great to compare some of the popular portals for features they offer as they make production.

    Some people LOVE EJB, some don't. I think people that deploy EJB's now will like 168 and JSF. They are not my customers.

    .V
  36. Pico[ Go to top ]

    [quote] Even Exo uses PHP Forums, no? How much JavaScript or other client side can you do w/ 168?[/quote]

    We use phpbb forum doesn't mean Exo cannot support java portlet forum. We have our own portlet forum and mail portlet that develop with webshere api and we will port to JSR 169 API soon

    [quote]Sharepoint, PHP Nukes, Zope, Plone, etc. are popular. all do not support 168, and could use XML RPC.[/quote]

    We prefer follow java industry standard

    [quote]
    pP is a portal based on business needs (Ex: Shopping Cart, Membership mailing, Forums, Content Management, Rich UI, etc.) and not on technology (JSF, EJB,
    168. I also wonder what the licensing on this will be).
    [/quote]

    We and third parties will develop portlets for shopping Cart , maill portlet , Forum , cms as well. We use GPL license and what is basicportal license

    [quote]Some people LOVE EJB, some don't. I think people that deploy EJB's now will like 168 and JSF. They are not my customers. [/quote]

    We don't love EJB, our default persistent layer implemeatation is hibernate. But we do provide a flexible service API that customer can reimplement using EJB or JDO. And finally , Yes , we love JSF and portlet technology
  37. eXo and Struts[ Go to top ]

    Fortunately, eXo (the most felexible and mature architecutre portal) supports web modules which are developed in Struts framework. These web module very pretty are inplaced in a portlet via a special proxy. For more information refer to http://exo-struts.blogspot.com

    Thank Mr. Benjamin Mestrallet and his staffs for providing this wonderful portal.