Michael D'Amour on Pentaho Platform Architecture

Pentaho Admin/Enterprise Console in SUGAR

2012-02-29T09:34:00.000-08:00

If you've grabbed a recent build of SUGAR you'll notice some obvious changes to the UI as well as a top-level directory structure which is totally missing. The "administration-console" (or "enterprise-console") folder has been removed. We are actively working to integrate PAC/PEC functionality in the Pentaho User Console as an Administration perspective.

The layout of the Administration perspective is defined in mantle.xul (pentaho/mantle/xul/mantle.xul). This will allow the possibility of changing the UI and/or removing UI elements. Presently, we have action-based security (ABS) and authentication (Pentaho/LDAP) implemented in this UI. In the upcoming weeks we'll be adding other missing parts from the admin console such as email/auditing.

Here's a recent screenshot of the Administration perspective:

How to Add New Admin Functionality

New functionality can be plugged into the admin perspective with a platform plugin. The plugin.xml of a platform plugin will have a XUL overlay section to add an item to the admin category tree. For example, if you want to add a new item to the "security" category you would do this to the plugin.xml:

<overlays>
    <overlay id="admin.perspective.overlay.ee" resourcebundle="content/my-admin/resources/messages/messages">
        <treechildren id="security">
            <treeitem command="mantleXulHandler.loadAdminContent('my-admin-panel', 'api/repos/myadmin/resources/my-admin.html')">
                <treerow>
                    <treecell label="${myadmin.label}" />
                </treerow>
            </treeitem>
        </treechildren>
    </overlay>
</overlays>

We are adding a new panel to the admin perspective with an ID of 'my-admin-panel' and we are specifying the location of the UI (by URL). At this point you have adding your content to the admin category tree. Just like any plugin, you can have back-end code in a JAR, eg my-admin/lib/my-admin-plugin.jar.
Even more interesting is the new capability of a platform plugin to easily register its REST services in the plugin.spring.xml. We're using Jersey (v1.12) for exposing these web services. For reference take a look at the echo-plugin.

Finishing the Job: JavaScript Integration

Whatever your choice of JavaScript library, you will be coexisting with PUC/admin perspective. While not required, you can improve the user experience by registering your UI for state changes, etc. To do this create an object with an id and activate/passivate methods. For example:

var myAdminPanel = {
    id : "my-admin-panel",
    activate : function() {
        refreshConfig();
    },
    passivate : function(passivateCompleteCallback) {
        if(isConfigDirty()) {
            passivateCallback = passivateCompleteCallback;
            dijit.byId("saveChangesDialog").show();
        } else {
            passivateCompleteCallback(true);
        }
    }
};

Now register this object with the admin perspective:
window.top.mantle_registerSysAdminPanel(myAdminPanel);

That's all there is too it, you will be notified when the user selects on/off of your panel so you can check for "dirty" and prompt for saving.

REST services

In order to support the new admin functionality added to PUC, we added several new REST services which might be generally useful to OEMs, integrators, and developers.

/pentaho/api/userrole/users
Using GET, will return a list of all users in the system.

/pentaho/api/userrole/roles
Using GET, will return a list of all runtime roles in the system.

/pentaho/api/userrole/roleAssignments
Using PUT, will set role bindings between roles and permissions (logical roles)

/pentaho/api/userrole/logicalRoleMap
Using GET, will return the list of roles and the permissions (logical roles) which are assigned to them

The following LDAP REST API calls are in the EE product

/pentaho/api/ldap/config/getAttributeValues
Using GET, returns all name/value pairs from applicationContext-security-ldap.properties, plus the current securityProvider

/pentaho/api/ldap/config/setAttributeValues
Using PUT, sets (merges) name/value pairs and saves them to applicationContext-security-ldap.properties as well as set the authentication type in pentaho-spring-beans.xml.

/pentaho/api/ldap/config/ldapTreeNodeChildren
Using GET, returns the list of

/pentaho/api/ldap/config/userTest
Using GET, simple test if a user can be found.

/pentaho/api/ldap/config/rolesTest
Using GET, tests if search for a user returns roleAttribute successfully.

/pentaho/api/ldap/config/userRolesTest
Using GET, will perform a populator test (check if granted authorities for the given user works)

/pentaho/api/ldap/config/providerTest

Scheduling and Workspace in SUGAR

2011-11-16T06:43:00.001-08:00

