Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Building Liferay from source (subversion or git) Jorge Correa August 7, 2012 6:43 AM
RE: Building Liferay from source (subversion or git) Jorge Correa August 8, 2012 4:52 AM
RE: Building Liferay from source (subversion or git) Hitoshi Ozawa August 11, 2012 6:08 PM
RE: Building Liferay from source (subversion or git) Jorge Correa August 13, 2012 4:22 AM
RE: Building Liferay from source (subversion or git) Hitoshi Ozawa August 13, 2012 4:32 AM
RE: Building Liferay from source (subversion or git) Peter B West August 16, 2012 6:44 PM
RE: Building Liferay from source (subversion or git) Jorge Correa August 17, 2012 9:37 AM
RE: Building Liferay from source (subversion or git) Peter B West August 20, 2012 1:12 AM
RE: Building Liferay from source (subversion or git) David H Nebinger August 20, 2012 5:16 AM
RE: Building Liferay from source (subversion or git) Hitoshi Ozawa August 20, 2012 5:27 AM
RE: Building Liferay from source (subversion or git) Peter B West August 20, 2012 6:06 AM
RE: Building Liferay from source (subversion or git) David H Nebinger August 20, 2012 7:01 AM
RE: Building Liferay from source (subversion or git) Hitoshi Ozawa August 20, 2012 8:35 AM
RE: Building Liferay from source (subversion or git) David H Nebinger August 20, 2012 9:34 AM
RE: Building Liferay from source (subversion or git) Hitoshi Ozawa August 20, 2012 2:50 PM
RE: Building Liferay from source (subversion or git) Peter B West August 20, 2012 3:53 PM
RE: Building Liferay from source (subversion or git) David H Nebinger August 20, 2012 4:28 PM
RE: Building Liferay from source (subversion or git) Jorge Correa August 21, 2012 7:39 AM
RE: Building Liferay from source (subversion or git) James Falkner August 21, 2012 8:49 AM
RE: Building Liferay from source (subversion or git) Peter B West August 21, 2012 1:29 PM
RE: Building Liferay from source (subversion or git) James Falkner August 21, 2012 2:30 PM
RE: Building Liferay from source (subversion or git) Peter B West August 23, 2012 4:31 PM
RE: Building Liferay from source (subversion or git) James Falkner August 24, 2012 11:19 AM
RE: Building Liferay from source (subversion or git) Peter B West September 3, 2012 5:02 PM
Jorge Correa
Building Liferay from source (subversion or git)
August 7, 2012 6:43 AM
Answer

Jorge Correa

Rank: New Member

Posts: 5

Join Date: August 7, 2012

Recent Posts

Hi, I would like to know where to find an updated guide explaining how to build Liferay from source. Months ago I built from 6.1.x branch, with all required plugins. Last week I update the code with subversion and some files changes, for example, build-dist.xml.

My scenario is:

Liferay CE 6.0.6 in production (installed from bundle with Tomcat)
Trying to build from tag 6.1.1

I've already tested some weeks ago the migration from 6.0.6 to 6.1.x and it worked fine. So, now I would like to generate a bundle with 6.1.1 (from tag directory of SVN) with tomcat 7.0.29.

Where can I find a guide? In my tests I can build Liferay but not the plugins :/

Thanks a lot.
emoticon
Jorge Correa
RE: Building Liferay from source (subversion or git)
August 8, 2012 4:52 AM
Answer

Jorge Correa

Rank: New Member

Posts: 5

Join Date: August 7, 2012

Recent Posts

Following with my tests, I've checked out liferay and plugins again. So, i've made some modifications in some build files, to adjust some locations. Running 'ant -buildfile build-dist.xml dist' I can build Liferay. However, what and where do I have to set to build the plugins?

The log of building shows that section about plugins:


update-plugins-includes: (this is a target)

update-plugins-includes-plugin:

update-plugins-includes-plugin:

