Shane Paul wrote:
Hi there Ian and to all the members of the list,
First time poster and subscriber. :)
I am building and using Pluto for the first time also. (over the
weekend...pity me...) Moving from Liferay to Pluto. Long story but the
crux is we are building our own custom portal essentially and Liferay is
like a heavy, ugly anchor on the project. Their (in house) performance
data sucked also. (it is not on their web site, you have to ask for it -
email if you want it)
I'm not familiar with Liferay (Cocoon user here). Sounds like that's a
good thing... :)
I had the same problem as Ian and found a TEMPORARY solution.
HACK ALERT: This is a 5 second fix and not to be taken as best practice
or even correct.
To make this work you need to edit the:
[...]\pluto-testsuite\pom.xml
I have shown the entry to edit below (commented out) and my workaround.
I have not actually tested the resulting package yet, but it seems good.
<webXml>${basedir}/target/pluto-resources/web.xml</webXml>
<!-- webXml>${project.build.directory}/pluto-resources/web.xml</webXml
-->
This seems to work, but this problem appears throughout the build code.
You end up with things writing to [pluto]/target/ and attempting to find
stuff there. Not sure if this is a maven bug, ant bug or whatever?
Perhaps windows only?
Good catch, Shane! Far as I can tell, the problem is that ${basedir}
refers to the directory where the mvn command was issued, so unless you
run the command from the sub-project directory (e.g.
<PLUTO_HOME>/pluto-testsuite), any paths which reference ${basedir} are
going to be off. Using ${project.build.directory} seems like the right
approach.
On the positive side, according to Eclipse there are only 10 pom.xml's
that reference ${basedir} (that may be because there are only 10
pom.xml's :) ). I will go ahead and create new issues in JIRA and
attach patches as time permits.
Other points to note for everyone:
- Some of these URLs end up being half windows-based "\" and linux "/",
which implies Maven is having a few issues.
Windows supports both "/" and "\" for path seperators, so probably the
best approach would be to standardize on "/"
- If you use "site:site" it will not build the site correctly. The
sub-projects (and importantly the API's) ARE built, but are left in
their corresponding project directories under .../site/.
I've got the same problem with my own multi-project project. This is
probably something that should be addressed in maven-site-plugin.
Hope that helps...
It does, immensely!
Thanks,
Ian
