Nuxeo Developers Blog

Nuxeo Runtime 1.0: Extension Points for Java EE and OSGi for JBossAS

We today released (under the EPL and the LGPL) the version 1.0 of Nuxeo Runtime.

Nuxeo Runtime offers a coherent component model for Java applications based on OSGi that makes them runnable on any Java platform with virtually no modifications. Nuxeo Runtime also offers a flexible extension/plugin system for any Java / Java EE application.

We today released (under the EPL and the LGPL) the version 1.0 of Nuxeo Runtime.

The inception

The original idea was born when we were confronted with the problem of deploying several core components of Nuxeo ECM (our ECM platform) to several Java platforms. Our initial goal was to make Nuxeo Core run on JBossAS and Equinox without modification to avoid the burden of maintaining two separate branches of the components.

Working on this issue, we also quickly figured out that nothing like Eclipse extension points was available for Java EE and that this would cause us some troubles since Nuxeo EP needs to be fully extensible, to allow ISV and system integrators to customize and develop new features without doing any code/package change on our certified components. Moreover, we like to think about and design applications as a set of components that extend each other (thanks to the experience of our previous ECM platform).

This approach is a tremendous feature for all business platforms. I believe it’s one of the main reasons of the current Eclipse success.

So we decided to work on a new system that would allow us to deploy our components to any Java platform (Java EE application server and OSGi) without code changes. This new system would also need to provide a flexible extension system allowing component to provide / consume extension points mutually.

We then went to the “Let’s find a name” phase with the usual internal arguments.

Nuxeo Runtime was born…

Requirements

The requirements for Nuxeo Runtime were pretty simple and quickly defined.

1. Deploy POJO components to any Java platform (Java EE application servers, Eclipse, etc.)

2. Offer an extension system usable by any Java component (POJO, EJB, whatever)

3. Minimize the work required to support new Java platforms (we want to support Glassfish very soon, for example)

4. Reuse as much as possible from existing standards

Now, the easy part: “how to implement that?”… :-)

OSGi: the Package Model

Because we were familiar with Eclipse RCP, OSGi quickly came to our minds for the package model. After some analysis, we decided to go with it for several reasons:

1. It is a standard and is gaining momentum in the industry

2. It provides all the features we required (dependencies, versioning, etc.)

3. It is simple enough yet powerful and flexible

4. It is vendor-neutral

Moreover, current activities around OSGi (adoption, extensions, etc.) made us feel confident in its future.

As OSGi is not supported by all Java platforms, we created an adaptation model that allows host adapters to be written. These adapters mimic an OSGi platform using native features of the host platform.
OSGi bundles are, then, seen as native component of the host platform. For example, on JBossAS, your component is seen as a native MBean.
We currently have an adapter for JBossAS, and Eclipse is supported without adapters since it’s an OSGi platform.

Extension System: Everything is a Plugin!

Another very important feature we required was an easy way to make our components pluggable. We wanted to make it easy to write plugins for our components. We like the approach of a set of components extending themselves mutually to form the final application. Furthermore, we strongly believe that easy extensibility is the key factor for a platform’s success.

We started to work on an extension system, inspired by Eclipse extension points and Zope’s component architecture.

So Nuxeo Runtime provides a flexible plugin system based on extension points that allow any component to declare extension points that others can use to extend/configure. Nuxeo Runtime manages the extensions tree and takes care of bindings. Any Java and Java EE component can use this system to become pluggable with almost no change.

The final model is close to OSGi Declarative Services. We plan to fully support this in the next release. We’re also thinking of adding support for Eclipse’s native extension system.

Extensible Java and Java EE applications and Composition

Thanks to Nuxeo Runtime, any Java and Java EE component can offer extension points to become extensible.

This allows an approach based on true composition to build your applications. Take the components you need, let them plug and extend themselves. Then write one (or more) “customization” component and make it bind them all.

I really believe this opens an amazing way to create componentized Java EE applications.

Just forget the pain of specific builds, enjoy composition!

Example: Nuxeo Transformation Service

For a real-life example, let’s take Nuxeo Transforms, our document transformation service for Nuxeo EP.

First, the NXTransform package defines the transformation infrastructure (transformer, transform chain, etc.). It does not implement any real transformation code.

