[
https://issues.apache.org/jira/browse/TRINIDAD-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-1056.
---------------------------------------
Resolution: Fixed
Fix Version/s: 1.2.7-plugins
Fixed on trunk and 1.2.6.1. I blacklisted many mfp: elements so that the
resultant faces-config.xml is mostly the same. Adding new mfp: elements will
automatically be copied over now
> Chang maven-faces-plugin to stop filtering out metadata
> --------------------------------------------------------
>
> Key: TRINIDAD-1056
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1056
> Project: MyFaces Trinidad
> Issue Type: New Feature
> Components: Plugins
> Affects Versions: 1.0.7-core, 1.2.7-core
> Reporter: Andrew Robinson
> Assignee: Andrew Robinson
> Fix For: 1.2.7-plugins
>
>
> The maven-faces-plugin has two xsl files, transform.xsl and transform12.xsl.
> These files are used to build the final version of the faces-config.xml.
> Right now they are implemented to support a certain set of elements in the
> facet-extension and property-extension.
> For example, the XSL code basically says, if there is an <mfp:required/>
> element under the <property-extension/>, then create a new element called
> <required/> and apply the templates to its guts.
> This is a very inflexible design as for every new mfp:* property that an IDE
> adds support for, we have to update the XSL files and ship a new version. I
> would like to change this so that all mfp:* elements are automatically
> stripped of the namespace and copied over without filtering. I don't see any
> value in filtering these out in the plug-in.
> Right now I'd like to add <mfp:hidden/> so that if component B extends
> component A, but does not want to make one of the properties a part of the
> public API, then it can hide an attribute or facet from the tag
> documentation.
> I will wait for the standard 72 hours for negative feedback, and if I don't
> receive any I will update the XSL files to simply pass through all mfp:*
> elements without a white-list approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