update-plugins-includes-plugin:

.
.
.
.

But, not happens. In some versions ago, I could found a section in release.properties as:

lp.plugins.includes.misc=${lp.plugins.includes.tcat},mongodb-hook,social-bookmarks-hook,analog-clock-portlet,sample-groovy-portlet,sample-icefaces-ipc-ajax-push-portlet,sample-icefaces-jsf-1.1-myfaces-jsp-portlet,sample-icefaces-jsf-1.2-sun-facelets-portlet,beautiful-day-theme,bitter-sweet-theme,bright-pixel-theme,brochure-theme,brownie-theme,chit-chat-theme,cleap-theme,coffee-n-cream-theme,desktop-theme,dirtylicious-theme,drupal-garland-theme,emerald-theme,envision-theme,facebook-theme,illuminate-theme,jedi-theme,kort-theme,murali-theme,night-and-day-theme,noir-theme,sample-html4-theme,sample-styled-advanced-theme,sample-styled-minimal-theme,sample-unstyled-theme,sample-wap-theme,section-508-theme,sevencogs-theme,spurt-theme,test-servlet-context-include-filter-theme,titan-theme,tuxedo-theme,wordpress-kubrick-theme,wordpress-twenty-ten-theme,yellow-jacket-theme,zenlike-theme,server-manager-web,wurfl-web
lp.plugins.includes.required=sevencogs-hook,chat-portlet,google-maps-portlet,knowledge-base-portlet,mail-portlet,opensocial-portlet,social-networking-portlet,web-form-portlet,wsrp-portlet,sevencogs-theme,kaleo-web
lp.plugins.includes.tcat=${lp.plugins.includes.required},antisamy-hook,default-web-content-hook,ddl-form-portlet,digg-portlet,flash-portlet,google-adsense-portlet,ip-geocoder-portlet,private-messaging-portlet,netvibes-widget-portlet,social-coding-portlet,stocks-portlet,twitter-portlet,vimeo-portlet,weather-portlet,wiki-navigation-portlet,youtube-portlet,cas-web,solr-web

But these variables are not present in new versions.

Anyone could help?

Thanks.
Hitoshi Ozawa
RE: Building Liferay from source (subversion or git)
August 11, 2012 6:08 PM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7990

Join Date: March 23, 2010

Recent Posts

Check the following page.

http://www.liferay.com/community/wiki/-/wiki/Main/Develop+Liferay+Core+with+Tomcat

It's mostly
ant all
ant deploy
Jorge Correa
RE: Building Liferay from source (subversion or git)
August 13, 2012 4:22 AM
Answer

Jorge Correa

Rank: New Member

Posts: 5

Join Date: August 7, 2012

Recent Posts

Unsuccessful. 'ant all' and 'ant deploy' finish without errors but I'm not seeing the plugins yet.

I suspect that I have to change something in build files to set plugins to be built correctly.

'ant all' and 'ant deploy' don't generate a zip bundle too. Using the 'dist' target I can get a zipped bundle, with tomcat, but without the plugins.

For example, my folder structure is something like:

~/Liferay
~/Liferay/6.1.1/ (from svn)
~/Liferay/bundle/ (with tomcat inside)
~/Liferay/plugins/6.1.1 (from svn)

After call the 'dist' target I can see a zip file in ~/Liferay/6.1.1/dist. But there is no plugin inside. And, no plugin in ~/Liferay/plugins/6.1.1/dist/. Some weeks ago I had built and all worked fine. But after a svn update the build files changed and now I can't build everything.

Thanks!!
emoticon
Hitoshi Ozawa
RE: Building Liferay from source (subversion or git)
August 13, 2012 4:32 AM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7990

Join Date: March 23, 2010

Recent Posts

ant all
OR
ant clean
ant start
ant deploy

should deploy liferay to specified application server. Which plugins are you looking for. Some plugins have to be build/deployed separately.
Peter B West
RE: Building Liferay from source (subversion or git)
August 16, 2012 6:44 PM
Answer