NXTransform, by itself, will never transform your MS-Word document into a nice PDF. Neither will it extract plain text from a PDF. It only defines a couple of Session Beans / Message-Driven Beans that can be called to ask for a transformation, and offers a set of extension points (to plug real transformers and to define transform chains). NXTransform.sar will never change, whatever transformation chain and transformers it needs to offer.

Now, take a look at NXTransformPlugins, the default set of transformers we provide in the platform. You can find in this package the transformers and the transformation code. You can see the JOOConverter transformer as well as the PDFBox transformer. This package just plugs the embedded converters to NXTransform’s extension points to register its transformers.

Want to add transformation capability? Just write a new component to implement the transformation and plug it into the transformation service. Need a new transform chain? Just add a bundle descriptor that will configure the new transform chain.

Have a look here for an Adobe PDFGenerator integration: Nuxeo Adobe PDFGenerator Transformer.

Before runtime, Nuxeo Transforms has no need to know anything about what transformers will be available. You only need to build it once…

To give some metric, the implementation of the transformer “PDF to plain text”, based on PDFBox, took 30 minutes. Tests included…

Wanna Play?

Just head to Nuxeo Runtime Page, download it, read the documentation and start coding! :-)

Currently JBossAS and Eclipse are supported (in fact, it should run natively on any OSGi platform but it’s untested). We would love to give help if somebody volunteers to support more platforms (e.g.: Glassfish, Geronimo, JOnAS, Websphere, Weblogic, other OSGi platforms, etc.).

If you need support or simply want to discuss just join the mailing-list.

One more thing… If you like it don’t forget to send a postcard to Bogdan Stefanescu (c/o Nuxeo, 18 rue Soleilet, 75020 Paris, France) that made it possible! ;-)

Stay Tuned!

(Post originally written by Eric Barroca on the old Nuxeo blogs.)

Nuxeo switches to Java technologies

As you may have already seen on the web, we are announcing a big transition for our ECM platform: we are switching from the Zope application server to the Java platform.

Nuxeo 5.0, successor of CPS, will be entirely based on the Java platform. It benefits from modern java technologies such as Java EE 5, JSF, JBoss SEAM, OSGi, etc. This transition started 8 month ago, when we have begun to integrate Java component into CPS. We, then, evaluated technologies from the java world, figured out that Java 5 was a big improvement, made some tests and research and finally decided to go with it for our next products.

This may be a big surprise for our long-term users and developers, but we believe we have made the right choice. Furthermore, we are not abandoning CPS, which will be supported for at least 3 years. We are taking it to the next level.

The new platform is still under intensive development and you can expect more announcements in a few days...

Nuxeo 5 will be available in 2 editions:

• Nuxeo Enterprise Platform to deploy large scale ECM solutions
• Nuxeo Rich Client Platform to create ECM oriented desktop applications

Nuxeo 5 introduces some innovative approaches and technologies:

• Nuxeo Runtime — Write once, deploy anywhere
  • Platform independent deployment and extension system (inspired by Eclipse’s extension point) that can be use to make any Java 5 / Java EE application easily extensible through plugins.
  • OSGi-based bundle model
  • Deploy to any Java platform through adapters (it currently includes adapters for JBoss and Eclipse)
• Nuxeo Core — “an embeddable enterprise content management core”
  • Full-featured document / content management engine
  • Based on the JCR API for persistence
  • Offers POJO and Java EE API
  • Offers a smart and powerful SQL-like language for querying the repository (Eclipse BIRT data source available)
  • Fully extensible through plugins
  • Deployable on JBoss and Eclipse
• A set of components that forms the ECM platform

The first public and stable release of Nuxeo 5 is due for November 15.

Related reading:

• Nuxeo website
• Nuxeo’s Java Switch FAQ (French version here)
• Nuxeo 5 community portal
• Nuxeo 5 roadmap
• Nuxeo EP 5 features list
• SVN repository

(Post originally written by Eric Barroca on the old Nuxeo blogs.)

New spellcheckers available

The 0.2 version of Occitan (languedocian) has been uploaded. Thanks to Bruno Gallart

A new spellchecker is also available Marathi (India)
This indian language is spoken by around 90 millions of people Wikipedia says

it has been a quite challenging work as from a word list in an encoding i could not read on first load, i end up with 'not-so-bad' solution :)
Thanks to Hunspell, the default engine of OOo 2.0.3, using UTF-8 is possible so the Marathi language became beautifull to me (well, unfortunatelly only as a picture)
Using CTL linguistic options as well as a dedicated font (all is explained in the readme file of the spellchecker), one can see that the spellchecker is working even if there are some missing word.
The next step is creating the affix file and enrich the word list. Some solutions are on the road though ...