With the recent addition of perspectives to the Pentaho User Console (PUC) we opened up a whole new way to integrate with the BI platform. This will go a long way for customers and OEMs who want to add (or remove) functionality from PUC. Having said this, we are currently developing new perspectives for the SUGAR release. Sean Flatley has been developing a PDI admin perspective (based on CDF). There are also plans to create an admin perspective (or add to the PDI admin) to replace the admin console (PAC and PEC).

Recently, I have been developing a total replacement for the PUC workspace, which was in dire need of TLC. When PDI added scheduling capabilities against our DI server, this was against a brand new scheduling system. As of yet, we hadn't taken advantage of this in the BI server. All of this changes in SUGAR, the old scheduler is completely removed, the new scheduler has taken over! Rather than get our existing (pre-SUGAR) workspace to work against the new scheduler, we spent some time re-writing it. The new workspace makes all scheduler interactions using REST. This means that it will be easy for other developers to interact with the scheduler in their own interfaces.

Scheduling with REST
I mainly wanted to highlight the new workspace in this post, but I figured there might be a fair amount of outside interest in learning about scheduling + REST. We have held up our end of REST purity in that GET, POST and DELETE HTTP methods are used where appropriate. Simple results are returned as text/plain, while complex state (such as a list of jobs) can be returned as either XML or JSON. Whatever your client-side technology of choice is, you can set the "accept" HTTP header to instruct the server to return the desired type back. For example, myrequest.setHeader("accept", "application/json") will cause the scheduler REST service to return results back (if supported) as JSON.

The URLs listed in the examples below assume that your BI server is running on "localhost" port 8080.

Scheduler State
To get the state of the scheduler make a GET request to:
http://localhost:8080/pentaho/api/scheduler/state

The return type for this is text/plain and the result will be one of:
RUNNING, PAUSED or STOPPED

To control the state of the scheduler you must make a POST request. In order to start or resume the scheduler as a whole:
http://localhost:8080/pentaho/api/scheduler/start

To pause the scheduler:
http://localhost:8080/pentaho/api/scheduler/pause

To shutdown the scheduler (must be rebooted after a shutdown):
http://localhost:8080/pentaho/api/scheduler/shutdown

Remember, these are POST requests, you cannot just paste the URL in a browser and expect them to work (would be a GET request this way).

Listing Jobs
Since listing jobs does not change any state on the server, the request for getting the list of jobs is a GET.

The following URL can be used as GET request and will return XML or JSON.
http://localhost:8080/pentaho/api/scheduler/jobs

Job State
Like the scheduler itself, we can interact with the running state of an individual job. Getting the state of a specific job requires that you submit the jobId (which is given in the list jobs REST call). You can only get the state of a job that you created (own), unless you have administration privileges.

To get the state of a job, the REST url is:
http://localhost:8080/pentaho/api/scheduler/jobState

You must submit JSON or XML wrapping the jobId. For example, the JSON request payload:
{"jobId":"joe:1685214344:1321154720424"}

The request header for the "Content-Type" is also set:myrequest.setHeader("Content-Type", "application/json");

The return type for this is text/plain and the result will be one of:
NORMAL, PAUSED, COMPLETE, ERROR, BLOCKED or UNKNOWN

Altering the state of a job is not much different than getting the state except that a POST request must be made. The REST urls are:
http://localhost:8080/pentaho/api/scheduler/resumeJob
http://localhost:8080/pentaho/api/scheduler/pauseJob

Triggering a Job Immediately
To trigger the immediate execution of a job, you can invoke the triggerNow REST endpoint (POST) with the jobId wrapped with JSON or XML. You must be authorized to execute the job in order to trigger it.

Deleting a Job

To remove a job from the scheduler, you can invoke the removeJob REST endpoint (DELETE) with the jobId wrapped with JSON or XML. You must be authorized (job owner or admin) to delete the job from the scheduler.

Creating a New Job

This is the most complex part of interacting with the scheduler. In order to represent a new schedule, there are 3 "trigger" types, simple, complex and cron.

I'm just going to give some examples rather than document every possible combination. First, let's use a simple schedule, run the Inventory.prpt every 4 hours until December 31, 2012. The JSON payload would be:

{"inputFile":"/public/pentaho-solutions/steel-wheels/reports/Inventory.prpt", "outputFile":null, "simpleJobTrigger":{"repeatInterval":14400, "repeatCount":-1, "startTime":"2011-11-16T00:00:00.000-05:00", "endTime":"2012-12-31T23:59:59.000-05:00"}}

