maven plugin: Cannot find setter, adder nor field in com.agilejava.docbkx.maven.DocbkxWebhelpMojo for 'distroName'

Bug #1351245 reported by Gauvain Pocentek
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openstack-manuals
Invalid
High
Sam Harwell

Bug Description

I ended up with this error while trying to build an OS docbook with the current clouddocs-plugin trunk.

Tags: doc-tools
Changed in openstack-manuals:
importance: Undecided → Critical
Sam Harwell (sam-z)
Changed in openstack-manuals:
assignee: nobody → Sam Harwell (sam-z)
status: New → Confirmed
Revision history for this message
Sam Harwell (sam-z) wrote :

The underlying cause of this bug is an error in the implementation of Parameter.getJavaIdentifier():
https://code.google.com/p/docbkx-tools/source/browse/trunk/docbkx-builder-maven-plugin/src/main/java/com/agilejava/maven/docbkx/spec/Parameter.java?r=307#122

This method is capable of returning values where the first letter is uppercase. Maven does not support assigning field values for plugin parameters which start with an uppercase letter (e.g. the backing field for a property named DistroName must be distroName).

The bug was exposed to our plugin via the inclusion of a new value for the `@parameter` tag on line 280 of plugins.stg:
https://code.google.com/p/docbkx-tools/source/detail?r=259

Adding the new expression means a default value now exists for these invalid properties, and attempting to bind them at runtime fails.

There are two possible solutions to this issue, both of which seem to make sense (to me). I lean towards the first proposed solution.

1. Add the properties which start with an uppercase letter to the list of excluded properties. All of the affected properties are declared in docbook/VERSION.xsl, and are extremely unlikely to ever require being set. In fact, it seems they should actually have been declared using <xsl:variable> instead of <xsl:param> (but of course I may be overlooking some other issue which prevented that).

2. Revert following change, which simply defers resolution of this issue to a later date and brings back the previous issue related to source file encodings.
https://review.openstack.org/#/c/107115/

Revision history for this message
Anne Gentle (annegentle) wrote :

We use profiling for the install guide so I doubt 1) will prove to be an easy fix. Go with 2) media rely then investigate 1)

Revision history for this message
Anne Gentle (annegentle) wrote :

Erg not media really. For now revert the use of 12.0.5

Revision history for this message
Andreas Jaeger (jaegerandi) wrote :

I suggest to revert for now, we should not have a broken tree. It would also be great if we would have tests for building of manuals that would cover these issues before check in.

Once this is reverted, look again at option 1 - adding it, fixing the problem, testing everything - and only then applying the patch.

Revision history for this message
Tom Fifield (fifieldt) wrote :

Hi.

How is this going? Is this still a critical bug?

Revision history for this message
Tom Fifield (fifieldt) wrote :

As this appears to have been worked around, I am lowering the priority from Critical.

Changed in openstack-manuals:
importance: Critical → High
Revision history for this message
Tom Fifield (fifieldt) wrote :

this appears to be fixed

Changed in openstack-manuals:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.