I also wish they make it a little faster to compile and deploy and debug some time.
it kills during debug.
is there any one here who likes to implement a new portal from scratch?

the new Portlet 2.0 spec is a great opportunity, if any one (personal or company) becomes interested I am also volunteer to start a an open source project for this.

I agree not to re invent the wheel
but portlet 2.0 is the time for every one to reinvent the wheel
and for us Iranian developers to show there are some good developers in Iran too (may be is not!?)
we are not force to do every thing from scratch
we may start with a portlet container then move into a complete portal.
we can use some liferay  and other open source portals code in our own code.

It looks a marvelous idea.

Have you any business model in mind ? It is more that obvious that any ovement would be  just a flame and is sentenced to vanish, if it is not supported by a business model.

Suppose that we implement a state of the art Portal, and be enough rapid to develop a suitable solutions to others, do you think any one in the whole word can trust a product from Iran ?

I think it is better to become officially part of one good starting open source movement and help farsify it.

Unfortunately in the last six month companies are liferaying. I guess there is a misunderstanding about the portal concept in the mangement level that has made all companies to work on portal and this certain portal server.
Well, I see no good structure in Liferay. liferay  is a museum of antipatterns cause it is 7 years old and Chinese haved developed this software without major refactoring. Liferay has started its life 7 years ago with no MVC framework and then they ended up using struts but they are misusing it. The same incident happened for Hibernate and then spring frameworks. My point is :
Not everything that sounds complicated is beautifull and extensible, this software lacks quality.

Portal Server development is not waste of time
If I were to develop a portal server, I'd choose a more modern approach, develop less code(less than 600 spring beans!!!). And I would try to think in an un-chiniese way. It can be wise to choose a good license for an open source portal. If you like JSR-168, be aware that untalented chinese charge their customers more than 70000$ a year for their junk support.

As this topic is hot these days, yesterday I was trying Liferay 4.2.0 and faced with problem in setting up the Chat portlet. It says "This portlet is inactive. " whereas when I check in admin portlet it's active and I have already granted permissions to the test user.


Anyone knows how to configure this portlet from scratch.

A few months ago I wanted to start such a project. I'm busy with other things now. My preliminary conclusions were:

- spend most of time on the poral server part, rather than the portlet container. Stuff such as user management, communities/spaces, security, templates, etc. Liferay has a lot of features  in this regard.
- for the portlet container use pluto or some other container. pluto is good, it's spring based and very clean/unit tested. It doesn't implement portlet2 spec atm though. eXo has an excellent design too.
- portlet2 spec has a huge dependency on WSRP2 spec. It's such a complicated spec. afaik there's no good WSRP2 open source project atm. IBM's open sourced wsrp2j which was donated to apache  is also inactive atm, and is crappy anyways!
- write lots of portlet suites: That's Liferay's selling point too: lots of portlets.

portlet container/wsrp < portlet suites < portal

It's harder than you think :) Especially using portlet2 spec....

There are tens of open source JSR-168 all of them with their own
weakness and feature.
You may take a look at Exo stack if you are going to deploy a high end
portal system. Officially it does not support  rtl-ltr but its easy to
hack it (matter changing few lines).
In case that you are looking for a easy to deploy and easy to manage
portal, then take a look at StringBeans with out of the box Persian and
rtl-ltr switch support. It is not bundled with tens of Portlet and
themes as Liferay does but its worthy of a try.

I think StringBeans will be one of the first portal with an
implementation of JSR-286 portlet container .


You may find exo at:
http://www.exoplatform.com
and StringBeans at :
http://www.nabh.com

Specially about "museum of antipatterns" and
"this software lacks quality", best words to describe Liferay.
Liferay is closed-to-extend and unusable, with bunch unusable and just
few useful portlets and fooling beautiful interface and complexity
that make it hard to find out what it really is.

>Portal Server development is not waste of time
I think there is misunderstanding about my words:
Developing a portal server FROM SCRATCH is as much waste of time as
trying to use and/or extend Liferay (may be I'm not correct because
extending Liferay is almost not possible ;-) and I suggest developing
from a well-structured and extensible open source portal instead. As
other guys have pointed Pluto, eXo and JetSpeed are good points to
start (I don't have any experience with StringBeans.)

Also I'm agree with Arash about business model consideration and
"just a flame and is sentenced to vanish" without it. And I doubt
about i-product market place in Iran, that is, producers' product
quality, consumers' real need and the market place foundation.

>afaik there's no good WSRP2 open source project atm. IBM's open
sourced wsrp2j >which was donated to apache  is also inactive atm, and
is crappy anyways!
It was true about WSRP4J until few weeks ago, but now both producer
and proxy portlet are working with a little configuration and I can't
see y u say it's "crappy".

since number of interested developers has reached the number 5 I will officially start the project this week
are you also interested to join?
there is no need to develop code
you can help by:
1) telling us about what you need
2) giving idea about architecture and design

My personal exprience with open source
portals like eXo, tells me that starting with a
large, heavy and full-of-features projects like
liferay or eXo is not a good idea. If you want
to start a project, start with less and very less
feature projects like pluto or write a new portal
from scratch. This projects need a lot of
changes (may be more than writing anew) to
support RTL, unicode, persian calendar and so
forth. And after all you suddenly hear that the
license holder restricts Iranians to access,
use, modify, or distribute the software, and then
everything's gone! I strongly suggest you to start
a new portal from scratch. If anyone is interested
in this, let the others know.

PM: Bad news for those who use Google's services
and products, these products and services are one-by-one
restrict iranians to use them: Google code, Google Desktop,
picassa and some other services are know forbidden for
Iranians, so please while start using new product or service
read terms very carefully to avoid facing license problems.

Thanks for your comment, too. But I have just summarized other guys comments.

Code development is an art and I try to be an artist. Don't consider
it down ;-) because I'm being paid for. $-)

About architecture, I'm not a Portal Architect although I love to be.
Usually being Portal Architect is more than being Enterprise
Architect. To find the its definition you can refer to Portal
Architect job requirements. It is really what is needed to design a
portal.

Since I'm interested in this field, feel free to contact me about it.
I will help as much as I can. :-)