[
https://issues.apache.org/jira/browse/MNG-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182405#comment-17182405
]
Dániel Dékány commented on MNG-5862:
------------------------------------
The namespace is already associated with the nodes of the "snippet" node tree,
so I'm not sure if there's a difficulty there that I miss. As of all the others
mentioned, are those relevant in the case of a POM?
Anyway, they have deliberately removed XInclude support, so, I thought, if
there's no hope for that, there's still a way to allow reusing pieces of XML.
The main goal would be to be able to reuse pieces of plugin configuration. We
can reuse text via {{properties}}, but not multiple "parameters" in a plugin
configuration. That hurts sometimes, and feels to be a quite arbitrary
restriction to me.
Actually, allowing inserting XML snippets anywhere probably leads to too much
abuse (mostly, people using it where inheritance can solve the same), but if
it's POM concept, then maybe it can be restricted enough.
> POM XML parser needs XInclude and/or XML Entity support
> -------------------------------------------------------
>
> Key: MNG-5862
> URL: https://issues.apache.org/jira/browse/MNG-5862
> Project: Maven
> Issue Type: New Feature
> Components: POM
> Reporter: Jason Vas Dias
> Priority: Major
>
> POM XML files can get very large and repetitive , and not all modularizaton
> scenarios can be resolved by using a Super POM as described in MNG-1980 ,
> and would be easily resolved if only the POM parser supported XIncludes or
> XML Entities - neither are supported.
> Here is one such scenario:
> I have a large project that has several SureFire plugin based "Test Suites" -
> each test suite uses a "common-at-classes" module of common test classes,
> and is essentially identical except in its XML configuration "test resource"
> files
> - so the structure is like this :
> {quote}
> {noformat}
> Top Level project directory:
> ./pom.xml
> ./acceptance-tests/pom.xml
> ./acceptance-tests/common-at-classes/pom.xml
> ./acceptance-tests/test-suite_#1/pom.xml
> ...
> ./acceptance-tests/test-suite_#N/pom.xml
> {noformat}
> {quote}
> There are @ 10 ( being upgraded to @ 20) "test suites",
> which all do exactly the same thing, but with slightly
> different "test resource" configuration files,
> and depend on the 'acceptance-tests/common-at-classes" JAR .
> We can modularize all the test-suite dependencies OK in the single
> common-at-classes/pom.xml location .
> But their is no way to modularize the actual XML code that runs each
> test-suite with plugin executions - these plugin execution stanzas can
> currently ONLY
> be in each test-suite#N directory, even though they are identical.
> It would make no sense to have the "Super POM" : acceptance-tests/pom.xml
> contain the plugin executions to run any single test suite ; nor can the
> common-at-classes/pom.xml contain the plugin execution to run any
> test suite, since a test suite run depends on the customized test resource
> files that only exist in each "test_suite#N/" sub-project .
> So the only solution currently available with Maven is to copy the XML stanzas
> that configure and run the test suite ( about 400 lines of XML ) into each of
> the 10-20 test-suite/pom.xml files ; this is all because Maven does not
> support
> XML XInclude or XML Entities; if it did, we could put all this code into one
> XML
> file provided by the common-at-classes project, and include it in each test
> suite .
> The test suite XML is then a nightmare to maintain, consistently for all test
> suites.
> This is becoming such a problem that I am considering making the root project
> POM do nothing more than transform the test-suite poms with XML XInclude-s
> (using an external XML processor), creating a new copy of the whole project,
> and then run an exec plugin goal which runs maven with the transformed POMs.
> Please, please can we have some form of XInclude or XML Entity support , or
> support for an "<include ...>" element, in the POM parser !
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
