On 02/01/2008, Steinar Bang <[EMAIL PROTECTED]> wrote:
>
> >>>>> "Stuart McCulloch" <[EMAIL PROTECTED]>:
>
> > yes, the <manifestLocation> is a File parameter, so if you use a
> > relative path Maven will calculate it relative to the ${basedir}
>
> Hm... thinking back, where I've seen issues with this have been when I
> have inherited a setting from a parent with packaging POM, and then
> verified that it have worked when running in the project in question,
> but then have failed when running the project as part of a
> multi-project.btw, a few months ago this was the case ( see https://issues.apache.org/jira/browse/FELIX-402 ) but it's now fixed in trunk and the latest 1.1.0-SNAPSHOT - I've tested it with multi-projects and it works as expected, but if you find a scenario where it doesn't work please raise an issue. these kind of issues can happen with plugins that run in a forked lifecycle, where $project is not the same as $executedProject - or when the plugin assumes the current working directory is the project directory, which is not necessarily the case for a reactor build. Then I've had to go in and add ${basedir} to the settings, and it have > worked (the plugins I've seen these issues in have been pde-maven-plugin > and maven-clean-plugin). > > But you're saying leaving ${basedir} out is safe? to the best of my knowledge yes - but adding ${basedir} won't cause any harm, as it basically does what Maven would do internally to turn the relative path into an absolute path, so if that works for you then that's fine too. I put it in there yesterday just to be sure, and it seemed to work as > well. I put the <manifestLocation> setting into a parent with packaging > POM, together with a maven-clean-plugin setting telling it to delete the > MANIFEST.MF directory on "mvn clean". > > -- Cheers, Stuart
