Introduction

Since our September article, many things have changed. The number of developers and users have dramatically increased. Big companies have already moved their development environment to the eXo platform and smaller companies are about to use it in production.

By using an open source model we target developers and provide them with many features that make their everyday life easier. Our strategy clearly defines a bottom-up approach.

With this new version, we go even further and prove our compliance with the portlet API specification defined by the Java Community Process, in order to convince and assure managers and decision makers that using the eXo platform is a safe choice.

Furthermore, we maintain our efforts to ease developers’ lives and this new version comes with many new features and services as well as an eclipse plug in.

Non techie part

Compliance

As soon as the specifications were final, we contacted Sun Microsystems for the Technology Compatibility Kit (TCK) software. This tool is a test suite composed of 372 tests.

The concept of the TCK is relatively simple. The licensee has to deploy several portlet application (WARs) in its portal / portlet-container and use the TCK client (HTTP client) to access them. The portlets interact with the portlet-container through the portlet API, and therefore, test the compliance of the implementation.

The test suite documentation was impressive and in two days our team had set up the entire set. After the first test showed 71% compliance, it took us one week to be 100% compliant. We did not encounter any major design problems needing big refactorings, and the fixes were only small details.

The compliance is fundamentally important as this certifies that portlets developed with the eXo platform can be deployed on any other compliant portal and vice versa. Indeed, as many features of the first versions - like hot deployment - really increases developers' productivity and reduces time to market, several large companies have decided to use the eXo platform in development stages. The certified compliance ensures that this is a good development choice. It is now our challenge to convince you that the eXo platform is fit for production.

Finally, sincere thanks to Sun Microsystems, and notably Adam Abramski, for their support and expedient responses.

Business model : dual licences, support and services

Like our code, our strategy is open : we communicate everything.

The eXo platform SARL is a commercial company distributing open source software (OSS) under the GNU/GPL licence. The company also provides commercial licences to Integration Service Vendors (ISVs) and end users. The "end user" licence adds many common warranties on the product we distribute, whereas any open source licence disclaims all responsibilities with the free software. The ISV licence allows integration companies to distribute their product bundled with the eXo platform without forcing them to use the GPL licence. Of course anyone is free to use the GPL licence and we do encourage it. But, as this sometimes is not possible we also propose other options. We enforce no restrictions on anyone, and truly believe this is what open source is about : Freedom.

We aim to delve deeper into the notion of "derivative work", as defined in the GPL licence. We have had many questions on that topic and have experienced that this is not well understood by our cutomers. Distributing the eXo platform with your own portlets that only communicate with the portal/portlet-container through the standard portlet API is possible. You do not have to use the GPL licence for them. This is not a derivative work of our software. But if those portlets use any non-standard extensions implemented by the eXo platform such as filters, message listeners, services etc., then this has to be viewed as "derivative work" and your portlets should also be distributed under the GPL licence.

Now, a few essentials about Intellectual Property (IP). Many open source committers are poorly informed on this very important point. In order to provide several licences for the same code source, the eXo platform SARL company requires a copy of the IP from every committer. This is a copy of the developer rights, and the concept of copy is of importance. When a developer commits code to the eXo platform project and provides a copy of its IP he does not part with it. He may still do anything with his code, and use it in any other project using any other licence. It is his code and IP, and with the copy he extends the company the same rights.

In exchange for these rights we reward credits for all tasks, issues and bugs. Once a task is completed and unit tested the developer's account is credited. Every three months we distribute 75% of the net revenues from licence sales to all committers (individual or company) according to their rewarded credits. The eXo platform project is composed of several modules that each have a credit budget for a three month period. Each module is managed by a leader that defines the amount of points rewarded for each task within his module.

This innovative approach to collaboration has already attracted many developers and companies. There are presently 6 very active developers, 4 of them working full time, including weekends! Please, join the consortium!

The eXo platform SARL provides services and support for its products. For more detailed information please browse the www.exoplatform.com site.

Roadmap

The eXo platform is based on several projects also in final development stages, such as Java Server Faces, Pico container or jBPM (Java Business Process Management).

The JSF team is expected to release a new version by year's end, and a final one within the first quarter of 2004. Pico Container is in beta3, with the next, final release expected soon. jBPM 1.0 is almost final and the current version (beta 5.2) is stable.

When all these products are out, we will release our first 1.0 version, probably during first quarter of 2004. We may release a last beta version in the begining of February. The next big step is then to support the Oasis WSRP standard.

Our intention is to challenge and compete with commercial solutions providing integrated Portal - Content Management Systems (CMS). There is still work to be done to tightly couple our workflow engine with our CMS repository, but our first version will be a viable open source alternative to very expensive, closed commercial solutions

Development environment

The goal of this section is to introduce the reader to the portlet API by showing a small tutorial on how to create a Hello World portlet and to test it with the eXo platform. Then, we introduce the eXo platform Eclipse plug-in, a tool that improves developers' productivity while implementing portlets.

Your first Hello World portlet

A basic portlet should extends the GenericPortlet class from the portlet API. It provides several methods like doView(), doHelp() that are called by the render() method of the GenericPortlet according to the current mode. The Hello World portlet code we will show is quite simple : it has dedicated behaviour for normal window state.

public class HelloWorldPortlet extends GenericPortlet {

  private static final String HELLO_TEMPLATE = "/WEB-INF/templates/html/HelloWorld.jsp";

  public void init(PortletConfig config) throws PortletException {
      super.init(config);
    }

  public void doView(RenderRequest request, RenderResponse response)
    throws PortletException, IOException {
    WindowState state = request.getWindowState();
    response.setContentType("text/html") ;
    if (state == state.NORMAL) {
      Writer writer = response.getWriter() ;
      writer.write("<center><img src='/HelloWorld/images/hello-world.png'/></center>");
      writer.write("<center>Hello Portal World in View Mode</center>");
    }
    PortletContext context = getPortletContext() ;
    PortletRequestDispatcher rd = context.getRequestDispatcher(HELLO_TEMPLATE) ;
    rd.include(request, response);
  }
  [...]
      

In the normal state we get a PrintWriter from the RenderResponse object and write directly into it. In any other window state (including the normal one), we use a PortletRequestDispatcher to include the content of a jsp page : HelloWorld.jsp. Obtaining the current state is very easy : request.getWindowState(). As the portlet API leverages the servlet API, the code is quite similar to what you write for a simple servlet. Even the init() method, that uses a PortletConfig object, uses almost the same signature as the corresponding servlet one.

The jsp page does not change much either. To obtain the portlet objects you need to either use some tags defined in the API or simply get them as request attributes :

<%@ page import="javax
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] 下一页 
    
 进入问吧