eXo Platform Merges Portal Software Dev into JBoss Community

Discussions

News: eXo Platform Merges Portal Software Dev into JBoss Community

  1. I'm glad to announce to the TSS community an important partnership between Red Hat and eXo Platform. The official communiqués from both side http://press.redhat.com/2009/06/10/jboss-org-community-grows/ http://www.businesswire.com/portal/site/google/?ndmViewId=news_view&newsId=20090610005342&newsLang=en Here is my official blog post on the partnership that gives a more informal view on what's going on: http://blog.exoplatform.org/2009/06/10/exo-jboss-partnership/
  2. Congrats to Julien and Benny. A funny turn of events.
  3. thanks buddy! glad to see you're still alive
  4. This is a great marketing message but reality is... JBoss cant even consolidate or upgrade their current projects as it stands. I'm sure that adding a new project and new partner company will not help this AT ALL! AS5 has been out for a while and no support for JBoss Portal running on it! jBPM, Drools (expanded components), and now 2 portal projects.... Come on folks.. produce a stack that actually works together and forget about marketing hype!
  5. Hi Art, this is the goal to produce a common portal. I think you misunderstood the announcement, there are good faqs that describe what happens from each side: http://www.exoplatform.com/portal/public/website/aboutUS/eXoJBossPartnership http://www.jboss.org/community/wiki/JBossPortal-eXoPortalFAQ cheers
  6. Art, For AS5 + JBoss Portal you would need to build it yourself, it's all explained here: http://www.jboss.org/community/wiki/JBossPortalonAS5 As all our efforts are going to the new merged project we don't have plans to release JBoss Portal 2.7 on AS5 but instead work on the merge with eXo Portal. The stack that we sell and support is called Enterprise Portal Platform 4.3. This is a mature stack. EAP 5.0 is coming and so will come EPP 5.0. About your idea of consolidation, jBPM is a workflow engine, JBoss Rules is a rule engine, 2 different things. Now you can argue that you may want to take decisions (and direct your workflow) using rules, this is the goal of what is explained here: http://docs.jboss.org/seam/2.0.2.CR1/reference/en-US/html/drools.html#d0e7004
  7. About your idea of consolidation, jBPM is a workflow engine, JBoss Rules is a rule engine, 2 different things. Now you can argue that you may want to take decisions (and direct your workflow) using rules, this is the goal of what is explained here:
    http://docs.jboss.org/seam/2.0.2.CR1/reference/en-US/html/drools.html#d0e7004
    Actually consolidation of rule engines and workflow engines makes perfect sense and what we have done in Drools 5.0, along with event processing too, as announced on TSS here: http://www.theserverside.com/news/thread.tss?thread_id=54698 We now have 3 main sub projects, among others, to reflect this - Drools Expert, Drools Flow and Drools Fusion. You can find out more details of Drools Flow here: http://www.jboss.org/drools/drools-flow.html I'll quote part of that page here: "Drools 5 is a complete rethink (not reimplementation) from the bottom up, with a new public api and everything designed with rules, processes and events as first class citizens - no feature is added without making sure that is is seamless, unified and orthogonal. Because processes, rules and events are integrated into the same engine, all three paradigms can easily take advantage of the common features (when you add a feature to one paradigm it is accessible to the others as well). There is simply no reason for multiple apis and deployment approaches that at best only burden the user with more complexity and at worst introduce impedance mismatches when two differing projects are used together. The traditional way of using two different offerings forces the user to work with a process-oriented or rules-oriented approach, which just gets in the way, often with great confusion over which tool they should be using to model which bits. Drools is a move away from a rule-centric or process-centric attitude to a more behaviour modelling approach with a lot more flexibility for users to model their problems how they want, creating a more holistic approach to software development (where the term holistic is used for emphasizing the importance of the whole and the interdependence of its parts). We do not believe in the process-centric approach only, where rule integration or event processing integration are not being considered or will be added as an after-thought rather then a basic principle from the beginning. This usually means that rule integration is limited to a stateless rule session being invoked in a process node (with all the mapping, marshalling and unmarshalling and consistency problems as a result). Being process-oriented also forces the user to learn duplicate, but different, apis and deployments approaches, will not provide one tool chain for supporting the life cycle of the business knowledge (like for example a unified knowledge repository and management tool as Drools Guvnor, or provide important features such as correlated audit logging and reporting."
  8. LGPL will be a nice addition to EXO portfolio. AGPL is really, *really* not compatible with the real world
  9. Think LGPL only applies to the Portal layer. Looked over EXO and looks very nice, but the components over the Portal are still GPL, nothing bad about this, just impossible to "openly" extend for specific domain areas. For example, how can I extend CS to a Clinical Trials domain branch? How can I use other non GPL technologies with EXO? Also, is EXO really open source, where can we download CS version 1.3 development? So far, looks like Nuxeo is the most "open" best way to start, their technical documentation and access to "all" source code repositories speaks for itself! Could someone from EXO respond to these concerns?
  10. Indeed, LGPL applies to eXo JCR and JBoss eXo Portal. Regarding the GPL licensing of the eXo applications, that applies only to software distribution. If you do distribute your code that extends code based on GPL then you will have to license your code to GPL. That does not affect other technologies you would use along with eXo because they are not consuming eXo, it's just your product that use those technologies along with eXo. You can get the CS 1.3 from its trunk : http://svn.exoplatform.org/projects/cs/trunk/ Hope it answers your questions.
  11. Well, it seems that this future joint effort will be released under the LGPL. I was talking about that - I also find impossible working with GPL (and affero GPL is even worse)
  12. CS 1.3[ Go to top ]

    Also, is EXO really open source, where can we download CS version 1.3 development?
    I am working for eXo. As you seem to know, eXo CS 1.3 is work in progress. A first beta should be available soon on OW2 forge : http://forge.ow2.org/projects/exoplatform Until then, you can checkout the code here : http://svn.exoplatform.org/projects/cs/trunk/ Regards, Patrice