Benjamin Bentmann wrote:
Dennis Lundberg wrote:
The problem comes when the user specifies a stagingDirectory. The
parameter is of type File and will be created relative to the currently
running project. This has to change so that it is relative to the top most
project of the reactor. Unfortunately I haven't been able to crack that
one.
If I understand correctly you need to:
a)
Change the parameter type to String to disable Maven's path translation such
that the plugin can resolve relative paths on its own. Changing the
parameter type from File to String should be transparent for plugin users,
i.e. shouldn't cause any existing configurations to break.
I just realized that we don't need to do this. I found, buried in the
docs, that the stagingDirectory must not be dynamic, so I clarified this
for the parameter as well:
/**
* Staging directory location. This needs to be an absolute path, like
* <code>C:\stagingArea\myProject\</code> on Windows or
* <code>/stagingArea/myProject/</code> on Unix.
*
* @parameter expression="${stagingDirectory}"
*/
protected File stagingDirectory;
b)
Determine the top-level project to use for path resolution. Looking at
o.a.m.p.ProjectSorter.getTopLevelProject(), it seems you could simply
iterate through ${reactorProjects} and lookout for one with
isExecutionRoot() == true. However, I am not sure how John's javadoc comment
regarding the "-r" option affects the correctness of this approach.
Thanks Benjamin, that's exactly what I needed! I had a solution, but it
was using the inheritance hierarchy, which isn't necessarily the same as
the reactor hierarchy.
Benjamin
P.S. Again, my original answer was "spam" :(
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
