[
https://issues.apache.org/jira/browse/MNG-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805773#comment-17805773
]
ASF GitHub Bot commented on MNG-5862:
-------------------------------------
delanym commented on PR #1205:
URL: https://github.com/apache/maven/pull/1205#issuecomment-1887778841
The stigma surrounding xinclude is really quite infuriating. Is there a
feature more maligned than this? The disparity between its notoriety and its
simplicity is something almost poetic.
The fact is pom files already compose in at least 3 other ways - so if
there's some "security principle" at play its already broken. It could be
argued the whole purpose of pom files is to compose.
Whether processing xinclude introduces risks has nothing to do with XML per
se (a standard designed to be as open and dynamic as possible so no wonder
there's so many horror stories) and everything to do with this implementation.
You'd have to be half-mad not to use this one anyway.
I'm also not sure that xincludes will really work in practice, but I've yet
to see why not.
> 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
> Assignee: Guillaume Nodet
> 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.20.10#820010)
