Forums

Home » Liferay Portal » English » Liferay Legacy

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Ali S
Liferay vs. eXo?
November 12, 2006 7:56 AM
Answer

Ali S

Rank: Junior Member

Posts: 25

Join Date: August 8, 2005

Recent Posts

Hi

Can some one please tell me what dose liferay has that eXo doesn't?

I mean with respect to me as a developer, technologies and standards that they support.

Thanks in advance
Ali
Jörn Ebeling
RE: Liferay vs. eXo?
October 9, 2006 4:50 AM
Answer

Jörn Ebeling

Rank: Regular Member

Posts: 119

Join Date: January 5, 2006

Recent Posts

I never worked with eXo but mayby this document may help you:
http://epubs.cclrc.ac.uk/bitstream/785/406.pdf

It's not based on the latest version of liferay.
Leonard E. Sitongia
RE: Liferay vs. eXo?
October 10, 2006 7:10 AM
Answer

Leonard E. Sitongia

Rank: Regular Member

Posts: 136

Join Date: September 12, 2006

Recent Posts

First, Liferay has extensive documentation for installing, using and developing. This is vital. I explored eXo in the 1.x release, and found it very interesting, especially the GUI layout management. When they released 2.0, they had unbundled parts of it and there was little documentation on how to install an operational portal with CMS. Since then, someone on the list explained, but there is still little documentation on what it all is and how to use it. In 1.x it was easy, and documented, on how to get to the administration and configure portlets. With 2.x, I could not find that. Things had changed significantly, and there is little to go on. Thus, it is difficult to analyze and compare.
==Leonard
Mika Koivisto
RE: Liferay vs. eXo?
October 15, 2006 4:13 AM
Answer

Mika Koivisto

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1498

Join Date: August 7, 2006

Recent Posts

For me it was more active developer community, better CMS, more impressive UI (that is important for convinsing business people), it's spring based where as eXo uses PicoContainer. The last and possibly most important was Liferay's license.

Where eXo get's my respect is it is highly modular and it's builds are based on maven2.
I really hope that Liferay developers make Liferay more modular and adopt maven2.

What bugged me in eXo was the license, JSF and PicoContainer.
Ali S
RE: Liferay vs. eXo?
November 12, 2006 4:23 AM
Answer

Ali S

Rank: Junior Member

Posts: 25

Join Date: August 8, 2005

Recent Posts

Jörn Ebeling:
I never worked with eXo but mayby this document may help you:
http://epubs.cclrc.ac.uk/bitstream/785/406.pdf

It's not based on the latest version of liferay.


This doc doesn't have deep technical inspection. It's just like doing homework (just fill some paper).
Ali S
RE: Liferay vs. eXo?
November 12, 2006 5:23 AM
Answer

Ali S

Rank: Junior Member

Posts: 25

Join Date: August 8, 2005

Recent Posts

Mika Koivisto:
For me it was more active developer community, better CMS, more impressive UI (that is important for convinsing business people), it's spring based where as eXo uses PicoContainer. The last and possibly most important was Liferay's license.

Where eXo get's my respect is it is highly modular and it's builds are based on maven2.
I really hope that Liferay developers make Liferay more modular and adopt maven2.

What bugged me in eXo was the license, JSF and PicoContainer.


The problem appears when u try to change some thing in or add some thing to Liferay.
I'm agree with u about UI, but have u ever try to change it? Have you try to dev-dep a new portlet that do some thing more than just showing a single jsp/jsf, that is file upload/download, accessing Liferay api, ...?

To access api (it includes user/rules) u need to move the jar files from liferay web-inf to tomcat common/lib, and then u have to do it for your external portlet, and ... .)

About themes: it's not possible to change every thing in gui, just simple ones, and there is no spec to write new one. The gui code is scattered in many places starting form html/ .

And you point to what make eXo interesting for me:
Mika Koivisto:

Where eXo get's my respect is it is highly modular and it's builds are based on maven2.

Almost every thing in Liferay goes into portal-ejb and portal-web, and no way to managing dependencies and jar files.
It's the distribution of Liferay 4.1.2 source files:


and this one after removing laszlo-web, sql, lib and portlets :


Liferay is OS so we should not expect it be or have exactly what we want, but it should be some thing that make it's community able to develop and contribute to it (if and only if they feel they like to have dev community instead of user community).
Ali S
RE: Liferay vs. eXo?
November 13, 2006 1:03 AM
Answer

Ali S

Rank: Junior Member

Posts: 25

Join Date: August 8, 2005

Recent Posts

To be fair I should say build-service/build-db is a lovely feature of Liferay.
Alexander Chow
RE: Liferay vs. eXo?
November 13, 2006 1:23 AM
Answer

Alexander Chow

LIFERAY STAFF

Rank: Liferay Master

Posts: 519

Join Date: July 19, 2005

Recent Posts

The problem appears when u try to change some thing in or add some thing to Liferay.
I'm agree with u about UI, but have u ever try to change it? Have you try to dev-dep a new portlet that do some thing more than just showing a single jsp/jsf, that is file upload/download, accessing Liferay api, ...?

