[
https://issues.apache.org/jira/browse/MNG-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Pettey updated MNG-5862:
-------------------------------
Comment: was deleted
(was: Since there's no {{<scope>import</scope>}} for {{<pluginManagement>}},
there's no support for {{<pluginManagement>}} in profiles, and there's no
Xinclude, this would at least allow my top-level {{<dependencyManagement>}} pom
to specify properties for plugin versions. Also:
* dependencies whose versions are additionally used in a {{<profile>}} for
additional artifacts, e.g. Checker Framework.
* {{<links>}} to javadoc which are not at the default URL m-javadoc-p expects,
but can be located using the same version property (e.g. every apache commons
dependency)
* interpolated resources referencing version properties
This usage should be considered for PDT so it doesn't become yet another thing
that can't be fixed ever because the model is set in stone.
{{<dependencyManagement>}} does not exist completely isolated from the rest of
the project.)
> 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
(v7.6.3#76005)
