RE: 10 ways to fail as a Liferay plugin developer

2013-03-26T13:47:18Z

Ching Ice-creaming:

David H Nebinger:
Personally I advocate using Vaadin instead of jsp/struts

Practically Liferay is depending on jsp/struts instead of Vaadin.

I surely know what Liferay portlets are based on, but that is beside the point.

Liferay has different requirements than most other developers, so they take the road that meets their requirements, and that means jsp/struts.

I have different requirements:
1. Short dev cycles, releases in days or weeks, not months or years.
2. Team of java devs, not js/ajax experts, but projects require responsiveness of a full Ajax solution.

For these reasons vaadin is the best choice for my team.

I would never base my tool choice on what Liferay uses. Just because they use a push mower to cut their lawn, I will still keep my riding lawn mower to cut mine.

RE: 10 ways to fail as a Liferay plugin developer

2013-03-25T23:06:16Z

It is a safe bet that I don't put all my chips on one portal.

We're not either. We have a good relationship with Redhat with our president has given talk at their conference. In fact, we just installed their portal at one site. One of our member is now working at Redhat Japan too. :-)

We also have several sites with Alfresco up and running and we're doing pretty well with them too.

I'm trying to create an open source market in Japan so I'm really trying to get ALL open source projects successful and not just one.

Well, not just open source really. We handle several commercial portals and cms' too.

All in all, I have to say following JSR286 doesn't make too much sense because most portals don't support it and when they do, each portal have their additional "extras" to make it meaningless to just stick with the specification.

Similarly I am a gambler at Macau casinos

Well, I really don't gamble. I take "little" risk as I can. :-)

RE: 10 ways to fail as a Liferay plugin developer

2013-03-25T14:33:52Z

David H Nebinger:

Personally I advocate using Vaadin instead of jsp/struts

Practically Liferay is depending on jsp/struts instead of Vaadin.
See Liferay source: https://github.com/liferay/liferay-portal/blob/master/portal-web/docroot/WEB-INF/struts-config.xml

At my first message to Florencia Gadea here, I suggested plugin developers starting from making independent portlets.

Ching:

Struts2 portlet plugin follows JSR286 standard, if you follows its examples, you can make one portlet to run Liferay, eXo, GateIn, Jetspeed, Pluto, uPortal.
With the basic knowledge of struts2 portlet, you will have more confidence of developing more advanced Liferay or other portals.

David H Nebinger, please do not take my above feedback as troll or flame bait. I feel that developers and end users should have their freedoms of choices.

Hitoshi Ozawa:

I've already invested too much time on liferay that I can't have liferay fail.

Hi, Hitoshi Ozawa,
Similarly I am a gambler at Macau casinos but I am different from you. It is a safe bet that I don't put all my chips on one portal.

Hi, Jelmer Kuperus,
Karōshi is also suitable for Hong Kongers and Taiwanese:

Hi, Jack Bakker,
Me too, I enjoy sun of a beach.

RE: 10 ways to fail as a Liferay plugin developer

2013-03-24T21:45:59Z

Liferay basically doesn't give a damn about being backwards compatible

I think this is only partially true. The framework doesn't change too much and doesn't contain too many bugs. It's the portlets that's the main problem with compatibility and quality in liferay. Delete the ones you really don't need and modify the ones you want to keep to your requirement and you'll have a stable system.

RE: 10 ways to fail as a Liferay plugin developer

2013-03-24T21:34:02Z