The inputFile is the full path to the Inventory.prpt resource. We're using a simple trigger, meaning that we don't worry about special recurrence patterns, we just want to run every 4 hours until the "endTime" has been reached. The repeatInterval is 14400 seconds which equals 4 hours. If you want to repeat a specific number of times until the trigger is no longer fired (in lieu of endTime) you can give a repeatCount. A repeatCount of -1 means forever.

Next, let's imagine we want to schedule the Produce Line Sales.prpt every Sunday at 2am with no end date.

The REST endpoint is http://localhost:8080/pentaho/api/scheduler/createJob. The JSON payload would be something like this:

{"inputFile":"/public/pentaho-solutions/steel-wheels/reports/Product Line Sales.prpt", "outputFile":null, "complexJobTrigger":{"daysOfWeek":["0"], "startTime":"2011-11-16T02:00:00.000-05:00", "endTime":null}}

Dissecting this, we can see the inputFile is set to the full path to the scheduled resource. We are creating a "complex" job trigger with a recurrence pattern of "daysOfWeek" including just "0" meaning Sunday, the days range from 0-6. If the trigger was going to be for multiple days of the week, this would be given as "daysOfWeek":["0","1"]" (for Sunday/Monday). All times are in ISO_8601 date format (this is true for dates coming out of the scheduler REST services as well). The startTime specifies the "from" date and endTime refers to the date at which the schedule will no longer be run. A null value for the endTime means it has no end.

Another example, "The last Friday of every month at 4am" would have a JSON payload of:

{"inputFile":"/public/pentaho-solutions/steel-wheels/reports/Income Statement.prpt", "outputFile":null, "complexJobTrigger":{"weeksOfMonth":["4"], "daysOfWeek":["5"], "startTime":"2011-11-16T04:00:00.000-05:00", "endTime":null}}

Finally, a yearly schedule, "Every January 1st at midnight":

{"inputFile":"/public/pentaho-solutions/steel-wheels/reports/Invoice Statements.prpt", "outputFile":null, "complexJobTrigger":{"monthsOfYear":["0"], "daysOfMonth":["1"], "startTime":"2011-11-16T00:00:00.000-05:00", "endTime":null}}

The Workspace
With all the REST details behind me now, I can finally cover some new UI work that I've been working on the past few weeks. As I said before, the new workspace interacts with the server exclusively through REST web services, meaning that it is possible for someone with better UI skills to replace it (by removing the default one from the default-plugin/plugin.xml).

The old workspace listed all content for each schedule, this was unbelievably unmanageable, it was also rather clunky when it came to starting/stopping/removing schedules and their output content. It also lacked the ability to manage the scheduler as a whole (start/stop).

The new workspace lists schedules (aka jobs), not content (output) from those jobs. You can start/stop the entire scheduler or pause/resume individual jobs. A human readable description of each schedule is provided. Each column in the table view can be sorted. If there are many schedules, the table will enter a "paging" mode. If there are still too many schedules to find what you are looking for you can easily add a filter. You can multi-select (with the help of CTRL or SHIFT keys) and manage many schedules at once. Selected jobs can be triggered to run immediately, paused, resumed or removed permanently. When you click on a cell in the file (resource) column you can view and manage (TBD) content from previous executions of that schedule.

Workspace View showing multi-select "pause" (notice state of selected items)

You can filter the list of jobs by file, state, user, schedule type and execution times

Selecting a file link will show past execution history and allow content to be viewed.

We're not done with the scheduling yet, but we've been making incredible progress. We still need to finish (WIP) parameter support and define (TBD) what content management can be done from the history (generated content dialog).

Plugin Overlays, PUC Layout

2011-11-01T07:16:00.000-07:00

I was thinking about my previous post on PUC Perspectives and some of the things that were necessary to make that happen when it dawned on me that I hadn't really highlighted some really cool changes. There are two primary changes that are worth talking about: menubar and PUC layout.

Menubar
The PUC menubar was a GWT menubar, standing not much different than it did in the proof-of-concept that I did back in March 2008. James Dixon later extended upon this by adding the ability to define "menu customizations" through our plugin system. What we really needed though was a total rewrite of the menu system but the prospect of making such a drastic change was never a priority. Fortunately, we were able to justify the rewrite with the fact that without it, the capability of doing perspective overlays for the menubar were going to be pretty darn near impossible. That is, without adding hacks upon existing hacks. And so, the menubar was rewritten and XULified.

