Re: Trouble Building Pluto Testsuite Portlet from SVN

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