Thanks Priti D. Patil and janabhaaratii Project  for giving this word list and releasing the spellchecker ressources under LGPL

This has been possible because Marathi (India) was a locale already defined at the OOo L10N  project level and available in OOo. So also thanks to the L10N project
I really like when energies are merging and i find that someone prepared a work i need as a basis :)

Both spellcheckers are available within DicOOo.
They're actually propagating on mirror so be patient ...
Be sure to read README file for special needed configuration if you're not in India

Other lingucomponent stuff being finalized and will be announced soon, stay tunned ...

(Post originally written by Laurent Godard on the old Nuxeo blogs.)

OOoCon2006, it's over

Now the OpenOffice.org conferences 2006 are closed and the normal life has taken its old rythm now. This article is only about to thank you all for making this year's conferences a big event, quite like a family one.

Being prepared during several month by many persons on both OpenOffice.org and INSA Lyon side, my first thanks are coming to all those who helped us making it possible: Sophie, Marie-Jo, Jean-François and Charles from OpenOffice.org and Yves Condemine, Patrick Pollet, Cédric Grand, Anne Mouriquand from INSA. I am sure to forget many persons here, but I think that they will recognize themselves.

To help us keep the conferences in our mind, the kiberpipa team who did an extraordinary job, provides us the video archives of the conferences and offers to host your photos of the event.

Again, thanks to you all.

(Post originally written by Cedric Bosdonnat on the old Nuxeo blogs.)

OOoWikipedia 2.0.3 is out

Thanks to Andras Timar from fsf.hu, OOoWikipedia handles now magyar language.

OOoWikipedia is an OpenOffice.org extension that allow you by highlighting any word in a text document to popup a browser that connects directly to Wikipedia ressource on it.

(Post originally written by Laurent Godard on the old Nuxeo blogs.)

Switching from Emacs to PyDev...

I gotta admit I was wrong...

I recently tried out Pydev and Pydev extensions on Eclipse 3.2 for my
Python and Zope developments. Wouah !

I've been using these plugins for couple of weeks and I already can't
switch to emacs anymore. I wouldn't have believed It could have ever
happened. I've been using emacs for years and somehow refused to try
out any IDE for Python because I thought it wasn't as crucial for
Python development as for other languages such as Java, C#, C++
etc....

I love this feeling. I mean when you find out a tool and are wondering
how you've been living without it for so long that you can't go back to
the old one :) I'm in this case with emacs. I simply can't
anymore. (Well, I could but you see what I mean)

Pydev really brings a lot.  I was surprised by the progresses made by
Fabio on the Pydev front and especially what Pydev extensions bring
related to code completion.

I let you check out the screencasts to get a quick overview if you
don't have time to install and play with it (or you are not convinced)

For Zope development there are some things I'm missing that require
some command lines beside Pydev. (Or these are maybe some things I
didn't find since I'm relatively new in Pydev development)

•  Support for zope.interface

      This is a bit annoying since pydev doesn't recognize
      zope.interface and thus shows errors on those classes. I might
      even dream about a full integration checking the Python classes
      implementing interfaces such as in Java. And yeah, I'm still
      dreaming about builtin Python interfaces but eh wait ... Python
      guys don't want that...I need to stop dreaming...

• Support for doctests

      Pydev doesn't support doctests. Although, you can run external
      commands from Eclipse. I'm using them to specify a zope.testing
      based tests.py as external command and I get back the result in
      the eclipse console. It would be a plus if it could directly run
      them from the Eclipse as doctests as the other Pyunit tests.

•  Python specific package browser

      Here, I'm especially talking about the refactoring. Move and
      rename you can find in the Java package manager. So that you can
      rename module names and don't worry about changing the references
      in other Python projects in the workspace. Or still move modules
      with the same behavior. It really does ease the refactoring in
      Java.

• Zope server plugin
  
  
• Debugger integrated with Zope
  

To sump up, Pydev and Pydev extensions rock. It's really promising and
it addresses a huge lack related to Python development.

Please don't tell me about other Python specific IDEs since this is
not what integrators are expecting. They already do have Eclipse on
theirs boxes all over the place so they just want a new Eclipse
plugin. (and they are right) Another industry reality. I guess IDE
war is over ... as well.