Peter B West

Rank: Junior Member

Posts: 57

Join Date: March 23, 2009

Recent Posts

I've tried building from the 6.1.x branch of portal, with the same branch of plugins installed as a sibling directory, and the appropriate values in release.properties.

A few things I've noticed about the build:

The lp.version in portal/release.properties is 6.1.0. The lp.version in plugins/build.properties is 6.1.1. At a certain point, the build tries to find the wrong jar (or war?) file from plugins because of this discrepancy.

The plugins/build.${user.name}.properties file is repeatedly overwritten in the build process, so don't rely on that.

The build is liberally sprinkled with Windows-only constructs.

Altogether, it's not easy to build.
Jorge Correa
RE: Building Liferay from source (subversion or git)
August 17, 2012 9:37 AM
Answer

Jorge Correa

Rank: New Member

Posts: 5

Join Date: August 7, 2012

Recent Posts

-> The lp.version in portal/release.properties is 6.1.0. The lp.version in plugins/build.properties is 6.1.1. At a certain point, the build tries to find the wrong jar (or war?) file from plugins because of this discrepancy.

Same here. We had to correct this versions to complete the build without error.

The plugins/build.${user.name}.properties file is repeatedly overwritten in the build process, so don't rely on that.

Yes, the same with 6.1.1 TAG branch. I'm putting a list of plugins, for example, inside the build.properties in the 'includes' variable.

I'm using the same environment that you, with a branch checked out from SVN and a sibling directory for plugins. I noticed that from 6.1.x to 6.1.1 the build files (.xml) are a little different. With the TAG branch I'm using the following to build:

From 6.1.1 Liferay directory:
ant clean
ant compile
ant deploy

Files will be copied inside the tomcat directory informed in build.properties.

So, in the plugins' directory, after the Liferay deploy:
ant clean
ant compile
ant deploy

Then, a 'deploy' directory will be create at the same directory level of tomcat folder, with the plugins we selected in release.properties.

However, when I start the application, I'm getting the following errors (filtered log, only the errors):

16:31:41,947 ERROR [localhost-startStop-1][PortalInstances:468] com.liferay.portal.kernel.events.ActionException: com.liferay.portlet.dynamicdatamapping.StructureNameException
16:31:46,352 ERROR [http-bio-8080-exec-1][ThemeUtil:445] _SERVLET_CONTEXT_/wap/themes/mobile/templates/portal_pop_up.vm does not exist
16:33:20,578 ERROR [com.liferay.portal.search.lucene.LuceneHelperImpl-1][FileImpl:321] org.apache.tika.exception.TikaException: Unexpected RuntimeException from org.apache.tika.parser.microsoft.OfficeParser@e2d4aa1
16:33:33,264 ERROR [com.liferay.portal.search.lucene.LuceneHelperImpl-1][FileImpl:321] org.apache.tika.exception.TikaException: Unexpected RuntimeException from org.apache.tika.parser.microsoft.OfficeParser@76e80326
16:33:50,300 ERROR [com.liferay.portal.search.lucene.LuceneHelperImpl-1][PDCIDFont:328] Error: Could not parse predefined CMAP file for 'Adobe-WinCharSetFFFF-UCS2'

it's frustrating that the buildings are not being checked. I really hope that at least the TAG branch could be built without all these problems.

Thanks!
Peter B West
RE: Building Liferay from source (subversion or git)
August 20, 2012 1:12 AM
Answer

Peter B West

Rank: Junior Member

Posts: 57

Join Date: March 23, 2009

Recent Posts

I've given up on building an environment that I can use as I can the distributed tomcat bundle and the distributed plugins sdk. I have no idea what the developers actually do to generate these environments. I wish I did. The whole point about having a git repository is that you can apply patches as they are developed in parallel with your own changes. But if you can't build the same environments, what's the use?

