Hi David
I have been taking a look at your excellent "Constructing a
special-purpose server using maven" (link below) in the hope to actually
get Liferay 5.0.1 (rc1) running on Geronimo 2.1.1 in a special purpose
build. Working on this i noticed what I believe is a typo in the
documentation of the liferay-jetty pom
<configuration>
:
<module>
<groupId>com.liferay</groupId>
<artifactId>liferay-portal</artifactId>
<version>${liferayVersion}</version>
<type>war</type>
</module>
:
If I understand things right the artifactId should be
"liferay-portal-lesslibs" else the liferay portal plugin would be the
unmodified liferay war.
Despite this finding I am unfortunately stuck at the same 404 error at
http://localhost:8080/c as pointed out in the documentation. Although I
added the debugviews console portlet plugin and trying to squeeze some
logging out of liferay to find out what is going on I have so far not
been able to get past this problem.
Have anyone got some luck with this ?
Any suggestion on what to do to get more information out of
liferay/geronimo to be able to pinpoint and fix this error is greatly
appreciated!
regards
peter petersson
David Jencks wrote:
On Mar 4, 2008, at 9:48 AM, Jim Foster wrote:
<snip>
Hi David,
I am glad that this is turning out to be a productive discussion.
I have some more review notes for you.
For reference:
Constructing a special-purpose server using maven
http://cwiki.apache.org/confluence/display/GMOxDOC21/Constructing+a+special-purpose+server+using+maven
[1] Preparation – find the artifacts
[2] Set up a parent maven project
[3] Repackage the liferay war
[4] Build a database plugin
[5] Build the liferay war plugin
[6] Build an assembly
[7] Run the project
Note:
In the following, I use the term "baseline" to mean your
liferay-sample.jar
attached to your wiki doc, which builds as it should in maven (hence
"baseline"), and "doc" to mean your wiki documentation.
[3] baseline has this:
<version>4.4.1</version>
whereas the doc has this:
<version>${liferayVersion}</version>
which produces an artifact not found error (i.e., there is no
liferayVersion defined at this point of the process).
fixed
[5] baseline has this:
<dependency>
<groupId>com.liferay</groupId>
<artifactId>liferay-portal-lesslibs</artifactId>
<version>${liferayVersion}-SNAPSHOT</version>
<type>war</type>
<scope>provided</scope>
</dependency>
whereas the doc has this:
<dependency>
<groupId>com.liferay</groupId>
<artifactId>liferay-portal-lesslibs</artifactId>
<version>${liferayVersion}</version>
<type>war</type>
<scope>provided</scope>
</dependency>
which produces
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
GroupId: com.liferay
ArtifactId: liferay-portal-lesslibs
Version: 4.4.1
fixed
[6] baseline has this:
<properties>
<geronimoVersion>2.1</geronimoVersion>
</properties>
whereas the mvn command generates this:
<properties>
<geronimoVersion>2.2-SNAPSHOT</geronimoVersion>
</properties>
which produces
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
GroupId: org.apache.geronimo.assemblies
ArtifactId: assemblies
Version: 2.2-SNAPSHOT
Reason: Unable to download the artifact from any repository
added a note near the top about this.
[7] I see the same PermGen error.
I wonder if we built this using MySQL rather than the system database (as
the Liferay folks intended) we would be in better shape?
After all, that database (the MySQL version at least) is just shy of
60MB,
so it stands to reason that we are taxing resources here.
I would like to explore this. Could you please guide me?
It's worth a try, although it's also a bit worrysome. permGen OOM
errors normally mean you are creating too many classes. The amount of
data being fed into a database shouldn't affect the number of classes
needed so if it is somehow affecting this I wonder if something else
is wrong.
I'll see if I can write up an example later today, but meanwhile you
might look at the mysql plugin for roller under plugins/roller/trunk.
The basic idea is to build another database plugin, like the derby
one but using the mysql wrapper and include something like this so the
mysql plugin gets used instead of the derby one when it's installed.
<artifact-alias
key="org.apache.geronimo.plugins/roller-derby-database/${version}/car">org.apache.geronimo.plugins/roller-mysql-database/${version}/car</artifact-alias>
Apache can't distribute something that automatically downloads the
mysql driver jar which is why the roller plugin has mysql as a
prerequisite. If you are in an environment where this is not a
concern you can leave out the prerequisite and geronimo will install
the mysql jar for you when you install the mysql plugin.
I think I have the basics down of what would be needed, but I don't
think I
quite have it all down yet, and I would like to know for sure by
hearing it
from you.
I think you are getting there, keep asking questions!
I would like to see us put this puppy to bed, you folks bless it for the
general public, and move on (Liferay portal is but the first of
several apps
I am building on top of Geronimo - details of this project to be
shared as
we go).
looking forward to it!
thanks
david jencks
Thanks!
Jim
--
View this message in context:
http://www.nabble.com/Geronimo-v2.1-Plan-Creator-%3D%3E-Deploy-Liferay-4.1.1-tp15437773s134p15833008.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.