I used to life in Azabu which is like Hollywood and Washington DC wrapped into one. Former president Bush came to a The Iikura Guest House, which is just few blocks from where I lived, when he came to Japan to talk with the former prime minister of Japan. I used to jog around the Imperial Palace every morning before going to work.
It used to be nice and quiet but unfortunately, it began to become crowded with people when public transportation became better when they built Roppongi Hills (http://en.wikipedia.org/wiki/Roppongi_Hills). So I just decided to rent out my condo room and moved to Kamakura.

We have beaches in Kamakura (http://www.japan-guide.com/e/e3109.html) and Great Buddha too (http://www.japan-guide.com/e/e2166.html).
President Obama came here when he visited Japan and this is where he ate the macha (green tea) ice cream which he associates often with Japan.

The person who built my house used to be a real tea ceremony teacher so I actually have a real tea room in my house; unfortunately, I don't practice tea ceremony so I'm just using as a storage.

You can sit on a beach or go hiking for couple of days but I'm really sure that you'll get tired out with boredom.

BTW, I created a Facebook account last week. If interested, please look me up. I'm having trouble finding all the people.

FYI,

Well you're from the country that invented Karōshi (過労死)

I think there's actually more death from suicide than from karoshi in Japan. People nowadays don't commit "harakiri" for failure, but there sure are many trains stopping because of "human accidents" here. Japan don't have a caste system as is in India but there's a hierarchical system and people have to know your own position and the position of other people. The practice of "一見さんお断り" which means "first time visitors are unwelcomed" ("people without introduction from a person who is already within the group are unwelcomed") is common too to keep out people who are not socially acceptable to the group.

RE: 10 ways to fail as a Liferay plugin developer

2013-03-24T17:15:07Z

I disagree that sticking to the spec is a surefire way to fail and with some of the reasons people have brought up against it.

You can extract away many of the liferay specific details behind a set of interfaces. For instance you might have a UserService interface that manages users, Then have a Liferay, JetSpeed and jboss implementation.

If you need things like sharing code between different portlet wars then nothing is stopping you from exposing your services as rest / soap / rmi / thrift etc services

If you want your portlet to be porttable across different containers you can get a long way without having to reinvent the wheel.

Your code will also be much easier to test. Liferay was not designed with testability in mind (at all!) which makes it very difficult to deliver high quality solutions based on it. And you no longer have to worry about upgrading to a new version of liferay, because the jsr standards are stable whereas Liferay basically doesn't give a damn about being backwards compatible

Sure there are trade off's and there is no right solution for every project type. But sticking with just jsr286 might be a more than ok solution in many cases imho!

RE: 10 ways to fail as a Liferay plugin developer

2013-03-24T16:53:47Z

Well you're from the country that invented Karōshi (過労死)

I'll take that beach side property thank you

RE: 10 ways to fail as a Liferay plugin developer

2013-03-24T01:49:15Z

Jack, good point!

When we evaluate something and we only outline a good points, people aren't going to take it. Even in the Gartner reports, there's a strong point and weak points.

There, also, has to be some conflicts sometime to spice up the forum once in a while to make things interesting. It's especially true in something like these forum when most of the questions begins to get repetitious and people begins to lose interest. There's some social difference and there's also a problem with IT people taking everything too seriously - nobody is going to stop using liferay because someone posted something on this thread.

We need more people talking about "liferay" - it's not sufficient to have limited liferay.com employees sending several messages now and then. As the saying goes, "It better to be hated than to be forgottten".

I've already invested too much time on liferay that I can't have liferay fail.

RE: 10 ways to fail as a Liferay plugin developer

2013-03-23T21:01:20Z

there some community 'rap' threads like this one and a previously notable to me 'liferay sucks' that to me has created some interesting 'open' dialogue, more wrt to focus on people

there is a seemingly successful LMS I researched recently where in blog they adverstised something like : jerks don't stay here long ; I like that ; my point is +1 to smart/openHonest

RE: 10 ways to fail as a Liferay plugin developer

2013-03-23T01:50:15Z

Uhmmm.. I like Struts2 a lot ; but also MVCPortlet and Vaadin... and also having developers with the right expertise ; and I like the beach because my kids do.

Enjoy and thanks all. Good night.

RE: 10 ways to fail as a Liferay plugin developer

2013-03-23T00:18:16Z

Actually I am retired and I become retarded,

Well, almost the same here. Enjoying my third business life now. It's not in my habit to just sit in my home or at a beach. That's actually more stressful for me - tried it and didn't work out. I tell people that they should plan their life so they can retire by the time they reach 40 if they desire to. :-)

Take risk, work hard, don't follow other people's tracks. Thank God for giving opportunities and people around you for helping to realize on that opportunity.

RE: 10 ways to fail as a Liferay plugin developer

2013-03-23T00:02:55Z

each portal has their own extensions to access environment-specific stuff.

Agree with David on this. Also, think about the "why" you'll want to make it just stick to the standard. I think it's because to lower cost to move to a different environment. However, the cost to create a portlet is very low nowadays that it actually costs more to write a JSR286 alone portlet. Calculate the cost of making a portlet and projected sales. If you are going to write a simple portlet to sell as a hobby at Marketplace, you may not be able to charge for support so that may actually eat up for your time too.

I like to calculate software in terms of time instead of something like license fee and subscription fee. By time, I mean the time it takes to develop and to maintain/support it. For example, it you're able to sell a software for $100, it seems that you've done really well. However, it you think in terms of time, if it is possible to spend the time to develop the software in something else that can result to sell of $150, you've really lost a $50.

RE: 10 ways to fail as a Liferay plugin developer

2013-03-22T19:23:04Z

Ching Ice-creaming:

Actually I am promoting Apache Struts programming to all plugin developers because eveyone can write one single struts2 portlet running on different portals. Inventing one wheel to fit all Liferay, eXo, uPortal, Jetspeed, GateIn, blah, blah, blah, blah.... ... to fight GateIn lock-in, Jetspeed lock-in, uPortal lock-in, eXo lock-in... and ??????? lock-in

Again, this is not very practical. As I said before, each portal has their own extensions to access environment-specific stuff. Want to get at the user portrait for example? All of the jsp/struts stuff in the world is not going to get you there, you have to invoke portal-specific extensions to access the data. How about showing some web content from the CMS? Again, the same thing. JSR-286 is not the be-all and end-all, it's just a foundation to build from. To get your portlets really snappy, you're going to add JS/AJAX, hooks into the portal environments, theming considerations, etc.

Personally I advocate using Vaadin instead of jsp/struts. While you're trying to get all of your javascript, AJAX, dom synchronization stuff working, I've finished my snazzy Vaadin portlet and have gone home for the day...

RE: 10 ways to fail as a Liferay plugin developer

2013-03-22T15:22:05Z

To Hitoshi Ozawa

1. I have read your story http://www.liferay.com/community/forums/-/message_boards/message/22851073
2. I do not disuss your five questions at public forum here. Some business tricks is mysterious. I have your email and I tell you privately.

I recommend this blog http://www.liferay.com/web/paul.hinz/blog/-/blogs/open-source%3A-the-future-or-a-trend- There is many wisdom of words inside, for examples:
"Vendors also design aggressively to lock customers onto their platform to ensure long term support revenue and to ensure a foothold for other product sales. "
"Instead major vendors have looked to add features that either lock customers into their platforms or push product-chaining strategies."
"Open source must also support industry, defacto standards and simplify integration/interoperability or again they will not grow in popularity. This allows customers a broader capability to fight vendor lock in. "

HItsohi Ozawa,
As above blog saying: "This allows customers a broader capability to fight vendor lock in"
Actually I am promoting Apache Struts programming to all plugin developers because eveyone can write one single struts2 portlet running on different portals. Inventing one wheel to fit all Liferay, eXo, uPortal, Jetspeed, GateIn, blah, blah, blah, blah.... ... to fight GateIn lock-in, Jetspeed lock-in, uPortal lock-in, eXo lock-in... and ??????? lock-in

Actually I am retired and I become retarded, Please give me time to write an email about your five questions

Ching

RE: 10 ways to fail as a Liferay plugin developer

2013-03-21T09:21:53Z

Hi Ching,

Can read the following thread too.
http://www.liferay.com/community/forums/-/message_boards/message/22851073

Before you create a software, should provide the answers to the following questions. I just love giving business advices too. :-)
1. What exactly are you trying to sell?
2. Who will be the target customers of the software
3. Why would they want to buy it
4. How are you going to reach your potential customers? (who is the sales contact - if you don't have any, chances are very low that you'll be able to sell)
5. Where are you going to sell it? What's the business custom there? (If you don't know the business customs, you really should learn before you offend people)