For instance, see http://www.liferay.com/community/forums/-/message_boards/message/15702262 for an example of a build wrinkle that has been specifically written for a windows system. If you run this build on, say OS X, that part of the build will not occur. This is terrible.
David H Nebinger
RE: Building Liferay from source (subversion or git)
August 20, 2012 5:16 AM
Answer

David H Nebinger

Rank: Liferay Legend

Posts: 7157

Join Date: September 1, 2006

Recent Posts

Liferay uses Git in a different manner than what we expect. The Git repository is meant to be a work in progress, not an environment suited for building and using.

If you must 'build from source' (which is never encouranged, by the way), your best bet is to use a stable release (i.e. GA2) and it's source/plugin SDK versions.
Hitoshi Ozawa
RE: Building Liferay from source (subversion or git)
August 20, 2012 5:27 AM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7990

Join Date: March 23, 2010

Recent Posts

Liferay.com is global. It seems parts are developed in different countries by several teams. There doesn't seem to be a strong standard on which platform to use nor encoding nor end of line marker. I've also seen some difference in programming style.

The best bet is to go with the GA release source and build your branch from there. Don't use the Github because it's work in progress and not always guaranteed to work 100%.
Peter B West
RE: Building Liferay from source (subversion or git)
August 20, 2012 6:06 AM
Answer

Peter B West

Rank: Junior Member

Posts: 57

Join Date: March 23, 2009

Recent Posts

David, Hitoshi,

Not unexpectedly, I disagree. If this were a centralised repository, say subversion, I might go along with you. But it is a DVCS. I have three or four copies of the repo sitting on my drive. The same is true of every developer.

A primary consequence of that fact is that there is never any excuse to break the master build with a checkin. If you want to play with dodgy things, throw a branch, but don't contaminate master (or 6.1.x.) If the developers don't get that, then they need to sit down and think about what a DVCS is, how it differs from the old way, and what fabulous advantages it offers.

All that aside, Jorge was talking about the 6.1.1 tag. A tag says, this is it, folks. But it isn't. If you can't build from the repository, then there is all sorts of stuff going on under the covers to get the thing built, and that stuff is not available in the repo.

Have a look at the source code release for 6.1.1. See portal-impl/build.xml; that is, the example I quoted in 15702262. The code is exactly the same. This sloppy stuff is not an aberration of an unstable repository- it's endemic.

Hitoshi, you're one of the people who would benefit most if the git repo were to be run correctly. You can clone the repository in a known state, and work from there to implement your own changes. You have a reference tree REF that tracks the liferay repo. From that reference repo you clone your own working tree WRK. You merge from your working tree (which has its own repo branch) back into your reference tree, and you merge from the Liferay repo as it changes. When merge conflicts occur, you resolve them in your reference branch, and commit them to REF. You can test the functionality of REF as changes are made. It the reference tree continues to build, and to work for you, you can merge out to WRK, and continue to develop there. If not, you can note the problems, and continue with WRK. In either case, you maintain maximum compatibility with the developing Liferay code, and minimise the pain when a new release occurs, because you already know where the conflicts have occurred.

I have commented before about the development process seeming to be out of control. This is more evidence. The pity of it is, that a DVCS allows maximum freedom to developers at the price of some modest discipline about the reference repository - in this case, github. With a DVCS, you can have it both ways, and everyone benefits.
David H Nebinger
RE: Building Liferay from source (subversion or git)
August 20, 2012 7:01 AM
Answer

David H Nebinger

Rank: Liferay Legend

Posts: 7157

Join Date: September 1, 2006

Recent Posts

Peter B West:
A primary consequence of that fact is that there is never any excuse to break the master build with a checkin. If you want to play with dodgy things, throw a branch, but don't contaminate master (or 6.1.x.) If the developers don't get that, then they need to sit down and think about what a DVCS is, how it differs from the old way, and what fabulous advantages it offers.


