[Mondrian] Mondrian release schedule (3.1.5, 3.2, and 4.0)

Julian Hyde jhyde at pentaho.com
Fri Jan 8 17:08:55 EST 2010


> Will Gorman wrote:
>
> Before I kick off the Mondrian build I went to test Schema Workbench.
> When loading Foodmart, I get the following exception:
> 
> Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError:
> org/olap4j/Scenario
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> 	at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.
> java:124)
> 	at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> 	at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> 	at mondrian.rolap.RolapCube.<init>(RolapCube.java:246)
> 
> It looks like olap4j is now a direct dependency of Mondrian?  I don't
> think adding new dependencies to Mondrian in a patch release 
> is a great
> idea.  Should we consider rolling this change back out, or rev'ing
> Mondrian to 3.2.0?  
> 
> If the dependency is required, we'll have to modify Mondrian's build
> script to include this jar in the workbench distribution as well as
> updating all the other places where Mondrian is used in the 
> platform and
> client tools.

Oops. I had assumed that olap4j was already a dependency. I guess previously
you'd only try to load olap4j classes if you used one of the olap4j wrappers
(principally MondrianOlap4jConnection).

However, I'd rather not remove the scenario functionality, because I'd like
people (in particular the PAT developers) to be able to use scenarios before
4.0 comes out.

Now would be a good time to discuss the structure of releases between now
and mondrian-4.0. I've changed the subject of the email and Cc:ed the
mondrian list.

Here are the facts:

1. I am developing 4.0 functionality on the main line (//open/mondrian). My
changes (and there are lots of them) are in a sandbox, not checked in, and
not on a branch.

2. The change to add support for scenarios (i.e. writeback) in the 3.1
branch (//open/mondrian-release/3.1) makes mondrian depend on olap4j.jar for
the first time, even if you are using mondrian's legacy API. I'd call that a
minor breaking change.

3. The code on the main line includes scenario support (and therefore
requires olap4j.jar on the class path) and one other minor breaking change:
it includes the ability to have independent members of hierarchies in the
same dimension, which might just possibly break applications that have used
multiple hierarchies.

4. Other developers are putting significant architectural changes into the
main line. I'm thinking in particualr of Matt Campbell et al's work on
NativizeSet. This is great work, and it doesn't break any APIs or
applications, but it's a pain for me to continually merge their changes with
the 4.0 changes I am making in my sandbox.

5. At some point I am going to check my 4.0 changes into the main line. From
that point, mondrian will be unstable for a month or so. (Not all tests will
pass, and there will be significant breaking changes in API and other
behavior that we have not documented yet.)

6. At any time in the future, we may need to make a patch release at short
notice to solve a high-priority problem.

Given these facts, I don't think that we can continue to make
backwards-compatible releases in the 3.1.x series right up until 4.0 is
ready to go production. The differences between the code bases will be so
great that it won't be practical to port bug-fixes between the 3.1 and 4.0
lines. In addition, we need to make it easy for other developers (e.g. Matt
Campbell) to contribute without continually treading on my feet.

I think the solution is to branch the current main line as mondrian-3.2. (It
will become a //open/mondrian-release/3.2 branch in perforce.) We would make
a series of releases mondrian-3.2.x. These would include scenarios,
independent hierarchies, and other recent contributions such as Matt's
nativization improvements.

This would let me develop 4.0 on the main line, and I can integrate changes
over in one shot when 4.0 is close to being released.

We could optionally release mondrian-3.1.5 before then. I'd exxcise the
scenario stuff excised, so that it does not depend on olap4j.jar, but I
would not make any further releases from that code line.

What do you think? I'd also like to hear what other mondrian developers
think too.

Julian




More information about the Mondrian mailing list