RE: 10 ways to fail as a Liferay plugin developer

2013-03-21T09:08:51Z

That's actually not a way for a developer to fail but more of a way for a plugin to fail. I think we actually made a distinction before.

RE: 10 ways to fail as a Liferay plugin developer

2013-03-19T19:37:48Z

can't please everyone so you have to

on that note ; sure is code outside here in Canada

RE: 10 ways to fail as a Liferay plugin developer

2013-03-19T12:55:29Z

Well, at least we could add another way to fail:

* Developing JSR286 compatible portlets.

Thanks for your contribution Ching.

RE: 10 ways to fail as a Liferay plugin developer

2013-03-19T02:16:20Z

Ching Ice-creaming:

For viewpoint of customers, this is the advantages if portal vendors following JSR286 standard:
1. Outside developers will be happy for avoiding SDK lock-in provided by vendors.
2. Customers will be happy for avoiding vendor lock-in.
3. We shall be happy to watch portal vendors playing a fair game.

And these are the disadvantages:

1. Re-inventing the wheel. Since you're just playing to the 286 standard, you cannot take advantage of any Liferay services. As such, you'll need to re-invent the wheel to provide your own services which mimic what Liferay provides.

2. 286 does not provide a method for sharing code w/ portlets, such as Liferay's Service Builder. So all of your data-related portlets must be tightly coupled (shipped in one war file) or else you sacrifice runtime resources (duplicated jars loaded in separate wars, multiple database connections, data caching issues, etc.).