Oh, I whole heartedly agree with you. If one of my developers checks in code that breaks a build, they get an ear full... I expect that all checkins have been tested and synchronized and that, at any point in time, I can do a build and get a successful outcome. I'm an advocate of automated build systems that rebuild on every repository checkin as it keeps the code in sync at all times.

However, this is just one way to use a centralized repository. Liferay's way seems to be to let development flow forward and allow possible breakages knowing they'll get cleaned up later. I guess it works for them...

That doesn't mean that I advocate their way, I'm just passing along the info as how they do it and why you should not be using the repository for building Liferay from source...
Hitoshi Ozawa
RE: Building Liferay from source (subversion or git)
August 20, 2012 8:35 AM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7990

Join Date: March 23, 2010

Recent Posts

Hitoshi, you're one of the people who would benefit most if the git repo were to be run correctly.


No I won't. Portlets are fun to play around but the only portlet that's really being used in production is the web content portlet to create a simple page on url indexes. There actually isn't any market for a portal in Japan.

I'm building generic and customized applications package with the stripped down framework and really don't see any benefit of keeping it in sync with liferay.com's source. I thought everybody else was using liferay in a similar manner.
David H Nebinger
RE: Building Liferay from source (subversion or git)
August 20, 2012 9:34 AM
Answer

David H Nebinger

Rank: Liferay Legend

Posts: 7157

Join Date: September 1, 2006

Recent Posts

Hitoshi Ozawa:
Hitoshi, you're one of the people who would benefit most if the git repo were to be run correctly.


No I won't. Portlets are fun to play around but the only portlet that's really being used in production is the web content portlet to create a simple page on url indexes.


Neither would I, in fact. I am a Liferay user, not a developer. I want a standard release version of Liferay to build from, whether it is using as-is or overriding/customizing in some necessary way.

The early GA releases tend to be buggy enough, why would I want to bang my head against the wall trying to work from the repository? emoticon

The repository should only be used if you are actually a Liferay developer (developer in the sense that you are contributing patches to the core, since the patches are only accepted for the latest and greatest (from the Git repository)).

If you are just a Liferay user (user in the sense that you may be developing portlets, themes, hooks, etc., just not submitting patches), you should never be using the git repository.
Hitoshi Ozawa
RE: Building Liferay from source (subversion or git)
August 20, 2012 2:50 PM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7990

Join Date: March 23, 2010

Recent Posts

Liferay.com is in a business of selling support. They're providing a software for free in the form of community edition and charging for support. I think that's fair enough. People usually don't go into a store and complain about having to pay. I really don't know why people complain about when they have to pay for software support.

I complain when liferay.com don't fulfill their promises and when they do something that's very bad marketing practice which I think is really hurting their business, but I think people should get paid for what they've done. This goes for liferay.com staff as well as other people involved with liferay (ie. people shouldn't expect liferay.com to provide everything for free nor liferay.com think people should provide them something for free.).

To put it simply, do what you've promised and get rewarded for what's you've done. Don't promise what you can't fulfill and don't expect people to serve you. I think that's what fair means.
Peter B West
RE: Building Liferay from source (subversion or git)
August 20, 2012 3:53 PM
Answer

Peter B West

Rank: Junior Member

Posts: 57

Join Date: March 23, 2009

Recent Posts

I certainly haven't demanded that Liferay give me enterprise level support. I'm in favour of Liferay making money, because I can then expect the product to continue to develop. If I didn't want development, I could just take an earlier, relatively stable release and develop applications based on that. Then I could forget about whatever it is that Liferay is or is not doing.

We're all here, though, because we expect and depend upon that ongoing development. If we have our own customer base, we expect to be able to improve the product we supply by incorporating the improvements that are made by Liferay with our own specialisations. As Liferay has developed, the need to access the code base has diminished, and hooks are available for many of the specialisations we require. Many, but not necessarily all.