To access api (it includes user/rules) u need to move the jar files from liferay web-inf to tomcat common/lib, and then u have to do it for your external portlet, and ... .)


I don't think you would have much problems if you developed in the /ext environment (unless I misunderstand your question).

Almost every thing in Liferay goes into portal-ejb and portal-web, and no way to managing dependencies and jar files.


You should take a look at the roadmap under "Spurgeon".
Ali S
RE: Liferay vs. eXo?
November 14, 2006 4:24 AM
Answer

Ali S

Rank: Junior Member

Posts: 25

Join Date: August 8, 2005

Recent Posts

I mean:

1. Accessing LR API form hot-deployable portlets without moving many of liferay(ROOT)/WEB-INF/lib/*jar* to say Tomcat common/lib, and as consequence mixing portlet jars and LR jars.


Features & Road Map >> Spurgeon >> Refactor Liferay Services >> Liferay Services Available to Portlet WARs through Liferay Kernel


2. The way that LR generate layout/UI. If some one wants to change ui s/he must read all of below files and related java files in portal-ejb by tracing many js/html/jsp/java/... files, and need to change lots of them to get desired result.


3. Css file in themes. Styles in css files are at least from 4+ category: styles that are 1) defined in jsr168 and/or used in portlets, 2) used in theme files, 3)used in the above files(portal structure), 4)may be used every where, +)unknown.
Again a trace is needed to find out where which one is used.

I think the files in part 2 and 3 should be refactored to provide a consistence way to create and change LR UI. Business logic and view should be decoupled and there should be a way to completely replace view with a new one or use business logic in a different way(e.g. use with web services). (There is a lots of bl in struts actions and jsp files).

4. Every thing is magically mixed up with other thing and the lines between different components are opaque.
Attachments: css_all.jsp.txt (2.5k), css_portal.jsp.txt (1.7k), css_portlet.jsp.txt (3.7k), css_shared.jsp.txt (5.6k), css_theme.jsp.txt (3.8k)
Brian Chan
RE: Liferay vs. eXo?
November 14, 2006 9:05 AM
Answer

Brian Chan

LIFERAY STAFF

Rank: Liferay Master

Posts: 751

Join Date: August 4, 2004

Recent Posts

You can access the liferay internals via portal-client.jar, so you don't have to move everything to the common class lib. Also, for the themes, you actually get a lot more power this way.. you can modify the css's and add any logic you need directly.
Ali S
RE: Liferay vs. eXo?
November 15, 2006 5:20 AM
Answer

Ali S

Rank: Junior Member

Posts: 25

Join Date: August 8, 2005

Recent Posts

You can access the liferay internals via portal-client.jar, so you don't have to move everything to the common class lib.

I hadn't noticed portal-client, probably because it is web service based and/or the source is generated at build time. Although it's probably a working solution I don't think it's good practice to use WSs for communication between two piece of code that run in the same JVM just because they are in two sibling node in class loader tree.
(BTW does it work for ext-ejb?)

Also, for the themes, you actually get a lot more power this way.. you can modify the css's and add any logic you need directly.

Lots of file that are out of themes but still take part to generate UI, limits the power of themes to change existing and create new UI.
(By splitting css file I mean it should be defined that what does every style do and where it is used.)

Also I suggest u to use maven to build and separating different design concerns in different component. Not only it help development/debug but also make it possible to extend LR and adding more feature.
Michael Young
RE: Liferay vs. eXo?
November 15, 2006 9:33 AM
Answer

Michael Young

LIFERAY STAFF

Rank: Liferay Master

Posts: 842

Join Date: August 4, 2004

Recent Posts

Can you elaborate on what maven will bring to the table? Maven has been an internal discussion of ours.

What are its immediate benefits for us?
Mika Koivisto
RE: Liferay vs. eXo?
November 15, 2006 10:49 AM
Answer

Mika Koivisto

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1498

Join Date: August 7, 2006

Recent Posts

Michael Young:
What are its immediate benefits for us?


Dependency management, modularization. Makes continuous integration easier. You really should read Better Builds with Maven. A good project that uses maven 2 is Apache ServiceMix. And what it gives to your user community is ability to build custom portal more easily.
Ali S
RE: Liferay vs. eXo?
November 19, 2006 12:08 AM
Answer

Ali S

Rank: Junior Member

Posts: 25

Join Date: August 8, 2005

Recent Posts

Michael Young:
What are its immediate benefits for us?


You will not need to put every thing in portal-ejb/web! ;)

You can divide your code to different and completely separated but dependent module (component, subproject) and use Maven to automatically build and package them, optionally each module will be installed into Maven repository and this way they may use each other.

You will just need to tell Maven which is which, the relations and the goals, you (we) will get rid of big Ant scripts. Ant to Maven is like Assembly to C.

Also you can exclude the external jars from the source and use Maven repository and dependency manager to download/install/store/manage them.
Ali S
RE: Liferay vs. eXo?
November 19, 2006 5:22 AM
Answer

Ali S

Rank: Junior Member

Posts: 25

Join Date: August 8, 2005

Recent Posts