We now have a main_menubar.xul which defines the content and layout of the main menubar. This will make it MUCH easier for 3rd party/OEMs to add/remove/update any/all of the behavior of the menubar simply by tweaking the XUL file.

This means that plugin.xml which used to contain "menu-items" will now use an overlay. Most plugins which defined menu-items already had an overlay section to define toolbar tweaks. The same overlay section is used for both menu and toolbar changes, for example,

<overlay id="startup.analyzer" resourcebundle="content/analyzer/resources/messages">

    <toolbar id="mainToolbar">
      <toolbarbutton id="newAnalysisButton" image="../api/repos/xanalyzer/images/analyzer_toolbar_icon.png" onclick="mainToolbarHandler.openUrl('${tabName}','${tabName}','api/repos/xanalyzer/service/selectSchema')" tooltiptext="${openNewAnalyzerReport}" insertafter="dummyPluginContentButton"/>
    </toolbar>
    <menubar id="newmenu">
      <menuitem id="new-analyzer" label="${openNewAnalyzerReport}" command="mainMenubarHandler.openUrl('${tabName}','${tabName}','api/repos/xanalyzer/service/selectSchema')" />  
      </menubar>    
</overlay>

There are a few subtle differences here with pre-SUGAR overlay definitions. I have fixed the annoying bug in the plugin system which required the nesting of an overlay inside of an overlay (simply due to XML parsing bug), for example:

<overlay id="startup.analyzer"  resourcebundle="content/analyzer/resources/messages">
    <overlay id="startup.analyzer"  resourcebundle="content/analyzer/resources/messages">

Another benefit is that overlays can have resource bundles associated with them, while the old menu-item section did not. This allows us to localize the display strings in the menu system.

PUC Layout

I was recently asked by James Dixon if it would be possible to update the entire layout of PUC with XUL. I said we needed to get the story on our sprint backlog, which I ended up doing (BISERVER-6693). Instead of using XUL, which might be a barrier to entry for some customers/OEMs, a much easier solution to the PUC layout actually exists: just use HTML. What if the PUC layout existed in HTML and we just inject into various id's? So, in SUGAR, I have done just this, the layout of PUC is based on DIV tags in the HTML (Mantle.jsp). When PUC loads, it no longer "takes over" the page, it now looks for certain elements by id, such as "pucMenuBar" or "pucPerspectives" and then injects the widget at that location. This will allow easier customization, for example, in SUGAR we have actually removed the "logo panel" from PUC itself. With the DIV-based layout, we can easily add a logo panel back into the product by editing the HTML. This is still a work in progress, the "pucContent" is very high-level and refers to the entire bottom section of PUC (explorer + content). The next phase will be to define the layout even further, but we've taken steps towards this direction and what has been done is beyond concept, it's committed.

The layout of PUC can be defined as something as simple as this:

<div id="puc" style="height: 100%">

    <div id="pucTopBar" style="background-color: black; height: 28px">
        <div id="pucMenuBar" style="float: left">
        </div>

        <div id="pucPerspectives" style="float: right;">
        </div>
    </div>

    <div id="pucToolBar" style="clear; both; float: left; width: 100%">
    </div>

    <div id="pucContent" style="clear: both; height: 100%; width: 100%">
    </div>

</div>

Enjoy!

PUC Perspectives

2011-10-21T08:47:00.000-07:00

Pentaho User Console Perspective Documentation for Developers

What is a perspective?

Perspectives are a specialized mode added to the Pentaho User Console (PUC) for the next release of the suite (SUGAR). Active development is still very much underway, but I wanted to highlight this really cool new feature. CI builds of Sugar are available at http://ci.pentaho.com/view/Sugar/.

A perspective changes the behavior and appearance of PUC by taking over certain areas of the interface. The PUC main toolbar and main menubar are now easily setup with XUL overlays. The content area of PUC can also be completely owned by a perspective. In this way, PUC can be dramatically customized. Switching perspectives is done by clicking on them in the upper right hand corner.

How to register a perspective

From an API standpoint, registering a perspective with the system simply means adding the right objects to the perspective manager. There are two interfaces of concern here, IPluginPerspective and IPluginPerspectiveManager. IPluginPerspectiveManager is added to pentahoObjects.spring.xml making it available through PentahoSystem. The easiest way to add a perspective to the system is to simply add its definition to the plugin.xml of a plugin. However, you are not constrained to this, you can register a new perspective through the API. For example,