For example, when the 6.1.0 GA1 release came, upgrades crashed for lots of people. Obviously, for whatever reason, there were a lot of people who wanted this upgrade. In one of the forum conversations, reference was made to a patch for one of the upgrade problems. The patch required a build against 6.1.0 GA1 codebase.

As I have pointed out more than once, I cannot build on OS X against the 6.1.0 GA source release, the 6.1.1GA2 source release, the 6.1.1 tag in Github. That is, I can't build without hacking the build scripts. I have hacked away quite a bit, but I have never managed a successful build against any 6.1 codebase, portal + plugins.

Am I demanding that Liferay support me? No. I am asking that Liferay live up to its own claims. This is a open source project. I don't make that claim, Liferay does. Its open source roots are the basis of Liferay's business model. Without it, where would they be? Their user base and their credibility has been built on that model. Their enterprise user base is, ultimately, built on it as well.

If Liferay decide to change that, it is their business entirely. As yet, they have not. Therefore, I have the same expectations of the Liferay codebase as I have of any other open source project.
David H Nebinger
RE: Building Liferay from source (subversion or git)
August 20, 2012 4:28 PM
Answer

David H Nebinger

Rank: Liferay Legend

Posts: 7157

Join Date: September 1, 2006

Recent Posts

Peter B West:
For example, when the 6.1.0 GA1 release came, upgrades crashed for lots of people. Obviously, for whatever reason, there were a lot of people who wanted this upgrade. In one of the forum conversations, reference was made to a patch for one of the upgrade problems. The patch required a build against 6.1.0 GA1 codebase.


I consider that a horse of a different color...

The first 6.0 GA releases also had their share of problems. As it turns out, it wasn't until about GA4 that things stabilized enough to warrant a move to 6.0 (IMHO).

I treat the 6.1 GA releases in the same light. I'll wait for probably a few more GAs before I take my company down that road, waiting for the dust to settle on the new Marketplace additions, etc.

I too keep the 6.1 head from Git around. Not as a platform for building a runnable version of Liferay, but to see all of the feature changes that are going in and identify what my future pain points will look like for upgrades. I also have the 6.1 GA2 source also so I can respond to forum posts...

I understand your frustration, Peter. But in the end it's their repository; they own it, they control it, etc. There's lots of things they could do better with it, as well as things they could do worse (i.e. only committing to an internal repository (hiding ongoing code changes and fixes) and publish to public repository after a version release).
Jorge Correa
RE: Building Liferay from source (subversion or git)
August 21, 2012 7:39 AM
Answer

Jorge Correa

Rank: New Member

Posts: 5

Join Date: August 7, 2012

Recent Posts

IMHO, the opensource model from Liferay is a quite different from the common opensource communities. "We are opensource. Here is, a ton of code. It's open, for you". And we cannot do so much with it. I see a strange opensource business model.

Yeah, they sell support. But Canonical do the same and Ubuntu without support works fine, have a community, is fairly documented etc etc.

I see a big security problem in waiting for GA releases. I was wishing build Liferay because just two facts: (1) GA also has bugs and I couldn't migrate from 6.0.6 to 6.1 because an issue which patch was in SVN, and I had to build from source; (2) I expected that building from a SVN TAG version I could get some corrections, mainly in security problems, before a GA release. Unsuccessful.

And, I think Liferay team may use a lot of patches committed by community members that identifies problems and tell the developers. So, at least a TAG version that are stable could be expected. I really don't want support. I wanted just a functional software.

Cheers!
James Falkner
RE: Building Liferay from source (subversion or git)
August 21, 2012 8:49 AM
Answer

James Falkner

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1218

Join Date: September 17, 2010

Recent Posts

Jorge Correa:
IMHO, the opensource model from Liferay is a quite different from the common opensource communities. "We are opensource. Here is, a ton of code. It's open, for you". And we cannot do so much with it. I see a strange opensource business model.

