[Mondrian] xmla over olap4j server

Michele Rossi michele.rossi at gmail.com
Fri Mar 11 15:55:02 EST 2011


Hi Julian,
regarding the new xmla server project - I have only ever created web-apps
(.WAR) using  eclipse-level projects mirroring the folder
structure dictated by the servlet specification.

So you have a WEB-INF folder with a web.xml etc.

With such a layout Maven can create a WAR very easily.

I am sure that with Ant you can do all sorts of things, including creating
that structure dynamically with a bit of build.xml tricks.
However  I am not sure about the best patterns to follow if we go down that
road.
The end product is a standard WAR file that you can run in any servlet
container and point to any olap4j driver right?


Patch files: sure, I assume it's something that the Perforce client can do
basing them on a changelist?
I will look into it.

Use of Maven: building a convincing case will take me a while and I am not
sure a long email is the best way to share my points.

I recently gave a presentation at work about it and people were quite
convinced afterwards.

Let's just say that if you adopt Maven you get all sorts of good things for
free including
-full eclipse integration

-automatic project-site generation with a variety of code quality reports
(test coverage is the one that impressed my boss most),

-integration with Sonar  (another advanced code quality analysis tool)

-integration with TeamCity (automatic builds and test execution)

-entirely declarative build files ("pom.xml") with no strange tricks - much
easier to mantain than ANT scripts (it's a personal opinion of course but I
think those build.xml files are evil - they seem easy to write and later you
find them totally impossible to maintain / debug)


Michele

On 11 March 2011 18:56, Julian Hyde <jhyde at pentaho.com> wrote:

>
>
>  ------------------------------
> *From:* Michele Rossi [mailto:michele.rossi at gmail.com]
> *Sent:* Friday, March 11, 2011 1:43 AM
> *To:* mondrian at pentaho.org; jhyde at pentaho.com
> *Subject:* Re: [Mondrian] xmla over olap4j server
>
> [re-sending from my private email address as it's not working from my work
> address]
>
>
>> Julian,
>> I have a few questions for you:
>>
>> 1. How do I get started?
>> Can you create an account on perforce for me with write permissions?
>>
> Please submit your changes as patches attached to jira cases. We don't give
> people committer privileges until they have made a few successful
> contributions.
>
>   2. Olap4j drillthrough
>> The mondrian olap4j driver implements drillthrough via the "executeQuery"
>> method which returns a java.sql.ResultSet right?
>> Can we not leverage that method to implement drillthrough on the xmla
>> server?
>>
> Possibly. Depends on your requirements. Mondrian's XMLA clients expect more
> in the XMLA response than is currently available in the ResultSet returned
> by that method. Therefore the XMLA server calls a method in XmlaExtra. The
> default implementation of XmlaExtra calls executeQuery. Same effect, longer
> route.
>
>
>>
>
>> 3. The new project:
>> We will need a new "olap4j xmla server" project with its separate build an
>> dependencies.
>> Can you think of a good name for it?
>> Perhaps Olap4jXmlaServer could be a good candidate :)
>>
> Sounds reasonable.
>
>  4. How to build the new project:
>> I know that mondrian is built using Ant.
>>
>> Have you ever thought about starting to use Maven?
>> I've used Maven successfully for years and I've totally forgot how to use
>> ant.
>>
>> I think it would also be beneficial in terms of linking olap4j releases
>> with server releases.
>> We could then distribute both olap4j, mondrian and the xmla server on
>> public maven repositories.
>>
> At this point I don't want to create a new project. I would like to work
> with the xmla server code in situ in the mondrian code base, to learn what
> the necessary changes are, and where would be the appropriate cut points.
> Then I will help you factor it into another project. But first, let's get it
> working in situ.
>
> Re. maven, see below.
>
>
>> 5. Proposed solution
>> I can put together a webapp project quickly using the following
>> ingredients
>>
>> a. maven build
>>
>> b. unit tests based on mondrian:
>> You create an in-process mondrian instance and connect to it using the
>> mondrian olap4j driver.
>> Then you hit the new server using the olap4j xmla driver.
>> You can then compare results making assertions on the equality of metadata
>> and values.
>>
>> c. The output artifact would a standard .WAR file
>>
>> d. Jetty launcher
>> I propose the creation of a jetty launcher too.
>> I can create such launcher using maven reasonably quickly.
>> The result would be a tar.gz file with a number of sub-folders, one of
>> them containing the .war file discussed above, others containing shared
>> jetty libraries and finally the .bat and .sh launchers.
>>
>> We could then have a "cfg" folder with a template .properties file where a
>> user would have to put the details of his/her favourite olap4j driver and
>> the connection details.
>>
> All of the above sounds fine. In due course. But please, don't make big
> changes as the first step. (I've found that the most successful committers
> are the ones who submit small patches at first.)
>
> In this case, the patches would be whatever hacks to mondrian's xmla server
> are necessary to build your flavor of the server. I will learn a lot from
> those patches.
>
> When time comes to create the new project, we can discuss using maven.
> You'd have to make a strong case, because it would be a Pentaho project
> (containing about 15k of mondrian source code, plus unit tests) and Pentaho
> projects have standardized on using an ant+ivy+subfloor infrastructure.
>
> Julian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20110311/a521d3fd/attachment.html 


More information about the Mondrian mailing list