Amidst all the discussion over Ruby and Python and Rails and Django and JRuby, Nuxeo, the company behind CPS on Zope, is switching to Java, away from Python - specifically, to JBoss AS, Seam, and the OSGi model. Reasons focus mainly on the strength of the Java EE 5 programming model and the maturity of the community. In a lot of ways, this might be a killer application from the tools used in development, as they have a very wide array of technologies in use:

Here is the list of technologies and products we use initially in our new platform. Technologies

• Java EE 5 and OSGi (for POJO components)
• JCR (JSR-170) as the internal repository API
• EJB 3 as server-side only components
• Java Server Faces as the UI and presentation layer
• JMS as messaging protocol
• Java Rules API (JSR-94) for rule engines integration
• XMLSchema as content type/schema definition language
• Portlets (JSR-168) for portal integration
• JCA for data provider integration

Products

• JBoss AS as the target application server
• JBoss Seam as web application framework (and AJAX support framework)
• JBoss jBPM as business process management engine
• JBoss Cache as cache system
• Apache MyFaces as JSF engine
• Apache Lucene as indexing engine
• Apache Jackrabbit as content storage
• PostgreSQL 8 and MySQL 5 as default target RDBMS

Development tools

• Eclipse IDE 3.2 with JBoss IDE plugin
• IntelliJ IDEA and NetBeans as secondary IDEs
• Maven
• JUnit

To me the most interesting part is they want a fat client in Java. I'm not sure if they'll be using Swing or SWT-based implementation, but for them a web app by itself didn't seem to be enough for their customers. Message was edited by: [email protected]

Reasons focus mainly on the strength of the Java EE 5 programming model and the maturity of the community.

Yes, competing platforms are much less mature as well as their communities. We too are now researching what technology platfrom should be our first choice in gradually converting our existing product to be SOA based and more open for integrations. The research is not yet finished, but the maturity of the Java platform and its community is a very, very strong argument.

To me the most interesting part is they want a fat client in Java. I'm not sure if they'll be using Swing or SWT-based implementation, but for them a web app by itself didn't seem to be enough for their customers.

Good windowing desktop app instead of AJAX/DHTML crap, why not? With the maturity of JavaWebStart and inclusion of very good SOAP stack in JavaSE 6 (we evaluated XFire, Axis 2 but JAX WS 2 currenlty leads in performance, stability, conformance...), it's even more right choice. And in the case you want binary protocol, there is a plenty of choice.

I suppose it´s easier to go to most of enterprises with Java products than with Zope. It´s a open source software, so the platform it is quite important when an enterprise has to choose the right software. It´s supposed they will choose a platform they know. I think Java is the best option for then. But the main problem is to write it all from scratch. Good luck! Joserra Nuevos Modelos de Negocio basados en SW. libre

Umm... So, are they pulling a Netscape here? I mean, there's no mention about the actual product performance and such. Why not fix what they have rather than rewrite it from scratch? I'm all for Java and all. Rah-Rah etc., but seems like abandoning a large code base and doing a complete platform switch, particularly in the saturated CMS market, doesn't seem really practical to me.

It looks like they ran into some limitations in attempting to use ZODB? They're now using Jackrabbit as the store in the CPS 4, inside of Zope somehow. CPS 4 seems to be a combination of Zope technology and Java (Lucene, Jackrabbit). I'm curious as to why they didn't use a Java frontend and keep the Zope stack on the backend. Maybe there were changes to Zope that were requested that weren't happening quickly enough? Who knows. I'm not affiliated with Zope or CPS or their respective companies. We do use Zope (as well as Java) where I work, so I thought it was interesting.

Hi, Detailed reasons of the switch are explained here: Nuxeo's JavaSwitch FAQ. CPS4 is the transition where we plugged Lucene as index engine (instead of ZCatalog) and Jackrabbit as storage engine (writing a low-level adapter for the ZODB Storage to keep ZODB persistence mechanism). Limitations and requirements were in favor of a full switch that we begun 8 month ago (february) mainly because of attraction of the Java EE 5 development models and because of a clean architecture.

It looks like it will be SWT since they are using the Eclipse RCP. Joshua

The rich client platform is based on Eclipse RCP so we'll use SWT. In fact, core component of the platform are runnable unmodified on both JBossAS and EclipseRCP thanks to Nuxeo Runtime which will be released tomorrow (2006-09-26).

The rich client platform is based on Eclipse RCP so we'll use SWT.

Too bad. Swing is faster than SWT on OSX and Linux not to mention that it works uniformly on all supported platforms. Some time ago I simply could not install Eclipse on 64-bit Linux thanks to SWT part. Why you did not create Swing based plugin for Eclipse so it could eventually be ported to NetBeans and IDEA?