Yeah, they sell support. But Canonical do the same and Ubuntu without support works fine, have a community, is fairly documented etc etc.

I see a big security problem in waiting for GA releases. I was wishing build Liferay because just two facts: (1) GA also has bugs and I couldn't migrate from 6.0.6 to 6.1 because an issue which patch was in SVN, and I had to build from source; (2) I expected that building from a SVN TAG version I could get some corrections, mainly in security problems, before a GA release. Unsuccessful.

And, I think Liferay team may use a lot of patches committed by community members that identifies problems and tell the developers. So, at least a TAG version that are stable could be expected. I really don't want support. I wanted just a functional software.

Cheers!


You are all right - building Liferay from source, and including plugins during the build, is not easy, but not impossible. I do it fairly regularly, but I only ever use 'ant all' for building the core (this is on Mac OS X), and then for individual plugins, an 'ant deploy' or 'ant war' to build the WAR but skip the deploy bit. You wouldn't want to build and deploy every single plugin from Liferay's plugins source code - there are tons of samples, etc. The official bundles only ship with the welcome-theme, welcome-hook, and marketplace-portlet. So to re-create this, just build the core, then build those three plugins and drop them into the deploy directory. Then zip the whole thing up and you've got yourself your own Liferay distribution.

I don't think we have given our build processes enough "tender love and care" over the years, and our internal build processes are complex because of it (and there is old, legacy code like the windows hack that Peter found). It needs cleanup. Building Ubuntu from its source code is similarly a challenging concept, but that is an operating system running on bare metal, and packaging up all the goodies that come along with it is also another challenge in itself.
Peter B West
RE: Building Liferay from source (subversion or git)
August 21, 2012 1:29 PM
Answer

Peter B West

Rank: Junior Member

Posts: 57

Join Date: March 23, 2009

Recent Posts

These are very useful comments, James. Thank you.
James Falkner
RE: Building Liferay from source (subversion or git)
August 21, 2012 2:30 PM
Answer

James Falkner

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1218

Join Date: September 17, 2010

Recent Posts

Peter B West:
These are very useful comments, James. Thank you.


Thanks Peter. Here's a cheat sheet (I just did this on my Mac (Snow Leopard)) for those that wish to build from source and re-create the pre-packaged LR bundles. This is on unix. Windows would be the same, assuming you have a command line 'zip' utility (and mv becomes move, and so on):


 1# make sure you have java
 2java -fullversion    # outputs java full version "1.6.0_33-b03-424"
 3
 4# give ant more room to work with
 5export ANT_OPTS="-Xmx1G -XX:MaxPermSize=512m"
 6
 7# download sources from github
 8wget --no-check-certificate --output-document=lr61ga2-src.zip https://github.com/liferay/liferay-portal/zipball/6.1.1-ga2
 9wget --output-document=lr61ga2-plugins.zip https://github.com/liferay/liferay-plugins/zipball/6.1.x
10
11# unzip liferay core
12unzip -q lr61ga2-src.zip
13
14# rename dir for ease of use
15mv liferay-liferay-portal-fe70851 portal
16
17# unzip liferay plugins
18unzip -q lr61ga2-plugins.zip
19
20# rename dir for ease of use
21mv liferay-liferay-plugins-7ed82a4 plugins
22
23# make empty bundles dir
24mkdir bundles
25
26# download tomcat bundle and extract
27cd portal
28ant -f build-dist.xml unzip-tomcat
29
30# build core, takes a few minutes
31ant all
32
33# build the same plugins that are bundled by Liferay
34cd ../plugins/portlets/marketplace-portlet
35ant deploy
36cd ../../themes/welcome-theme
37ant deploy
38cd ../../webs/resources-importer-web
39ant deploy
40
41# zip everything up
42cd ../../../bundles
43zip -r /tmp/mylr.zip data deploy tomcat-7.0.27
44
45# sometime later, I want to use it
46unzip -d /tmp/someloc mylr.zip
47cd /tmp/someloc
48./tomcat-7.0.27/bin/startup.sh
49
50# success! (hopefully)
Peter B West
RE: Building Liferay from source (subversion or git)
August 23, 2012 4:31 PM
Answer

