#nuxeo

[eunomundo]

#reykjavik #Nuxeo #nuxeokickoff18 #bw (em Iceland Reykjavik)

[eunomundo]

#Nuxeo #reykjavik #nuxeokickoff18 👌 (em Iceland Reykjavik)

[eunomundo]

Do something for the first time, everytime you can 😊 #3Dprinting #NUXEO #Xpower (em Lisbon, Portugal)

[eunomundo]

When a digital company gives you paper cards, they must be somehow special #NUXEO #passmeon #MOO #100%recycledcotton #0%tree #everythingisexperience (em Lisbon District)

[dmetzler-blog]

Fighting with all those Rhino forks

Today i tried to run a webdriver HtmlUnit test on a simple Nuxeo project that makes use of nuxeo-theme-html. I did not think it would be so hard. The problem is all about the Rhino javascript library that people loves to fork....

First one : WebDriver, Marc Guillemot explains here that for htmlUnit project they had to fork Rhino and make the HtmlUnit-core-js.

Second One : DojoToolkit, they made a javascript compressor (ShrinkSafe)  that depdends on a custom rhino and that is use by nuxeo-theme-html to serve JS resources.

The problem is that they share the same package namespace and don't work together.... So I in order to make Nuxeo-theme-html work, i have to  deactivate JS in WebDriver. But if I do that, my JS resources are useless in a test environment : the snakes bites himself. 

There are two solutions for now :

- Find a JS minifier library that doesn't make use Rhino (even YUI Compressor uses it.... :-( ) and convince Nuxeo-theme-html developper to use it...

- Run my WebDriver tests with another driver (as the FF one).

If someone has other ideas....

[dmetzler-blog]

Nuxeo & OpenSocial : a few teasing is good....

Well, it makes now one year that i work on the integration of Nuxeo, Opensocial (Shindig) and WebEngine. We are about to finish a WebEngine application that will act as an iGoogle container. But as it is not yet ended, I took some time time to integrate our GWT container in the JSF application of Nuxeo.

Surprisingly, it doesn't took very much time and I think the result is good enough to show some part of it, cause we are quite proud of it ! So here is a simple screencast of what it is about :

  I hope to be able to commit our changes to nuxeo HG repository ASAP, but i have to build a distribution project so that everyone can build it (there are some needed changes in the lib versions of the Nuxeo original packaging), so stay tuned !

[dmetzler-blog]

Playing with jUnit4.5, Guice and Nuxeo

In order to help our developpers to setup integrations test on our Nuxeo platform, i played with JUnit 4.5 and Guice. The goals were :

Don't have to build huge @BeforeClass method

Convention over configuration

Common services (Repository, CoreSession) easy usable

Reusability

Be able to run test on several repo types sequentially

Be able to deploy its own bundle

We already used Guice to make injection of some components in our test suite, and I decided to generalize this approach by binding core Nuxeo components to Guice providers. 

Here is the result as a simple test :

package com.leroymerlin.corp.fr.nuxeo.portal.testing;

@RunWith(NuxeoRunner.class) @Session(user="Administrator") @Repository(RepoType.H2 ) @RepositoryFactory(SimpleTestRepoFactory.class) public class InjectSessionTest {     @Inject     public CoreSession session;     @Test     public void theSessionIsUsable() throws Exception {         assertNotNull(session);         assertNotNull(session.getDocument(new PathRef("/test")));     }     @Test     public void sessionPrincipalIsAdministrator() throws Exception {         assertEquals("Administrator", session.getPrincipal().getName());     } }

I built a NuxeoRunner class that knows how to interpret the test class annotations

@Session to configure with which user we want to connect the session

@Repository to configure the repository type (can be either JCR, H2 or Postgres)

@RepositoryFactory : to give the developper the ability to feed the repository before the test runs (the SimpleTestRepoFactory.class just creates a /test workspace document)

Thanks to Guice, we are now able to inject a CoreSession ready to work. Of course, you can just use the @RunWith method, there are default values for all the annotations. For instance :

@RunWith(NuxeoRunner.class) public class UserManagerHarnessTest {     @Inject     private UserManager service;     @Test     public void serviceIsInjected() throws Exception {         assertNotNull(service);     }     @Test     public void canRetrieveTheAdminAccount() throws Exception {         DocumentModel admin = service.getUserModel("Administrator");         assertNotNull(admin);     } }

We also built another runner that can run NuxerRunner tests sequentially on different repository types :

@RunWith(MultiRepoNuxeoRunner.class) @SuiteClasses ( {SimpleSessionIT.class } ) @Repos({RepoType.H2,RepoType.JCR, RepoType.POSTGRES}) public class NuxeoSuiteTest { }

This test suite execute the SimpleSessionIT test sequentially on the three repository type implementations.

What needs to be done next  would be :

the ability to deploy bundles and contribs with annotations of factories

include as much Nuxeo Services bindings as we need in our Modules. 

Find a way to reintialize repo either at method or type level. 