In fact, core plugins (Nuxeo Core, the document repository) is not binded to any UI. We could virtually deploys RCP components on anything if an adapter for Nuxeo Runtime is available or if the platform is OSGi compliant (which is not the case for Netbeans and IDEA :-). Maybe we'll investigate to use < href="SWTSwing" rel="nofollow">http://swtswing.sourceforge.net/main/index.html">SWTSwing. By the way, I didn't know that IDEA is offering a rich client platform.

Please stop spreading FUD. Netbeans sucks on Linux. Swing sucks on Linux. My eyes hurt every time I open Netbeans in Gnome ... there is no system LAF, there is no system integration, the latency when clicking on things is awfull. SWT and Eclipse are way better on both Linux and Windows. Maybe the situation will improve with Java SE 6 ... but I am tired of waiting. SWT is here, and it works properly. I wish Java-heads would just stop waisting time with these stupid purity wars and concentrate on quality.

Netbeans sucks on Linux. Swing sucks on Linux.
My eyes hurt every time I open Netbeans in Gnome ... there is no system LAF, there is no system integration, the latency when clicking on things is awfull.

1. Please do not mistake NetBeans for Swing. IntelliJ-IDEA is pure Swing and it is faster than Eclipse everywhere. (And infinitely more usable IMO) 2. Application does not have to have system LnF in order to be successful and widely used: WinAmp is one example. And no popular web site/application conform to a System LnF 3. It is not about 'pure' Java, it as about pragmatism: there is less to maintain and less room for misbehavior. 4. There is more FUD about Swing these days, most or all the shortcomings of Swing which gave birth to SWT are not valid. 5. "SWT is here and works properly" - It is a joke, right?

Here is the list of technologies and products we use initially in our new platform.

For the most part, you just described JBoss Portal. ;-) STAY METAL! Roy Russo

Well, the feature-scope nor the approach are not really the same. :-) See: http://en.wikipedia.org/wiki/ECM

Well, the feature-scope nor the approach are not really the same. :-)
See: http://en.wikipedia.org/wiki/ECM

I agree, until nuxeo says: "Portlets (JSR-168) for portal integration" So is it an ECM? A portal? A bag of spinach with ecoli? STAY METAL! Roy Russo

Hi Roy, Maybe we just misunderstood on this point. We are providing JSR-168 compliant portlets for portal integration. There is no intention to write a portal engine. Those portlets are aimed at providing an easy way to access/display information from the ECM platform to the portal (managing content aggregation form organization's applications). And we are using JBoss Portal as our main target portal engine.

And we are using JBoss Portal as our main target portal engine.

Ah, ok. Please keep the portal team informed of your progress in this area. We're always looking for ECM's that our customers can leverage, and additional portlet providers to show our community on portletswap.com. Good luck to you, on your upcoming release! STAY METAL! Roy Russo

I use Zope and Plone to host 2 on-line community sites. The software is stable and very high quality. Developing new functions for these platforms has always been kind of daunting to me. I still don't understand the relationship between Nuxio and Zope? And for that matter what will happen to Plone with the CPS change in Zope? Also, Zope is a killer app for Python. What does this bode for the Python community? -Frank Cohen http://www.xquerynow.com http://www.pushtotest.com

Hello Frank, CPS is (was) a competing product to Plone, in that it also offered advanced CMS capabilities on top of Zope. I guess the Nuxeo move will not change the way Plone takes. Maybe someone will even pick up the CPS code base. Of course that is all Python (you know, the language that makes indentation significant) stuff, and doesnt really belong here.. Yes, Plone can be very useful and productive to quickly setup community-oriented sites. Christian

Nope, CPS was (and Nuxeo 5 is) not competing with Plone, it was competing with Documentum and eRoom. Regards. S.

Hi Frank, the name is "Nuxeo" BTW. Zope used to be the killer app for Python when we started our company (around 2000). Now things have changed a lot, new frameworks have appeared (Django and Turbogears, among others) in the last year and 1/2. Nuxeo used to be a major contributor to the Zope and CMF framework, on which Plone is based. We obviously won't have time to contribute as much as we did previously. But what we did contribute to the Python/Zope world, we intend to contribute now to the open source Java ecosystem, including "Nuxeo Runtime", an innovative, OSGi-based, component deployment and extension system that we intend to release in 1.0 form RSN. S.

Very interesting ! Very good for Java !! The CMS world has been dominated by PHP and ASP.NET so far - it would be great to see some competition from Java in that area.