3. Although 286 works, it is not always the optimal solution. For example, loading js and css via Liferay's liferay-portlet.xml, the portal can better optimize the loaded resources, optimizations that are not available to straight 286 portlets.

4. Since you're not building off of the SDK, you cannot directly access Liferay entities such as User, Group, etc.

5. The Liferay SDK is used for more than building portlets. The SDK is the only way to develop themes, hooks, layouts, etc. All Liferay deployments are more than just portlets. They usually include at least a theme and typically at least a hook or two.

JSR 286 reflects the least common denominator for what the portal vendors could agree to at the time of it's publication five years ago. Each portal vendor at the time and even those in existence today offer extensions that go beyond the 286 standard to be able to customize the environment well beyond what the standard allowed for.

Thinking that delivering only 286-compatible portlets is the answer to the world's portal problems is, IMHO, totally misguided.

RE: 10 ways to fail as a Liferay plugin developer

2013-03-19T01:17:02Z

To Florencia Gadea and all plugin developers,

I must thanks Jelmer Kuperus for his words of wisdoms "Stockholm syndrome". Just two words inspire me to seek my way to make independent portlets

I highly recommend an open source Apache Struts2 http://struts.apache.org (Maybe Spring MVC can do the same generic portlets but I don't know it.)

I figure out my way to request Liferay to improve its products: Just compare, no complain
I prove its problem by struts2 portlet to compare with its competitors
http://code.google.com/p/jasperrocks/wiki/Problems#Liferay

For viewpoint of customers, this is the advantages if portal vendors following JSR286 standard:
1. Outside developers will be happy for avoiding SDK lock-in provided by vendors.
2. Customers will be happy for avoiding vendor lock-in.
3. We shall be happy to watch portal vendors playing a fair game.

Hitoshi Ozawa is demanding for Liferay its own good because it is a portals war.

Now I am busy with the comparison of the new beta eXo Platform 4.0 with Liferay 6.20
Talk to Hitoshi Ozawa later.

Ching