Peter B West

Rank: Junior Member

Posts: 57

Join Date: March 23, 2009

Recent Posts

Success indeed. I built from clones of portal and plugins at branch 6.1.x, but otherwise followed the steps you outlined.

As you said, the build system needs some love. Clearly there have been major changes recently, but why the 'dist' target, or some variation of it, doesn't perform the steps you laid out is beyond me. The greatest beneficiaries would be the liferay developers themselves, and especially new developers trying to work out what is going on.

Follow-up question, which I hope you can help with. If I want to build a local distribution, I proceed as you outlined. As you point out, I don't want to build all of the plugins. Is it feasible to extend this procedure to deploy a full set of required plugins? There may, for example, be interdependencies which make that difficult.
James Falkner
RE: Building Liferay from source (subversion or git)
August 24, 2012 11:19 AM
Answer

James Falkner

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1218

Join Date: September 17, 2010

Recent Posts

Peter B West:
Success indeed. I built from clones of portal and plugins at branch 6.1.x, but otherwise followed the steps you outlined.

As you said, the build system needs some love. Clearly there have been major changes recently, but why the 'dist' target, or some variation of it, doesn't perform the steps you laid out is beyond me. The greatest beneficiaries would be the liferay developers themselves, and especially new developers trying to work out what is going on.


For fun, I just did an 'ant dist' and yeah it makes everything fine until it gets to plugins. Not sure what it's trying to do, but I'll see if I can clean it up and make it more sane.


Follow-up question, which I hope you can help with. If I want to build a local distribution, I proceed as you outlined. As you point out, I don't want to build all of the plugins. Is it feasible to extend this procedure to deploy a full set of required plugins? There may, for example, be interdependencies which make that difficult.


When you say 'required plugins' which ones are you referring to? Liferay can be built and deployed with *no* plugins from the liferay-plugins git repository. So strictly speaking, none of them are required. You could theoretically write a routine which, given a list of desired plugins, will drag in all of the required plugins, based on the dependencies described in each plugin's metadata.
Peter B West
RE: Building Liferay from source (subversion or git)
September 3, 2012 5:02 PM
Answer

Peter B West

Rank: Junior Member

Posts: 57

Join Date: March 23, 2009

Recent Posts

James Falkner:
Peter B West:
Success indeed. I built from clones of portal and plugins at branch 6.1.x, but otherwise followed the steps you outlined.

As you said, the build system needs some love. Clearly there have been major changes recently, but why the 'dist' target, or some variation of it, doesn't perform the steps you laid out is beyond me. The greatest beneficiaries would be the liferay developers themselves, and especially new developers trying to work out what is going on.


For fun, I just did an 'ant dist' and yeah it makes everything fine until it gets to plugins. Not sure what it's trying to do, but I'll see if I can clean it up and make it more sane.


That would be very useful.



Follow-up question, which I hope you can help with. If I want to build a local distribution, I proceed as you outlined. As you point out, I don't want to build all of the plugins. Is it feasible to extend this procedure to deploy a full set of required plugins? There may, for example, be interdependencies which make that difficult.


When you say 'required plugins' which ones are you referring to? Liferay can be built and deployed with *no* plugins from the liferay-plugins git repository. So strictly speaking, none of them are required. You could theoretically write a routine which, given a list of desired plugins, will drag in all of the required plugins, based on the dependencies described in each plugin's metadata.


"Required" should have read "desired."

I was thinking about a build that had the same set of plugins as an already running instance. However, I realised that I had no idea how upgrades were supposed to work in the new marketplace environment. Will upgrades require a subsequent step to get any "required" plugins from the market place?