foCustomization not interpreted relative to basedir

[GoogleCodeExporter]

The value of the foCustomization parameter in the docbkx-maven-plugin 
configuration is interpreted relative to the current working directory, not the 
basedir of the Maven project. This is problematic in multi-module builds where 
a submodule uses docbkx-maven-plugin. The build of the individual submodule 
will succeed (because the working directory is the basedir), but the build of 
the multi-module project will fail (because the working directory is the 
basedir of the root module, not the basedir of the module using 
docbkx-maven-plugin).

The problem is caused by the fact that the foCustomization parameter is of type 
String, not File. When File is used, Maven takes care of resolving the 
parameter value relative to the basedir of the project.

Original issue reported on code.google.com by andreas.veithen@gmail.com on 21 Sep 2012 at 10:31

[GoogleCodeExporter]

The attached patch solves the issue for foCustomization (and the 
xxxCustomization parameters used by other goals). Note that it doesn't take 
care of the getDefaultStylesheetLocation/getNonDefaultStylesheetLocation stuff. 
It is also likely that other parameters will require a similar change to make 
docbkx-maven-plugin working as expected in multi-module builds.

Original comment by andreas.veithen@gmail.com on 21 Sep 2012 at 10:34

Attachments:

• issue-93.patch

[GoogleCodeExporter]

Hi,

thank you for your patch, I will apply it and have a look to other properties 
with the same problem.

Regards,
Cedric,

Original comment by MimilO...@gmail.com on 24 Sep 2012 at 7:12

[GoogleCodeExporter]

The same problem (with a slight variation) also occurs for imgSrcPath and 
admonGraphicsPath. Now, for foCustomization there is an easy workaround, which 
is to prepend ${basedir}/ to the parameter value:

<foCustomization>${basedir}/src/docbkx/xsl/fo.xsl</foCustomization>

Doing the same for imgSrcPath and admonGraphicsPath works on Unix systems, but 
not on Windows. The reason seems to be that the parameter value may be a URL. 
On Windows, ${basedir} will start with a drive letter and the plugin gets 
confused because it believes it is a URL.

The only reliable workaround I found for that issue is to configure an 
execution of the gmaven-plugin plugin to convert basedir to an URL:

            <plugin>
                <groupId>org.codehaus.gmaven</groupId>
                <artifactId>gmaven-plugin</artifactId>
                <version>1.2</version>
                <executions>
                    <execution>
                        <id>init-properties</id>
                        <phase>initialize</phase>
                        <goals>
                            <goal>execute</goal>
                        </goals>
                        <configuration>
                            <source>
                                import java.io.File

                                project.properties['baseUrl'] = project.basedir.toURI().toString()
                            </source>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

One can then use that to fix the imgSrcPath and admonGraphicsPath parameters:

<imgSrcPath>${baseUrl}/src/docbkx/images/</imgSrcPath>
<admonGraphicsPath>${baseUrl}/src/docbkx/admon-graphics/</admonGraphicsPath>

If you want to test that, check out 
http://rhq-websphere-plugin.googlecode.com/svn/trunk/ (the Docbook project is 
in the design-doc submodule).

Original comment by andreas.veithen@gmail.com on 27 Sep 2012 at 8:45

[GoogleCodeExporter]

Hello,

and if you use something like 

<imgSrcPath>file:///${basedir}/src/docbkx/</imgSrcPath>

If I remember good it was working on windows, could have a test? (I do not have 
a windows machine near)

Regards,
Cedric,

Original comment by MimilO...@gmail.com on 10 Jul 2013 at 7:53

[GoogleCodeExporter]

The question is actually whether this works on Unix considering that it 
generates an URL of the form "file:////..." instead of "file:///...". It looks 
like the additional slash doesn't cause problems (at least not on Mac OS X), so 
this would indeed be a valid workaround.

Original comment by andreas.veithen@gmail.com on 14 Jul 2013 at 9:17

[GoogleCodeExporter]

Hello,

I commited your patch in r271.

getDefaultStylesheetLocation/getNonDefaultStylesheetLocation are used to locate 
the stylesheet within the docbook dependency, so there will be no issue of 
relative directory.

I think the 3 /// is a simple workaround, I added it in the wiki FAQ.

PS: I didn't yet added a multi module testcase :(

Original comment by MimilO...@gmail.com on 10 Sep 2013 at 7:36

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by MimilO...@gmail.com on 19 Jan 2014 at 7:18

• Added labels: Milestone-Release2.0.15