BTW I know that Ian Smith from Nuxeo is building a Nuxeo abstraction layer that also uses Guice to retrieve services, it's called Seattle (available in the nuxeo SVN sandbox). Our approaches are not the same (his code is better than mine ;-) ) but there are a few things common. 

The conclusion, is that jUnit offers us a cool way to build our own runners on POJO classes. Guice enables us to hide all the internal mechanism of Nuxeo services and statically code dependencies between nuxeo services. This way developpers focus on their tests and don't suffer of the time they need for their setup methods. The cons of this is that we must be very careful with the @BeforeClass and @AfterClass annotation since the injection mecanism does occur only on the class creation. 

This code will be soon available on http://hg.nuxeo.org/opensocial/ (nuxeo-test-util project)

[dmetzler-blog]

OpenSource @ Work : opensocial integration in Nuxeo

When I saw that my blog was mentionned in the What's New release note of Nuxeo 5.3, I thought about writing something newer thant September 9th... So, this is it, when the RC1 was announced, Erid said : "OpenSource @ Work" about the opensocial integration in Nuxeo. So this post will be all about our collaboration with them and how all this took place. 

First of all, this has not been very easy... Since OpenSource software is often a meritocraty, we had to proove our merit on what we were doing. It all began in July 2008 when we choosed the Nuxeo platform to hold our iGoogle like intranet. In August, we were able to make a tiny demo, integrating WebEngine (first version a that time) with Shindig. We were able to add gadget and drag'n'drop them on collaborative space. I made a small screencast and sent it to Eric. He anwsered : we should find some ways to work together.

I was then invited to make a talk on WebEngine in september : video can be found here (sorry first the moves, this was my very first talk...). After this talk I met Thierry Delprat (CTO) and Florent Guillaume (Head of R&D) to show them what we built. First problem for us, we were using the first version of WebEngine that didn't include the JAX-RS API yet. Then the product was not integrated into DM and was only a WebEngine app. At that time, Nuxeo had lots of work on the 5.2 branch and did not have sufficient time to work on OpenSocial.

After that, I came back to my office and continued our work on the portal... still with WebEngine v1 (this has been a real pain). At Nuxeo Developper Day, in december 2008, i made another talk (video here) with a better demo. The day after, we worked with Jean-Marc Orliaguet (Nuxeo Theme Developper) about the different approaches we had :

For Jean Marc : a Gadget is a piece of interface (a fragment) that can be stateful

For me : a Gadget is a Document inside a collaborative space (I will surely write a post about all the possibilty of this model)

The two approaches are complementary since, the first one is from a UI point of view : i want to decorate the page with gadgets and the second one is from a collaborative view : users can share gadgets as other documents. I think that at some point we will find how to yield those different approaches.

In February 2009, Eric Barocca came to us to see we exactly what we were doing, and what were our plans. After that, Nuxeo created a Nuxeo-dev mailing list that we could use to ask questions. Leroy Merlin was then designated as a possible future contributor.

After that, Nuxeo created for us an Opensocial Mercurial repository so that we could commit our dev and that Nuxeo could study our code. We really began commiting in May 2009. At this period, we were completely refactoring the platform : use of GWT-ext for the D'n'Drop interface, use of WebEngine JAX-RS (at last !), real integration of Shindig as a Nuxeo Runtime Service. As a result of that, I've been able to integrate the GWT container into the JSF Nuxeo-DM interface and made a small screencast of a collaborative space into Nuxeo-DM giving the ability to put as many dashboards you want in all workspaces.

Shortly after that, Ian Smith began to work on our code. He and Thierry Delprat came to us to understand what were our plans and how it could be integrated in the future 5.3 release. Then the OpenSocial repository has been merged with the nuxeo-features one, well integrated and used to replace the old JSF based dashboard. In mid-october, the RC1 came out, and now the GA.

The main problem for working together is that the release timelines are not aligned. When Nuxeo freezes some code, we want to add some functions. Mercurial hels us a lot but it's not easy. I think that for resolving this, we'll had to learn how to work together with time and perhaps share some realease dates.

From the licensing point of view, Nuxeo and Leroy Merlin are both owner of the contributed code that is LGPL licensed.

As a conclusion, it's not very easy to join such a big project but all the team is very proud of it. I'm sure there will be real benefits from that :

Our code is reviewed by Nuxeo Architects and well integrated in the core distribution.

We had to make the generic code generic, and make the specific parts plugin of it.  I really think its a proof a quality and that i made us ask for the good questions.

Apart from making the code generic, it did cost us nothing

I think that the value of a portal is the number of app you can integrate into it. Theorically we have all iGoogle gadgets that are integrable (and it make a lot ;-) ). I other people contribute by making "Enterprise ready gadgets" on top of the Nuxeo Platform, we will gain benefit from it (if you want some ideas, call me ;-) )

As funny as it could be, as we have a Nuxeo Connect Support, we could post JIRA tickets about our own bugs (really funny :-p)

Dicussing with other IT friends, they said : "I'm not sure my company would agree to contribute to OpenSource software !".

We did it so :"Yes we can !", "Yes YOU can !"

FYI a gadget can be as small as a hundred lines of JS code (postit gadget)