IPluginPerspective perspective = new DefaultPluginPerspective();
perspective.setId(..);
perspective.setOverlays(..);
etc.

IPluginPerspectiveManager manager = PentahoSystem.get(IPluginPerspectiveManager.class, getPentahoSession()); 
manager.addPluginPerspective(perspective);

Implementing the interfaces

Should you decide to implement your own perspective interfaces and replace ours, there are only a few interfaces to concern yourself with. The first thing you must do is replace the IPluginPerspectiveManager in pentahoObjects.spring.xml, for example:

<bean id="IPluginPerspectiveManager" class="com.yourcompany.BetterPerspectiveManager" scope="singleton" />

Once you've done this, and your class is available to the system your plugin perspective manager will be used to register perspectives. PUC will use PentahoSystem to use your manager to list the available perspectives. A perspective itself must extend IPluginPerspective, for example:

public class MyPluginPerspective extends IPluginPerspective {
 ..
}

This class is just a bean and provides:

id (unique perspective id)
title (name of the perspective shown in PUC)
content-url (the url of the page used to hijack PUC content area)
resourcebundle (the uri to a message bundle for localizing the title of the perspective)
overlays (xul overlays to apply to menu/toolbar of PUC)
layout-priority (used to control the order which perspectives show up in PUC, BI Browser is -1)
required-security-actions (action based security can be used to check if the user "isAllowed")

The easy way: How to define perspectives in plugin.xml

The plugin system in Pentaho has been expanded to read perspective definitions from the plugin.xml of a plugin in pentaho-solutions. Any number of perspectives can be added to a single plugin.xml.

<plugin title="My Plugin" name="my-plugin">
  <perspective id="myperspective1" title="Perspective 1" layout-priority="1">
  </perspective>
  <perspective id="myperspective2" title="Perspective 2" layout-priority="2">
  </perspective>
...and so on
</plugin>

If you want to localize the title of the perspective as it appears in PUC you'll need a resource bundle accessible to PUC at runtime. The URI is specified on the perspective definition:

<perspective id="myperspective1" title="${title}" layout-priority="1" resourcebundle="content/default-plugin-perspective/resources/messages/messages">
</perspective>

The plugin "default-plugin-perspective" is a folder in pentaho-solutions/system and contains a messages.properties file located in 'default-plugin-perspective/resources/messages'. This can be made available by publishing a static-path in the plugin config:

<static-paths>
 <static-path url="/default-plugin-perspective/resources" localFolder="resources"/>
</static-paths>

The string ${title} is replaced with whatever title means in the messages.properties file (or other localized
bundles).

As mentioned before, a perspective will takeover the content area of PUC when it is active. The URL for this is specified with the content-url attribute of the perspective. For example:

<perspective .... content-url="content/default-plugin-perspective/resources/html/index.html">

When this perspective is made active, index.html is loaded in an iframe in the content area of PUC.

Action based security may be used to lock perspectives down, for example, only show an "Admin" perspective to those who are allowed to see it. This is done using the existing action based security provided by the Pentaho platform. The security action for administration is "org.pentaho.security.administerSecurity". To specify this in the perspective definition:

<perspective .... required-security-action="org.pentaho.security.administerSecurity">

In PUC, the order that the perspectives show up in the UI is controlled by a layout-priority attribute in the perspective node. The default perspective (BI Browser) has a value of -1. If you want your perspective to appear before this go with a lower number (such as -2).

One of the most fundamental changes to PUC for the addition of perspectives was to completely replace the menu system with a XUL approach. We already had a XUL definition for the main toolbar, now there is a XUL definition for the main menubar. This file is webapps/pentaho/mantle/xul/main_menubar.xul. You can further customize PUC by changing this XUL file. What we are interested for the purpose of perspectives is the ability to modify the toolbar and menubar with XUL overlays. A perspective can provide any number of XUL overlays which are used to add/remove/update items to the toolbar or menubar. Here is a simple example:

<perspective>
 <overlay id="myoverlay"  resourcebundle="content/default-plugin-perspective/resources/messages/messages">
        <toolbar id="mainToolbar">
            <toolbarbutton id="mybuttonid" image="../content/default-plugin-perspective/resources/images/enabled32.png" onclick="mainToolbarHandler.executeMantleFunc('defaultTestPerspectiveFunction();')" tooltiptext="${mybutton}"  insertafter="dummyPluginContentButton"/>
        </toolbar>   
 </overlay>
