Maintaining Liferay

[jef vratny, modificado 14 Anos atrás.]

Since I'm quite certain that not everyone buys an EE subscription, I thought it might be good to find out how CE users maintain their installs. I've heard a few methods, but wanted to see what 'best practices' you've all come up with for the following:

Bugs, inevitably there are bugs in any software. Since the process for getting these committed to the core is not quick (and rightly so), how do you manage bug-fixes for your install? Do you fork... errr.. branch the public SVN to keep track of them? Do you submit them to Jira?

Security flaws, again inevitable in any project. If you uncover them what do you do? How do you keep track of these and manage them? Do you report them to Liferay?

SVN repo updates. You've made changes to protect your users or fix broken functionality in the released version. How do you incorporate these into the core when you want to merge in changes from the trunk? Do you merge your changes into the core or do you merge them into your fork... err... branch?

I suppose all these can be handled in the EXT environment or now the EXT plugin environment, but I wanted to see what people REALLY do in these situations. Hopefully this will spark some discussion around how to standardise this to make the liferay CE solution palatable for new users who think about this kind of thing. And yes I might just be instigating here, but these are real considerations for real deployments so I'd like to see the community come up with a way to deal with it that we can all work with since the current policy is to only release patches to EE customers. That's liferay's choice, whether I agree with it or not. I'd like to see the community help itself to a solution so we can all get on with using and building a great platform in a safe and maintainable way.

[Victor Zorin, modificado 14 Anos atrás.]

Quick bullet points based on 5+ years of supporting CE installations.

Maintaining Liferay it is not that hard, as long as you narrow down the out-of-box feature set and know-how-to-do workarounds.

Since I'm quite certain that not everyone buys an EE subscription

From my observations, issues with EE do not differ very much from issues with CE. Everything depends on who helps you to maintain your system. For most companies (which are SMEs) the budget of making an intranet/extranet system is hovering around $10,000, having EE costs on the top would make it 5 times dearer.

Bugs, Jira, etc

Most of bugs are exposed at this forum and it is usually followed by an easy application of a fix (well, easy in 90% of cases). We usually do not care about bugs in portlets, most important ones are within the portal framework.

If there is a bug within the portlet, it would usually have a workaround.
Unfortunately, there is a number of portlets, which had to be re-written from scratch. Submitting bug fix/enhancement for out-of-box portlet is proved to be a loss of effort. It is much easier and cheaper to maintain own portlets.

EXT environment

Never used one, and believe that this is an extremely bad practice. Many companies that used EXT are facing a blank wall now, as they are unable to upgrade their product to a next version.

We always use binary Liferay distribution only.

Using hooks for bug fixing only, keeping in mind that in the next release, they will be dropped.

The worst bugs are those that can not be applied with hooks, in this case we just re-distribute binary portal-impl.jar to our customers. However, it is quire rare, does not happen more than a couple of times per year.

Do not use hooks for extensions, it will cost you a fortune. Make own portlet/project.


Our process is not a "best practice", but I am not sure which one can qualify to be the one.

[jef vratny, modificado 14 Anos atrás.]

Thanks for that Victor, it kind of confirms my thoughts on what actually happens. I'd love to hear other ways, but your reasoning and processes seem pretty pragmatic. BTW I might only have a couple posts here, but have been using Liferay since version 3.x and have felt the pain of even minor version upgrades. I've also had clients who would benefit from the CE version say no to it because of the lack of a formal CE maintenance strategy, even though it was the perfect solution for them in all other respects.

So from what I'm reading, people do their bug fixes/security fixes/etc. based on solutions found in the forums or community in the form of hooks. Which leads me to the question, does anyone share theses solutions back to the community (I mean in the form of code, not posts) for peer review, validation or even just to make somebody else's life easier?

I realize liferay isn't going to dedicate resources to this process at the moment, but with a community this large it would make sense for the community to do it. Having thousands of people manually monitor the forums, wiki & blogs for fixes and code snippets so they can go do the same thing thousands other people have had to do seems a wee bit inefficient. Tossing out the work of all those people at the next release also seems a bit of a waste to me as well.

If there was a way to collaboratively manange CE patches/updates, etc. on this site, or any other for that matter, would you participate? Would you see benefit in being able to grab a plugin or a patch file to solve your problems? Would you want a 'CE patch plugin' that is maintained by the community for the community? Would you take the time to review the code and/or provide feedback to the person who submitted it?

Open Source is just as much about the community as it is the software, if not more so IMHO. Liferay enables communities. This community enables Liferay. Shouldn't this community enable this community too?

I don't have a solid answer to this, but am beginning to formulate some ideas. I'd like to see what kind of interest and ideas other people might have.