I guess Éric is going to like this post ;)

(Post originally written by Julien Anguenot on the old Nuxeo blogs.)

Triage of bugs in an open-source world.

The word "triage" in programming has been around for a while, but seem to have gained popularity lately. What it is, is basically a new word for "bugprioritizing", being easier to say and spell. But if we look at what the word comes from, we see that behind this lies a concept that is often forgotten in the usage.

"Triage" comes from french and means sorting, so nothing new there. Howerver, it comes to the programming world from the world of emergency health care, where it is used to allocate health care resources in emergencies, when there are more people needing care than there are health care available. In computers then, it becomes a system of allocating programming time to bugs, when there are not enough programmers to fix all the bugs.

How should this be done? Well, first of all, we of course need to take a look at how serious the bug is. What categories you have depend largely on what bugtracking system you use, and it's also a matter of personal taste. Personally, I would prefer these categories:

• A blocking/critical bug is a bug that means the system or part of the system gets unusable. It has no workarounds, and affects most users of the system.
• A serious/medium bug is a bug that is a big problem for many users and has no workaround, or affects everybody, but has a workaround.
• A minor bug is a bug that affects few users and has a workaround, or has no workaround but only is a problem in very extreme edge usercases.
• A trivial bug is not an actual problem for anybody. Could be spelling errors or ugly design.

Bugs also usually have a priority field. Prioritizing or triaging a bug is usually just setting this field. But triage is not prioritizing, it's resource allocation. And although in medicine, the resources are helath care workers, and the criticality is time, in programming, the resurce is programming time, and the ciriticality is rather the knowledge to fix the really difficult bugs.

That's OK as long as you work in a company, because there you can take the bugs allocated to you, in the order your boss prioritized them. If you get problems, you ask your co-workers. But in the open source world there is bigger differences. Also in the open source world, people assign bugs to themselves, and if you think a bug is over your head, you will simply never try to fix it.

Therefore, the bugs importance should not be the only data you tag the bug with, but also how hard the bug is to fix. Most bugtrackers only have severity and priority. Some, like JIRA, has a field where you can estimate it. Although that's more of a XP project management features than a help in triage, it can be used as such. If you have an hour over to bugfix, there is no point in trying to understand a bug who is estimated to take hours to fix.

But what would be even more helpful in an open source situation would be a difficulty field. The experienced bugfixers can look through the bugs, note severity and difficuly, and then not fix the easy bugs. It's tempting to fix the easy ones because quick fixes are satisfying and you feel productive. But if the wanna-be contributor can fix bugs marked as "easy" and understand and fix them, then we have not only gotten a new contributor, we have saved time for the experts.

(Post originally written by Lennart Regebro on the old Nuxeo blogs.)

OOoCon time !!

OOoCon is approaching !! It will take place this year at Lyon (France) from the 11th to 13th of september

Some are already there as Lyon is a nice city place to visit (Pavel, Stefan, ...). I will personnaly come from Grenoble on sunday evening

A lot of interresting topics will be covered by the conferences on tuesday and wednesday, especialy regarding extensions and OOo scripting :) but also ODF topics as well as promising lingucomponent project spellchecker presentation

On monday many meetings are planned : QA, Extenstions, Marketing, ... a great time to discuss less formally

One more important point, our kiberpipa friends rock and kindelly accepted to reproduce their wonderfull effort from last year. We will have a professional-like media coverage that will cover (Note that all of this is done only with open sources tools):

• live video streaming

• archiving the video on the web
• interviews
• blog planet (send an email to ooocon@kiberpipa.org if you want your blog to be included)
• photo gallery

 
Also thanks to local helpers such as Charlotte, Cédric (obviously ;) ) and Geoffroy (not so local but so efficient)

The media coverage address : http://ooocon.kiberpipa.org (guess what, probably still under construction ;) )

This OOoCon promises to be great event, really !!!

(Post originally written by Laurent Godard on the old Nuxeo blogs.)

Portuguese Thesaurus available in OpenOffice.org 2

Using OpenThesaurus by Daniel Naber, thesaurus for portuguese is now available in OpenOffice.org 2.0 though DicOOo (File > Wizards > Install new dictionaries)

Thanks to Paulo Trezentos and Rui Fernandez from Caixa Magica

(Post originally written by Laurent Godard on the old Nuxeo blogs.)