</perspective>

This XUL overlay will add a button to the main toolbar with a given image, title, tooltip, insertion point, etc. Menu items can be added anywhere in the menu system in a similar way:

<perspective>
 <overlay id="myoverlay"  resourcebundle="content/default-plugin-perspective/resources/messages/messages">
  <menubar id="mainMenubar">
   <menubar id="newmenu">
    <menuitem id="mymenuitemid" label="${mymenuitemlabel}" command="mainMenubarHandler.executeMantleFunc('defaultTestPerspectiveFunction();')" />  
   </menubar> 
  </menubar> 
 </overlay>
</perspective>

This will add a menuitem under the File -> New menu. You can actually add an entirely new menu if needed. This can be done by giving a more complete definition in the XUL:

<menubar id="mainMenubar">
 <menubar id="mymenu" label="${mymenu}" layout="vertical" insertafter="toolsmenu">
  <menuitem id="mymenuitem" label="mymenuitem" js-command="alert('Item Clicked')" />  
 </menubar>
</menubar>

When a perspective is active, its overlays will be in play, likewise, when it becomes inactive, its overlays are removed. It is possible for a perspective's overlays to make permanent changes to the UI, instead of just when it is active. This is done simply by convention, an overlay whose "id" starts with "sticky" or "startup" will be active even when the perspective is not. Typically, you would create two overlays for a perspective, one for changes to apply when the perspective is active and another to apply because the plugin exists.

For example:

<overlay id="sticky.myoverlay" resourcebundle="content/default-plugin-perspective/resources/messages/messages">

...

This overlay will be applied regardless of the active state of the perspective.

Interactivity

It is now possible to more easily interact with the main menubar and toolbar with JavaScript. If your content-url points to an HTML page you can use JavaScript to enable/disable any menu item or toolbar button

To read the state (enabled/disabled) of a toolbar button:

var enabled = window.top.mantle_isToolbarButtonEnabled("button.id");

To set the state of a toolbar button:

var enabled = true; // or false
window.top.mantle_setToolbarButtonEnabled("button.id", enabled);

To read the state of a menu item:

var enabled = window.top.mantle_isMenuItemEnabled('menuitem.id'))

To set the state of a menu item:

window.top.mantle_setMenuItemEnabled('menuitem.id', enabled)

We have also made it easier to bridge between the XUL/GWT world for defining what happens when you press a button or select a menu item. Of course, there are the existing techniques, referencing the handler and a bound function to invoke a well known PUC command, for example:

<toolbarbutton .. onclick="mainToolbarHandler.executeMantleCommand('SaveCommand')" />
<menuitem .. command="mainMenubarHandler.executeMantleCommand('OpenFileCommand')" />

If you want to invoke arbitrary JavaScript with a toolbarbutton or menuitem, you can alternatively define a
js-command attribute in the XUL definition. For example:

<menuitem .. js-command="alert('Hello Perspective')" />

When the menu item is pressed the JavaScript alert function will pop a message saying "Hello Perspective". In this way, we can invoke JavaScript functions defined by the page living at the content-url. Since we are crossing the boundaries of iframes and we don't necessarily know where to call the function, we always eval the JavaScript as it is provided to us. What this means is that you should define any functions you want visible to the toolbar buttons or menu items at the "top" window. An example of this:

<script type="text/javascript">
 window.top.myPerspectiveFunction = function() {
  alert('Success!');
 }
</script>

To invoke this function from a toolbar button or menu item:

<menuitem .. js-command="myPerspectiveFunction()" />

Update: 11/1/2011
We have added activation/deactivation hooks, if the document (content-url) contains javascript functions "perspectiveActivated" and "perspectiveDeactivated" then we the perspective system will invoke them at the appropriate time. This can be used for any purpose you see fit, practically however, this was created to allow the persistence of perspective state that might otherwise be lost. For example, when a perspective is activated (or reactivated) we can restore the toolbar state (buttons enbabled/disabled). Without the behavior, the XUL overlays are reapplied from the beginning without knowledge of any application state. An example:

<script type="text/javascript">
 
  var testButtonEnabled = true; 
  
  perspectiveActivated = function() {
    window.top.mantle_setToolbarButtonEnabled('some.button.id', testButtonEnabled);
  }  
  
  perspectiveDeactivated = function() {
    testButtonEnabled = window.top.mantle_isToolbarButtonEnabled('some.button.id');
  }  
  
</script>

This example has been checked in along with the existing sample plugin perspective.

Additional JavaScript interaction has been added as well. You can get a list of perspectives (array of perspective ids) and activate a perspective by id. Example use:

window.top.mantle_getPerspectives()

and

window.top.mantle_setPerspective(id)

Sample Perspective

Many of the features and functionality discussed here are available as a self-documenting sample plugin perspective located in pentaho-solutions/system/default-plugin-perspective/plugin.xml.

Platform Update - Consolidation & Cleanup

2011-10-13T08:46:00.000-07:00

I wanted to take a few minutes to detail the progress in the platform projects. As most of you know, we have gone through a round of project consolidation in the platform. The new projects are as follows:

===================================================
api - unchanged

core

- bi-platform-engine-core
- bi-platform-engine-security
- bi-platform-engine-services
- bi-platform-test-foundation
- bi-platform-ui-foundation
- bi-platform-util
- bi-platform-security-userroledao

The engine-* projects had previously enjoyed a GPL license, this remains unchanged, however, the license the projects brought into the core is now GPL if not already.

repository - relatively unchanged (this is the JCR)

scheduler - we have dropped the old scheduler, scheduler2 takes over

extensions

- bi-platform-web
- bi-platform-web-servlet
- bi-platform-plugin-actions
- bi-platform-plugin-services

user-console - though future plans for mantle include making it a plugin, it is out of the old bi-platform-v2/trunk and renamed

assembly

- bi-platform-appserver
- bi-platform-assembly
- bi-platform-build
- bi-platform-sample-data
- bi-platform-sample-solution

We have also removed several projects, such as portlet, legacy, and test-solution.

The dependency order is also, as I have listed the projects:
api, core, repository, scheduler, extensions, user-console
===================================================

All of the new projects produce new ivy artifacts, as to not overwrite anything already in artifactory. We have incorporated changes to subfloor allowing the publishing of test jars. For example, the core project's test-src contains classes essential for testing in many downstream projects.

api - pentaho-platform-api.jar
core:

- pentaho-platform-core.jar
- pentaho-platform-core-test.jar (BaseTest and friends)
repository:

- pentaho-platform-repository.jar
- pentaho-platform-repository-test.jar
scheduler - pentaho-platform-scheduler.jar
extensions - pentaho-platform-extensions.jar
user-console - pentaho-user-console.jar (typically resolved is the package/zip)

With the introduction of the JCR the notion of "solution" "path" "name" goes away and we simply have a single path to the resource "/path/to/the/resource". I have modified the API of SolutionEngine so that it only accepts this single path element and fixed all (known) downstream implications.

Unit tests are in outstanding shape right now and cobertura coverage is being published. I spent 2 days doing nothing but getting unit tests working again. Many of the unit tests which are now working have not been working since 2009 (some even earlier than that). Plenty of unit tests were commented out, where possible, I have uncommented these and they are now working. The unit test summary:

core - 100% unit test pass
repository - 100% unit test pass
scheduler - 100% unit test pass
extensions - out of 406 unit tests, 5 are failing, these failures are the real deal, they warrant investigation (they might have caught something)

So for the entire BI platform, there are only 5 unit tests which are failing! We're going to watch these projects carefully and keep the unit tests passing (and squash any failures). Over time we'll be adding new tests, and increasing the code coverage.

The assembly has been dramatically cleaned up and simplified. The assembly project does not require the checkout of any other projects, it has all the resources required to lay down the solutions, data, appserver, etc as well as ivy dependencies on package archives of other projects. You can simply checkout the assembly project, run an ant build and a BI-SERVER build will be created.

CI is running jobs for each of the new projects with the new build order in place. These can be seen in the SUGAR grouping:
http://ci.pentaho.com/view/Sugar/

Lastly, I have officially "closed" bi-platform-v2/trunk the new location in SVN for these projects is:
svn://source.pentaho.org/svnroot/pentaho-platform/trunk
The bi-platform-v2/trunk has been renamed as trunk-closed to further discourage any checkins to the wrong location.

Any SUGAR development and 4.1/4.5 fixes should be incorporated in the new project structure (though the project names have remained the same, using the summary I listed above you can easily find where to checkin).