Maven Doxia

Support use of custom properties in XDOC files

Details

  • Type: Task Task
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Won't Fix
  • Affects Version/s: 1.0-alpha-8
  • Fix Version/s: None
  • Component/s: Module - Xdoc
  • Labels:
    None
  • Number of attachments :
    0

Description

In the JPOX Maven1 use of "site" we tagged all (XDOC) docs like this
<document>
<properties>
<title>Application Identity</title>
<jpoxpagetype>Persistence</jpoxpagetype>
<jpoxversion>1_2</jpoxversion>
</properties>
...
</document>

since XDOCs werent validated against any DTD etc.

Then in site.jsl we could access these properties via
<j:set var="jpoxpage_param">
<x:expr select="./properties/jpoxpagetype"/>
</j:set>

With Maven2 I don't see how I can do this. I define my own skin for JPOX and in site.vm I have $title, $authors but nothing more. Delving into Doxia I see where they were set up. No allowance for users own properties.

The requirement for JPOX is that we have a large number of documents, and we tag each doc for particular categories ... which will then appear on the web site as horizontal navigation (the default Maven skin only has the navColumn ... vertical navigation). By being able to tag docs into categories/subcategories etc we can then generate a site that the user selects a horizontal nav category, and then a horizontal nav sub-category, and they see vertical navigation within that subcategory. This was possible with Maven1 due to the above ability. Without an equivalent in Maven2 we cannot switch over.

The JPOX docs (from Maven1) are available at http://www.jpox.org/docs/1_2/index.html
so you can understand what is being talked about here. If you need any more info let me know.

Issue Links

Activity

Hide
Lukas Theussl added a comment -

Maven 1.1 (and xdoc-plugin > 1.10) allows to validate xdoc sources according to a published DTD, see http://maven.apache.org/maven-1.x/plugins/xdoc/reference/xdocs.html#Validation. According to this schema, you sources are not valid xdocs.

Show
Lukas Theussl added a comment - Maven 1.1 (and xdoc-plugin > 1.10) allows to validate xdoc sources according to a published DTD, see http://maven.apache.org/maven-1.x/plugins/xdoc/reference/xdocs.html#Validation. According to this schema, you sources are not valid xdocs.
Hide
Andy Jefferson added a comment -

Yes, I'm aware that if things are validated against XSDs then that wont validate but it is a perfectly reasonable requirement to be able to specify a page to be in a particular horizontal and vertical navigation position. If there is some other way of providing this then please tell me what it is.

If M2/Doxia is never going to support flexible horizontal/vertical navs that we require (in some way), then M2 will never be an option for us since site generation is a key part of any project

Show
Andy Jefferson added a comment - Yes, I'm aware that if things are validated against XSDs then that wont validate but it is a perfectly reasonable requirement to be able to specify a page to be in a particular horizontal and vertical navigation position. If there is some other way of providing this then please tell me what it is. If M2/Doxia is never going to support flexible horizontal/vertical navs that we require (in some way), then M2 will never be an option for us since site generation is a key part of any project
Hide
Lukas Theussl added a comment -

This should be done with meta elements inside head, see DOXIA-129.

Show
Lukas Theussl added a comment - This should be done with meta elements inside head, see DOXIA-129.
Hide
Data Nucleus added a comment -

Thx Lukas, but how do I access such meta elements from a Velocity file? got an example?

Show
Data Nucleus added a comment - Thx Lukas, but how do I access such meta elements from a Velocity file? got an example?
Hide
Data Nucleus added a comment -

All seem to be thrown away using the version of Maven site referred to here (as "unknown" sink events whatever that is). Consequently they aren't in the generated site at all. If I can't access these "custom properties" from within the "meta elements inside head" (using a custom Velocity file) then this JIRA is not resolved

Show
Data Nucleus added a comment - All seem to be thrown away using the version of Maven site referred to here (as "unknown" sink events whatever that is). Consequently they aren't in the generated site at all. If I can't access these "custom properties" from within the "meta elements inside head" (using a custom Velocity file) then this JIRA is not resolved
Hide
Lukas Theussl added a comment -

It is resolved as 'Won't fix'.

Unknown sink events are events that a parser may emit when it encounters an element for which no sink method exists. Eg the xdoc parser may emit an unknown event for a <script> tag, which the xhtml sink can process, but an arbitrary sink may ignore.

Which version of the site plugin do you refer to here? Using doxia-1.1 (since site-plugin-2.1), the head elements should be preserved.

Show
Lukas Theussl added a comment - It is resolved as 'Won't fix'. Unknown sink events are events that a parser may emit when it encounters an element for which no sink method exists. Eg the xdoc parser may emit an unknown event for a <script> tag, which the xhtml sink can process, but an arbitrary sink may ignore. Which version of the site plugin do you refer to here? Using doxia-1.1 (since site-plugin-2.1), the head elements should be preserved.
Hide
Data Nucleus added a comment -

Hi Lukas, i've tried various versions. Most recently 2.1.1 since 2.1 is buggy for validating basic XDOC documents. Yes, it preserves the <meta> in the generated (X)HTML, but I'm not too bothered about preserving them. My question is how do I access them in a velocity file site.vm?
???.head.name or something? Thx

Show
Data Nucleus added a comment - Hi Lukas, i've tried various versions. Most recently 2.1.1 since 2.1 is buggy for validating basic XDOC documents. Yes, it preserves the <meta> in the generated (X)HTML, but I'm not too bothered about preserving them. My question is how do I access them in a velocity file site.vm? ???.head.name or something? Thx
Hide
Lukas Theussl added a comment -

The DefaultSiteRenderer emits the head in a variable $headContent, but as a plain String, so I'm afraid you can't access child elements like above.

Show
Lukas Theussl added a comment - The DefaultSiteRenderer emits the head in a variable $headContent, but as a plain String, so I'm afraid you can't access child elements like above.

People

Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: